Support --serve and --watch when using Deno without package.json

[vrugtehagel]

Is your feature request related to a problem? Please describe.

Currently, Eleventy works beautifully with Deno. However, it requires a package.json with "type": "module" to trigger Eleventy to go into ESM mode. I'd love it if I didn't need the package.json, given I already have deno.json for my dependencies; my package.json contains only { "type": "module" } just to be able to --serve my Eleventy site.

Describe the solution you'd like

The cleanest is probably to default to ESM if no package.json is found (since Eleventy 3 is ESM-first).

If that's undesirable, then the second-best solution is presumably a generic one; I'm thinking a flag --force-esm that forces Eleventy to go into ESM mode without looking for package.json. This would not only solve the issue for Deno, but also for other runtimes such as Bun. Furthermore, it would provide Node users with the option to force ESM mode if needed without having to change the "type" in their package.json (although I don't quite see a good use-case for this).

Alternatively, Eleventy looks for deno.json if package.json doesn't exist. However, this is runtime-specific and so might not be the best solution (especially if Eleventy is not quite ready to commit to supporting Deno officially).

Lastly, it could be a config option. The internal ESM flag is only used for watch and serve mode, so it should work, but this solution feels counter-intuitive to me since the config file itself needs to be read before the option can be set.

[vrugtehagel]

By the way, I'd be happy to open a PR if Eleventy is interested in supporting this feature!

[zachleat]

I think that’d be fine! First thoughts I’m wavering between:

• --type=module and --type=commonjs (default)
• --type=esm and --type=cjs (default)

Also is there a better idea than --type?

[vrugtehagel]

I do feel like --type is a good fit, but on the other hand it's very general (i.e. might be a good fit for a fair few other things, too).

A more specific one would be --loader, which is also what esbuild uses for this kind of thing. That is, we would have --loader=esm and --loader=cjs.

As for the values, I prefer esm and cjs mostly for brevity, but also module feels a bit too vague. If I see npx @11ty/eleventy --loader=module, then that doesn't look as clear to me as when I see npx @11ty/eleventy --loader=esm. But, perhaps that's only a personal preference of mine.

[vrugtehagel]

Also, just now realized; you mentioned cjs should be the default, but presumably we'd want to have an auto value as default, which reads the "type" from package.json. I would expect --loader=cjs to force Eleventy into CommonJS mode regardless of my package.json, so we would need this auto value for backwards compatibility.

Anyways, I'll draft up a PR for this later. Shouldn't be too big of a change 😄

[zachleat]

Great call on auto, yeah!

[vrugtehagel]

It seems that this change is necessary for Deno 2 (which is around the corner; Deno 1.46 is the last 1.x release). Deno 2 will complain that it cannot run Eleventy through deno run -A npm:@11ty/[email protected] (the Deno equivalent of npx @11ty/eleventy) because there is a package.json that doesn't specify Eleventy as a dependency. In other words; users would be forced to use package.json instead of deno.json, which comes with a whole array of other issues.

@zachleat could you have a look at the pull request? It'd be ideal to have a fix merged before Deno 2 lands 🙂

> DENO_FUTURE=1 deno run -A npm:@11ty/[email protected]
error: Could not find a matching package for 'npm:@11ty/[email protected]' in
a package.json file. You must specify this as a package.json dependency when the
node_modules folder is not managed by Deno.