-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Revert normalizeNonRelativeId
changes in config/resolveModuleIds.ts
#9073
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
0fe31cc
to
df7be26
Compare
I can confirm these changes still allow await import("https://cdn.jsdelivr.net/npm/@apollo/client@3.6.0-beta.0/core/+esm") |
brainkim
approved these changes
Nov 16, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I'm still getting an error from webpack after upgrading to 3.5.3
|
@SimenB Also seeing this in our internal stuff. We’re on it! |
benjamn
added a commit
that referenced
this pull request
Nov 18, 2021
From @apollo/client@3.5.0 until my recent PR #9073 (v3.5.3), non-relative imported module identifiers like 'ts-invariant/process' were rewritten during the build process (during 'npm run resolve') to include a specific module with a file extension (not a directory), producing in this example 'ts-invariant/process/index.js'. That rewriting was the wrong choice in general (for example, it would rewrite 'graphql' to 'graphql/index.mjs'), so PR #9073 disabled it for all non-relative imports. However, the specific replacement of 'ts-invariant/process' with 'ts-invariant/process/index.js' is still useful to prevent the strange webpack 5-specific error The request 'ts-invariant/process' failed to resolve only because it was resolved as fully specified which apparently happens because the [resolve.fullySpecified](https://webpack.js.org/configuration/module/#resolvefullyspecified) option is true by default now, and 'ts-invariant/process/package.json' is ignored, effectively forbidding directory-style imports like 'ts-invariant/process' when the package.json of the enclosing package has `"type": "module"` (which became true in Apollo Client v3.5, thanks to #8396). App developers could configure resolve.fullySpecified explicitly false, but we (the Apollo Client team) prefer a general workaround.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This reverts commit 60e18e9 from PR #8396.
In theory, commit 60e18e9 should have made it easier to consume
@apollo/client
ESM modules in a browser environment, by rewriting non-relative imported module identifiers liketo
effectively bypassing
react/package.json
and its"main"
field (which is not understood by browsers). Of course, thereact
package doesn't actually export ESM modules, and therefore can't be used natively in the browser anyway, so the rewriting doesn't help in this case.Not helping would be one thing, but unfortunately this change introduces more problems for bundlers that expect to find a
package.json
file when importing non-relative dependencies. For example, webpack complains thatreact/index.js
does not export functions such asuseState
(a fair criticism, sincereact/index.js
is a CommonJS module).Reviewing the commit message from 60e18e9, the only third-party package it names as benefitting from this extra resolution step is
ts-invariant/process
, which is a package we control and therefore can fix if necessary. My plan is to merge this PR intorelease-3.6
so we can do some additional testing of beta releases before backporting this change to v3.5.x (themain
branch).Here's a diff of
import
changes generated as a result of this PR, all of which seem reasonable to me: https://gist.github.com/benjamn/31c6ca0d61ca12bd42f08d3c6e6ef42b