@apollo/client v3 broken in Rollup & Snowpack

Tracked it back to this item:

https://github.com/apollographql/apollo-client/blob/master/src/react/react.ts#L8

The require function doesn’t exist inside an ES Module (any file with import or export syntax), which is causing the package to fail in some bundlers.

Happy to help brainstorm ideas on how to solve if you’d like, but would strongly recommend against shipping 3.0 with broken support in any major bundlers.

[abdonrd]

Also about ES Modules related, @apollo/client still uses three dependencies exported as CommonJS:

• graphql-tag (#6074)
• zen-observable (#5961)
• fast-json-stable-stringify

I have noticed this trying to make @apollo/client work directly in the browser, without using any build/bundled process during development.

[FredKSchott]

Yup, 100% agreed and wish this was better supported in ESM. But even Webpack is limited by how much it can statically analyze. Bundlers can see that @apollo/client is importing & requiring React, but they can’t tell at build-time wether that runtime function that does it will or won’t ever be run, so a bundler will normally just bundle “react” into your app just to be safe.

Based on the above, I’m 99% sure that Webpack is bundling "react" into every application that uses @apollo/client v3 regardless of whether the that code path ever gets hit. I don’t think it’s actually buying you that much.

I’d recommend:

1. Decide that @apollo/client is for React, and remove the layer of indirection / just import react directly. Webpack is already including React anyway, so this isn’t too different from the way it is behaving today, but you’d be able to support Rollup, Snowpack, etc, etc.
2. Split out anything React-specific from @apollo/client into a new @apollo/react or @apollo/client-react. I’d actually recommend this regardless of this issue, since it would help you scale to @apollo/client-{FRAMEWORK} without much thrash, but that’s just my outsiders opinion.
3. Move anything React-specific into a @apollo/client/react sub-path within the package, and have users import from there directly. Everyone who npm installs the package will still get react as a dependency, but if the user never imports @apollo/client/react in their project, bundlers should be smart enough to handle that.