Vite Struggles with Exports

[shellscape]

Any chance of getting an ESM version or some default export shimming introduced? vite dev dislikes the package immensely, throwing an error which resembles:

Uncaught SyntaxError: The requested module '/@fs/private/tmp/jsx-email-starter/node_modules/.pnpm/extend@3.0.2/node_modules/extend/index.js?v=ae42d2d7' does not provide an export named 'default' (at index.js?v=ae42d2d7:350:8)

unified is making use of this package (and is ironically ESM-only) and running vite with anything that wants to use unified is quite impossible without extensive gymnastics.

[justmoon]

This has come up before, see #57.

After playing around with adding ESM support, the issue is that this module currently supports very old Node.js versions which obviously don't support ESM at all. Adding a transpiler or maintaining two copies of the code and tests adds a lot of complexity.

To add ESM support for this module, the best way imo would be to make a new major version which fully switches to ESM and drops support for Node.js versions <12. Kind of like what @sindresorhus has done with his packages. Users of older Node.js versions could continue to use the older version of the package.

I'd be fine with that but @ljharb has been the primary maintainer for this package, so he'd have to agree.

[ljharb]

Have you filed an issue on vite? It should be able to handle all existing CJS packages, or else it's broken.

As for ESM-only packages, if you look at adoption numbers for basically all of them, without exception, the vast majority remains permanently stuck on the last CJS version - iow, it's objectively proven to be a failed initiative.

We could certainly ship a .mjs file and the exports field - VERY carefully, so as to not make it a breaking change - that would re-export all the properties on the CJS module.exports as named ESM exports, but that simply shouldn't be necessary. node itself uses cjs-module-lexer to figure out things like this for its native ESM implementation, so vite certainly should be able to.

[milesaylward]

Old issue but if anyone is using Vite and stumbles on this as I did the simplest solve I could find was to include extend in vite's optimizeDeps config.

optimizeDeps: {
  include: ['extend']
}

[MattiJarvinen]

Tracked this here:

  ▲ [WARNING] Module 'extend' used by 'node_modules/unified/lib/index.js' is not ESM

    CommonJS or AMD dependencies can cause optimisation bailouts.

In Node.js, bundle size is rarely an issue, but on the frontend it can cause major performance problems through many small inefficiencies adding up. One can reduce the impact by isolating code and splitting bundles carefully, but that only delays or softens the issue rather than solving it outright.

I completely understand that @ljharb will not alter a relatively small and stable library.

More information for anyone bumping here later:

• Angular: https://angular.dev/tools/cli/build#configuring-commonjs-dependencies
• JS in general: https://web.dev/articles/commonjs-larger-bundles