3.4.0-rc.17+snowpack/esbuild failing with Class constructor Observable cannot be invoked without 'new'

[sebastienbarre]

Intended outcome:

Trying to run any app using Apollo Client 3.4.0-rc.17 and snowpack (which uses esbuild under the hood if I'm not mistaken).

Actual outcome:

Once built, my app fails right away, with the console outputting:

TypeError: Class constructor Observable cannot be invoked without 'new'
    at new ObservableQuery (client.js:5431)
    at QueryManager.watchQuery (client.js:6658)
    at ApolloClient.watchQuery (client.js:7280)
    at QueryData.initializeObservableQuery (client.js:7900)
    at QueryData.updateObservableQuery (client.js:7908)
    at QueryData.execute (client.js:7804)
    at client.js:8097
    at useDeepMemo (client.js:8067)
    at useBaseQuery (client.js:8097)
    at useQuery (client.js:8137)
Uncaught TypeError: Class constructor Observable cannot be invoked without 'new'
    at new ObservableQuery (client.js:5431)
    at QueryManager.watchQuery (client.js:6658)
    at ApolloClient.watchQuery (client.js:7280)
    at QueryData.initializeObservableQuery (client.js:7900)
    at QueryData.updateObservableQuery (client.js:7908)
    at QueryData.execute (client.js:7804)
    at client.js:8097
    at useDeepMemo (client.js:8067)
    at useBaseQuery (client.js:8097)
    at useQuery (client.js:8137)

How to reproduce the issue:

Unfortunately, I cannot reproduce it from your Apollo Client Issue Reproduction repo, https://github.com/apollographql/react-apollo-error-template, which uses Create React App.

However I can reproduce it by taking the exact same example code of yours and plugging it into the official, Snowpack minimal template (app-template-mininal).

Here is my repo:
https://github.com/sebastienbarre-forks/react-apollo-error-template-snowpack

to reproduce, clone and:

npm install
npm run build
rpm run serve

head to the Google chrome console for the error message.
Replace 3.4.0-rc.17 with the current, official 3.3 and the problem goes away.

Note that the codesandbox will not fail -- this works in development mode, but fails once built.
https://codesandbox.io/s/github/sebastienbarre-forks/react-apollo-error-template-snowpack?file=/README.md

If I may invite snowpack and esbuild extraordinaire @FredKSchott and @evanw, they might know what's going on?

Thank you all.

Versions

  System:
    OS: macOS Mojave 10.14.6
  Binaries:
    Node: 16.4.2 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.18.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 91.0.4472.114
    Safari: 14.0.3
  npmPackages:
    @apollo/client: 3.4.0-rc.17 => 3.4.0-rc.17

Additional context

@benjamn added yesterday:

Initial answer below (I'll paste these details into the issue when it exists):

That sounds like the Observable class we use as the superclass for ObservableQuery is getting defined using native class syntax in production, but is compiled down to non-class syntax in development.

For the time being, Apollo Client needs to maintain compatibility with Internet Explorer 11, for applications that don't recompile their node_modules (see #8186 for future/AC4 plans). That's why @apollo/client ships a compiled version of ObservableQuery class without native class syntax. When the Observable superclass is a native class, ObservableQuery may have trouble calling super(...) in its constructor, because the compiled Observable.call(...) version of that code throws the exception you saw.

However, the zen-observable-ts wrapper package that Apollo Client v3.4 uses to implement Observable has some extra compatibility logic to handle this specific case, so I'm not exactly sure where the problem is coming from.

[brainkim]

Maybe Related:

• Revive zen-observable-ts wrapper for zen-observable package. #7615
• Support exports syntax in package.json evanw/esbuild#187
• When used with require() and node, does not honor "main" field in package.json if "module" is present evanw/esbuild#363

[benjamn]

@sebastienbarre Please try @apollo/client@3.4.0-rc.18 when you have a chance!

[sebastienbarre]

@benjamn thanks for the hard work guys, this fixes the reproduction repo, and my own app.

[benjamn]

Based on my past experiments with Snowpack, I think this might also be the final puzzle piece that allows Snowpack apps (in general) to use @apollo/client safely in production. ☃️📦

[sebastienbarre]

@benjamn unfortunately I had to revert to 3.3. GraphQL giveth and
GraphQL taketh away. After working on our app all day, I noticed a lot of new "Missing cache result fields" aka MissingFieldError on the console in rc18 that are not triggered by 3.3 for sure. I'm not sure how to even reproduce them outside our app, so I might wait for other people to give a shot to the official 3.4 release...

[dylanwulf]

@sebastienbarre I submitted an issue recently about "Missing cache result fields": #8442. Maybe your problem is similar to what I was seeing? From the response on my issue, it seems like it's intentionally noisy and these warnings don't necessarily mean that something is incorrect.

[sebastienbarre]

@dylanwulf thanks! Let me head to that thread.