11ty 3.0, version specifier and ESM

[pauleveritt]

Hi, we have an 11ty 3.0 project that we converted to ESM. Interested in getting rid of Vite and looking at this plugin for SCSS/PostCSS processing. First: thanks for working on this, fun reading through the source!

Since the package.json declares this is for 11ty 2.0 (-ish), I had to install with --force.

Then, when including the plugin in the 11ty config file:

[11ty] 1. Error in your Eleventy config file 'eleventy.config.ts'. (via EleventyConfigError)
[11ty] 2. Cannot read properties of undefined (reading 'getCompiledTemplate') (via TypeError)
[11ty] 
[11ty] Original error stack trace: TypeError: Cannot read properties of undefined (reading 'getCompiledTemplate')
[11ty]     at Object.<anonymous> (/Users/pauleveritt/projects/pauleveritt/eleventy-tsx/node_modules/eleventy-sass/lib/eleventy/patch-for-2.0.0-canary.18-and-below.js:4:28)
[11ty]     at Module._compile (node:internal/modules/cjs/loader:1376:14)
[11ty]     at Object.S (/Users/pauleveritt/projects/pauleveritt/eleventy-tsx/node_modules/tsx/dist/cjs/index.cjs:1:1292)

This is likely related to turning on the ESM mode in 11ty 3.0. I realize this probably isn't something you've been thinking about, so I'm asking...reluctantly. 😉

[kentaroi]

Thanks for letting me know, @pauleveritt.

I will try to fix the plugin when I can find the time.

[MangelMaxime]

I think you should be able to use eleventyConfig.versionCheck to check the version.

https://www.11ty.dev/docs/plugins/#version-checking

[kentaroi]

Thank you for your comment, @MangelMaxime.

However, eleventyConfig.versionCheck doesn't seem to be applicable in this case, although it'll work in other parts of the plugin, since the issue is probably caused by the change of how modules are loaded as @pauleveritt stated.
In other words, the version check should be done in package.json instead of in code level.

[xplosionmind]

Hi all!

@kentaroi, do you have any plans of shipping an Eleventy 3 and ESM compatible version soon?

I am very sorry to stress you, and I asked reluctantly too, but many of my projects depend on Eleventy and this plugin, so I can’t upgrade to Eleventy v3 without updating this plugin, too! There are not any solutions nearly as good as this!

Thanks so much!

Best,
Tommi

[kentaroi]

Hi, @xplosionmind!

I apologise for any inconvenience this may cause.
I will investigate the extent of the changes made to Eleventy 3 this week and let you know if I can release an update of the plugin that is compatible with Eleventy 3 soon.

[kentaroi]

Hi, all!

I just released eleventy-sass@3.0.0-beta.0 that is compatible with Eleventy 3. I haven't read all of the changes made to Eleventy 3, but fortunately the plugin seems to work with Eleventy 3.

eleventy-sass 3 requires Node.js 22 or newer, and you should add --experimental-require-module option to your Node.js commands.

Therefore, instead of running npx @11ty/eleventy, use the following command:

npx --node-options="--experimental-require-module" @11ty/eleventy

Eleventy 3 uses ES modules, which are quite restrictive, and probably there is no way to load internal modules in an NPM package whose type is "module" (ES module) from another NPM package whose type is also "module".

Therefore, I keep the type of eleventy-sass package default ("commonjs") and decide to use require() to load internal ES modules of Eleventy 3, which is an experimental feature of Node.js 22.

[xplosionmind]

Thank you so much, @kentaroi! ❤️

I just updated the plugin, and it works well, except for the many warnings about the experimental “require in modules” feature of Node 22.

I am not a JavaScript developer, so I am not sure, but I think that using require in modules is not necessarily the only solution. There is very useful information about this in this discussion.

If you wish to smoothly transition to an ESM-first plugin, I believe it will be best.

For the time being, thanks again, and have a great weekend! 🚀

[kentaroi]

Thank you for your comment, @xplosionmind!

The discussion you referred to isn't directly related to my needs, but your comment made me revisit ES module features, and I think I found a way to do it in ES module. Thank you very much.

Eleventy is a great Static Site Generator. However, it hasn't been extensible enough so far.

Therefore, eleventy-sass has to access internal modules and patch them to make everything work, and it was easy for Eleventy 1 and 2, like this:

const TemplateRender = require("@11ty/eleventy/src/TemplateRender");

However, the package.json of Eleventy 3 has exports field, which clarifies which modules are public and which are hidden (I initially thought the restriction was caused by ES module but it was not),
and Eleventy 3 reveals only the following modules:

https://github.com/11ty/eleventy/blob/5abe2303d7febbc96acb1d62f122167cda88a48e/src/Eleventy.js#L1393-L1443

If you try to load an internal module with import like the above require, you'll get a Package subpath './src/TemplateRender.js' is not defined by "exports" in /path/to/@11ty/eleventy/package.json error.

To address this problem, eleventy-sass@3.0.0-beta.0 uses require.resolve() and require() with --experimental-require-module to load internal (hidden) modules of Eleventy 3.

Probably, I found a way to do the same in ES module, but I haven't yet decided whether to make the plugin use ES modules or not.

Thanks again, and I hope you have a great weekend, too!

[kentaroi]

I just updated the plugin, and it works well, except for the many warnings about the experimental “require in modules” feature of Node 22.

To silence the ExperimentalWarning, you might want to use the --disable-warning option like this:

npx --node-options="--experimental-require-module --disable-warning=ExperimentalWarning" @11ty/eleventy