(react-urql): Import error in Node.js ESM mode

[brillout]

urql version: 2.2.1.

Steps to reproduce

See https://github.com/brillout/urql-vite3.

Expected behavior

No import error.

Actual behavior

Import error. Note that useQuery can be imported while gql cannot. It seems to be a problem on urql's side.

[JoviDeCroock]

urql has full ESM support in both export maps as well as not using require in the mentioned packages when using the proper export maps/....

• gql is a reexport
• which should point at

Makes me wonder if it's the .mjs extension again.

[brillout]

Thanks @JoviDeCroock for the answer.

The vite-plugin-ssr test suite tests a lot of integration, and only urql and preact are failing. That's why I'm leaning towards thinking it's a problem on urql's side.

[JoviDeCroock]

I mean, I just tried vite locally in our examples while doing those tests which did seem to all work correctly so I think it's something when we are in node-resolution land

[brillout]

Yes, dist/server is vanilla Node.js.

[kitten]

It's worth reminding ourselves that urql (the React bindings package) is not an ESM package as we had issues with making ESM packages that depend on non-ESM React, which seems vaguely similar to this issue. So it's indeed loading the CommonJS file, which is correct, but it's hard to tell why it's struggling with the re-exports. https://unpkg.com/browse/urql@2.2.1/dist/urql.js

Object.keys(e).forEach((function(t) {
  if ("default" !== t && !exports.hasOwnProperty(t)) {
    exports[t] = e[t];
  }
}));

So, probably worth looking into why Node's esm loader doesn't like this when it has to switch back to CommonJS. Likely because it only does a naïve check?

Edit: My first thought here after browsing was that cjs-module-lexer isn't detecting the re-export. But changing it certainly doesn't change the behaviour and the pattern Rollup uses seems to be explicitly tested for in their unit tests