[@web/test-runner] cannot import all npm packages

[tirithen]

I have now several times seen problems with npm packages that fails to import due to themselves or internally not handling default exports properly.

My latest problems with this is from the https://www.npmjs.com/package/expression-eval package (but it is easy find more projects with similar issues):

SyntaxError: The requested module './../../jsep/build/jsep.js' does not provide an export named 'default'

Some other issues probably related to this:

• Add ES modules to the bundle testing-library/user-event#547
• Unable to import intl-messageformat as standard ESM module formatjs/formatjs#2841

For the development server when I switched to vite instead of @web/dev-server all these imports just worked out of the box.

For sure in the best of worlds all older npm packages would be updated to latest ESM standards, but in reality that will take a long time.

Would it be possible to add similar import fixes that vite applies to the @web/dev-server and @web/test-runner as well?

Apart from this both packages are superb, I have been using them through the npm init @open-wc helper, but had to resort to vite for now, and possibly something else for testing now as well.

I also tried finding more details around the nodeResolve property in my web-test-runner.config.mjs and the possibility to setup some config there but I cannot find any config there much more useful than the simplest nodeResolve: true setting.

How are the rest of you working around this current limitation?

[Westbrook]

We are not likely to be adding CJS support by default to our tooling as it was never standardized, and as such was never and will never be supported by the browser which is the environment that our tooling is specifically targeting to.

Users that require support for CJS in their projects are encourages to bring up the out of date nature of these tools with the libraries that vend them, and when that is not enough can follow the following instructions to get support for CJS added locally to their configs: https://modern-web.dev/guides/dev-server/using-plugins/#commonjs This way only users who need support for these older packages need to pay the build time costs of addressing them.

Please let us know if that clears up the situation you've found yourself in.

[tirithen]

@Westbrook Thank you for the answer and your explanation. I myself prefer to stick to only the recent formats (especially as they are standards) as well, it is just inconvenient as there is such a huge amount of older packages with nice features out there.

Thank you also for the link about commonjs for the dev server, I think I was uncertain on how to add these settings for the test runner, but I'll give it a go, maybe both the test runner and dev server config APIs are more similar than I first noticed.

For now in the project affected by this, I simply reverted to the old school vendor/ directory and copied the packages source files and edited the export part as a workaround. That was good enough for now.

Keep up the good work! Hopefully the standard export/import will eventually be embraced by all major packages, libraries and frameworks.