Package.json has type: module but main still points at commonjs

[bschlenk]

I just started using this library and it works great! Thanks for your efforts here.

Now I'm writing tests (and running with vitest), but it seems to be picking up the commonjs version of the build. This results in the error "default is not a constructor".

I'm not 100% sure, but it might be that vitest is following closely with the module spec, where the module field of package.json isn't actually used, instead it uses the main field when there isn't an exports field. The module field of package.json isn't standard, so it makes sense that vitest wouldn't use it.

As a sanity check, I changed the main field to point to the .esm.js file and stopped getting that error. I wouldn't recommend that for production though, I think this should be updated to use the exports field and use conditional exports for require and import.

[bschlenk]

Here's a related discussion in the vitest repo vitest-dev/vitest#4233

[bschlenk]

If anyone else runs into this, I worked around this by adding an alias to my vite config:

alias: {
  'a11y-dialog': path.resolve(__dirname, './node_modules/a11y-dialog/dist/a11y-dialog.esm.js'),
},

[KittyGiraudel]

Hello Brian, and thanks for opening an issue. 👋

I must say this is the part of maintaining a package I am really unexperienced with, and I am always terrified of breaking things by touching the entry points or the bundling system. I recall having to release several hotfixes after v8 to have something that works. 😓

If you are pretty confident with the exports approach, you could consider opening a MR and I’ll happily review it. Otherwise, maybe we can just add your workaround to the docs. What do you think?

[bschlenk]

Yeah I agree touching exports can be scary!

I'm happy to send a MR when I get a chance. I think the biggest risk is that a user might be reaching into the package to grab some internals, and the exports change makes those internals no longer public. So the safest bet is to make sure that all files that are currently in the dist folder remain accessible. You can always lock that down further in a major version update, but this would be the safest bet to keep it a minor version bump.