Closed vrugtehagel closed 4 days ago
By the way, I'd be happy to open a PR if Eleventy is interested in supporting this feature!
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
?
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.
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 😄
Great call on auto
, yeah!
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/eleventy@3.0.0-beta.1
(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/eleventy@3.0.0-beta.1
error: Could not find a matching package for 'npm:@11ty/eleventy@3.0.0-beta.1' in
a package.json file. You must specify this as a package.json dependency when the
node_modules folder is not managed by Deno.
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 thepackage.json
, given I already havedeno.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 forpackage.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 theirpackage.json
(although I don't quite see a good use-case for this).Alternatively, Eleventy looks for
deno.json
ifpackage.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.