[v5.0.0] Fails jest tests

[dennismphil]

I am using url-join on a frontend project. I believe the browser have trouble understanding the export statement in lib. When I revert back to v4.1.0 all works well.

This was the error I was seeing in my jest tests.

 FAIL  tests/unit/App.spec.js
  ● Test suite failed to run

    Jest encountered an unexpected token

    This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.

    By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".

    Here's what you can do:
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/en/configuration.html

    Details:

    /node_modules/url-join/lib/url-join.js:60
    export default function urlJoin() {
    ^^^^^^

    SyntaxError: Unexpected token 'export'

    > 1 | import urlJoin from 'url-join';
        | ^

      at ScriptTransformer._transformAndBuildScript (node_modules/jest-runtime/node_modules/@jest/transform/build/ScriptTransformer.js:537:17)
      at Object.<anonymous> (src/services/client.js:1:1)

Test Suites: 1 failed, 2 passed, 3 total
Tests:       25 passed, 25 total
Snapshots:   0 total
Time:        4.948s
Ran all test suites.                          

[jonkoops]

This is a known issue in Jest, for more information on how to deal with ES modules see their documentation on this topic.

[jonkoops]

I am closing this issue as there is nothing we can do on this side, except also bundling CommonJS (which would require a build step). If you don't want to use ES modules natively you can use Babel to transform the code.

[tony]

@jonkoops This new distribution method does make certain things more difficult.

As an example I use gatsby, I get stung by this here: gatsbyjs/gatsby#23705. This is tricky.

Maybe I'm the only one, but maybe it could be more portable to (some?) users if the package added a distribution for commonjs.

🤷 It's pretty easy to include an extra build output, to include esm, commonjs, etc. (rollup, webpack, tsc). It's your call, though

[jonkoops]

At this time I am not interested in maintaining a build system for this package. It would complicate things unnecessarily, especially in a future where ES modules are widely supported.

If you have tools that do not understand ES modules I would recommend to keep using the latest version in the 3.x range.

[david0178418]

@dennismphil For you and others running into issues on this front, if you take a look at the code, the module is actually quite small and easily lifted out and copied into your project.

If you look at the PR that changed the module format, there was a link to this thread which has since been "locked". Copying this out for the time being until such time that your project might be able to be adapted to work with native node esm modules will get you unblocked while dodging the crossfire in what has become an oddly ideological holy war.

[maksnester]

also bundling CommonJS (which would require a build step)

common guys, some convenience for users never hurts. Now I have to spend time on trying to overcome that silly issue with jest in node 14 which I could completely avoid and had a great time with your library if you could just ship commonjs module too.

[jonkoops]

Enough has been said about this issue and bumping this issue further will not change our stance on this. Tooling will advance and adapt to ESM (for example you can pretty much replace Jest with Vitest).

If you are looking for CommonJS library version feel free to keep using the older versions of this package or fork your own version of it.