Case Study: Apollo Client 4.0

[phryneas]

I'm currently evaluating if we can/should ship version 4.0 of Apollo Client with pre-compiled hooks.
Our current release target is RC state in May and final release in June.

I thought I'll open a thread here and document the whole thing a bit, and call out some questions that come up.

The PR for enabling the compiler is apollographql/apollo-client#12499
and the "Compare Build Output / Compare Build Output" CI step will always contain the diff between upstream & compiled.

You can see a diff here: https://github.com/apollographql/apollo-client/actions/runs/14172911524?pr=12499

[phryneas]

One concern that comes up pretty quick is versioning:

We cannot add a dependency to react-compiler-runtime like ^19.0.0-beta-aeaed83-20250323, as the publishing schema is not deterministic:

In this example, ^19.0.0-beta-aeaed83-20250323 matches these versions:

• 19.0.0-beta-df7b47d-20241124
• 19.0.0-beta-b2e8e9c-20241220
• 19.0.0-beta-e552027-20250112
• 19.0.0-beta-decd7b8-20250118
• 19.0.0-beta-e1e972c-20250221
• 19.0.0-beta-bafa41b-20250307
• 19.0.0-beta-aeaed83-20250323
• 19.0.0-beta-e993439-20250328

So actually, right now, npm will install 19.0.0-beta-e993439-20250328 instead, not because it's the newest one, but because it has the alphabetically "highest" hash. A few days ago, it would have installed the version from January 12 instead.
Newer versions will actually not update with this versioning scheme, since newer versions will likely be sorted alphabetically lower.

This scheme makes package versions unpredictable and ^ pretty useless, which doesn't seem good for a transitive depencency.

For now, we'll have to pin the react-compiler-runtime version and all other libraries will have to do the same, but that means that if multiple libraries get published with different react-compiler-runtime versions, the end-user package might blow up, bundling a lot of these - presumably otherwise compatible - dependencies.

(Note that I already reported this behaviour with the React canary builds and was told that it was intentional to make ^ useless as canaries should always be pinned, but maybe you could rethink this for this "transitive dependency" situation?)

[phryneas]

This is less of a problem now that a RC has been released - thank you!

[phryneas]

Another observation from a library perspective is the fact that the compiler plugin adds import statements, it makes it fiddly to use it with CommonJS builds (we end up with mixed ESM and CJS and have to run "@babel/plugin-transform-modules-commonjs" on it again).
It would be great if it could handle both CJS and ESM.

[phryneas]

Strike that, it doesn't work with CJS at all - if you compare the useQuery.js and useQuery.cjs here, almost no modifications are done in the .cjs file:

https://github.com/apollographql/apollo-client/actions/runs/14244962067?pr=12499