-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@apollo-client 3.3.2 fails to compile due to wrong ts-invariant version resolved #7406
Comments
@eugeneoshepkov The |
@benjamn So it comes from I don't have direct dependency of |
apollographql/invariant-packages#53 This may also help with issues like #7406, where a _patch_ version update (from 0.5.0 to 0.5.1) is not enough to force a dependency like ts-invariant with multiple conflicting version constraints (from @apollo/client and graphql-tools) to be updated, since version 0.5.0 is still semantically compatible with the desired minimum version 0.5.1, so ts-invariant remains outdated after updating @apollo/client, despite the new version being clearly mandated in @apollo/client/package.json. After updating the _minor_ version of ts-invariant in package.json (to ^0.6.0), there should be no risk of @apollo/client incorrectly resolving the older [email protected] version.
apollographql/invariant-packages#53 This update may also help with issues like #7406, where a patch version update (from 0.5.0 to 0.5.1) is apparently not enough to force a dependency like ts-invariant with multiple conflicting version constraints (from @apollo/client and graphql-tools) to be updated, since version 0.5.0 is still semantically compatible with the desired minimum version 0.5.1, so ts-invariant remains outdated after updating @apollo/client, despite the new version being clearly mandated in @apollo/client/package.json. After updating the minor version of ts-invariant in package.json (to ^0.6.0), there should be no risk of @apollo/client incorrectly resolving the older [email protected] version, though there may end up being multiple copies of ts-invariant in node_modules with different versions, which is fine for this particular package.
@eugeneoshepkov If you update to |
@benjamn Thanks for the fast response! Unfortunately, I'm still having this issue. I wonder if it can be related to my webpack / babel configuration, if it changes default node_modules resolve logic. I have
I've figured out that Update: It turned out that it was because of @benjamn Thanks again for your help! |
Bumping because I'm seeing this same problem when upgrading from I see this in the yarn lockfile:
So, although
|
Worked!!! Thanks. I was facing issue with latest version of @apollo/client
after resolving node_modules in webpack.config.js, it's working!!!
|
Intended outcome:
App compiles
Actual outcome:
App compilation is broken
App with the dependency of
@apollo/client@^3.3.2
fails to compile, here's the error output:I believe it's because the older
ts-variant
version is resolved.apollo-link
has a dependency on[email protected]
, while@apollo/client
relies on[email protected]
. Myyarn.lock
contains these two packages.Apparently, this is not true in my case.
Meanwhile, I've fixed it via
package.json
's resolutions:Versions:
System:
OS: macOS 10.15.7
Binaries:
Node: 12.18.2 - ~/.nvm/versions/node/v12.18.2/bin/node
Yarn: 1.22.5 - /usr/local/bin/yarn
npm: 6.14.8 - ~/.nvm/versions/node/v12.18.2/bin/npm
Browsers:
Chrome: 87.0.4280.67
Safari: 14.0.1
npmPackages:
@apollo/client: ^3.3.2 => 3.3.2
@apollo/react-ssr: ^4.0.0 => 4.0.0
apollo-datasource-rest: ^0.9.5 => 0.9.5
apollo-server-hapi: ^2.19.0 => 2.19.0
The text was updated successfully, but these errors were encountered: