Duplicate export 'ReactQueryDevtools' in snowpack-wrap

[jsefiani]

This message started appearing after I installed ReactQueryDevtools. What could be the problem?

I removed my node-modules folder and reinstalled everything, also used the --reload flag, but nothing really helped.

Does anyone know what this might be?

Whenever I try to start my app in dev mode, I get the following error:

Versions:
snowpack version: 2.13.3
@snowpack/app-scripts-react: 1.10.0
react-query-devtools: 2.6.0

[melissamcewen]

Hi @jsefiani sorry you're getting that error. Do you happen to have the repo in Github? That would help me debug it.

[jsefiani]

Sorry, it's not on Github yet, what exactly do you need?

[FredKSchott]

If you could provide some steps to reproduce in a fresh directory or in a create-snowpack-app template, that would be great! For example, how are you importing ReactQueryDevtools in your application?

I'm actually not sure what could be causing this, since in our CJS->ESM conversion we explicitly filter for duplicate exports by converting to a Set.

[jsefiani]

Here you go, I managed to reproduce the issue in a fresh directory: https://github.com/jsefiani/snowpack-react

[alavkx]

I have a nearly minimal relatively small repro here too

[jsefiani]

Same issue?

[alavkx]

Yarp

[stolinski]

I'm getting a similar issue with https://github.com/accounts-js/accounts

[snowpack] installing dependencies...
[snowpack] Failed to load snowpack-wrap:/Users/scotttolinski/Sites/levelup/node_modules/@accounts/graphql-client/lib/index.js
  Duplicate export '__esModule' (4:49) in snowpack-wrap:/Users/scotttolinski/Sites/levelup/node_modules/@accounts/graphql-client/lib/index.js
[snowpack] Install failed.

[stolinski]

I have a reproduction here using CSA. https://github.com/stolinski/snowpack-accounts-reproduction

The issue comes about when importing from @accounts/graphql-client

[stolinski]

I'm wondering if it has to do with how these files are exported here. https://github.com/accounts-js/accounts/blob/master/packages/graphql-client/src/index.ts

[FredKSchott]

Ah, __esModule is always a pain... but since that's a fake export (added internally by Rollup, I believe) I think "__esModule" can get filtered out by our automatic named import scanner (similar to how we make sure that we handle the default export correctly).

• https://github.com/snowpackjs/snowpack/blob/master/esinstall/src/rollup-plugins/rollup-plugin-wrap-install-targets.ts#L71
• https://github.com/snowpackjs/snowpack/blob/master/esinstall/src/rollup-plugins/rollup-plugin-wrap-install-targets.ts#L42

Would love a PR to tackle this, if anyone's interested!

[ryankask]

Is there a workaround for this? Is there something I could edit in node_modules or in a fork?

[FredKSchott]

this was recently fixed on master, will try to get it out in a patch release as 2.16.2.

[jsefiani]

@FredKSchott Was this fix released? I just updated snowpack to 2.17.0, but I'm still getting the same error?

[tliebberger]

Same here on snowpack version 2.17.1. Any updates on that issue :-(

[justrhysism]

@FredKSchott looks like the commit listed in the release notes never made it to the public repo.

20d8934a - fix: filter out false esmodule export from cjs

Unable to find that commit hash 😞

[jamesscaggs]

Same issue today on 2.17.1 with React Query. Any clue when this fix will get released?

[FredKSchott]

That's really strange, I'll have to find out why it was in the release notes but not the 2.17.0 release. Regardless, this has definitely gone out with 2.18.0 (you can see the commit in the git log). Can someone retry in v2.18 to confirm that this is fixed?

[zaiste]

I confirm this is fixed. Thanks!

There is, however, an issue with ReactQueryDevtools. It uses a trick to omit the component inclusion while not in the development environment. esinstall everything for production. This issue is out of scope for esinstall IMHO and should be fixed in react-query-devtools.

[FredKSchott]

Can you share a link to the relevant line of code? Curious if there's anything that we can do on our end as a short term fix for this package

[zaiste]

Here's the snippet. It reads off NODE_ENV, and if in production returns null. Is the compilation assuming that the production is always set when building ? I wonder if it'd make sense to define env variables «per package», or maybe it's an unnecessary complicaiton ?!

I've also filled a ticket for react-query-devtools

[justrhysism]

So kind of related to this issue, I have a dependency which does have duplicate exports in the packaged code, like:

exports.SomeFunction = void 0;
var SomeFunction = function(foo, bar) { ... };
exports.SomeFunction = SomeFunction;

I have no idea why that first export is there, or which bundler is putting it there. Has anyone seen this behaviour before?

I'm not entirely sure if this is something Snowpack should address, I guess if I was able to determine which bundler was outputting the duplicate exports and why it might help determine if it's a case Snowpack should intelligently handle.

[justrhysism]

Appears that upgrading @rollup/plugin-commonjs to v17 resolves it. Unsure of wider impacts.

[FredKSchott]

ah, good catch. If you're able to submit a PR to update @rollup/plugin-commonjs in esinstall to the latest version, that would be great! We can get that out in our next release

[justrhysism]

@FredKSchott have done so #1877; however, a number of tests have failed. I haven't had a chance to dig into whether it's just the comments now appearing in the snapshots, or whether it's actually breaking.

[FredKSchott]

no problem! followed up in that PR, thanks again

[MichaelFroeschen]

Hi,
I am currently in the process of migrating to snowpack (for research purpose) and i am encountering this error in a dependency that we have. Is there anything that i can do, to handle this?