-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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
fix(resolve): always use module
condition
#13370
Conversation
Run & review this pull request in StackBlitz Codeflow. |
da0652e
to
594a48f
Compare
import { msg as exportsWithModuleCondition } from '@vitejs/test-resolve-exports-with-module-condition' | ||
import { msg as exportsWithModuleConditionRequired } from '@vitejs/test-resolve-exports-with-module-condition-required' |
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.
This fails when running pnpm run test-build
but it works with cd playground/resolve && pnpm run dev
(thanks to adding @vitejs/test-resolve-exports-with-module-condition-required
to optimizeDeps
here). How should I configure the actual test script to do the right thing here (to process linked CJS modules)?
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.
If the dep needs to be optimized during build time, you could set optimizeDeps.disabled: false
in the config (the default is disabled 'build'). But I think we may need to move these tests to the optimize-deps playground though as we aren't yet testing deps optimization at build for all playgrounds (it is an experimental feature).
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.
What I don't understand though is the fact that there are some other CJS modules in playground/resolve
. So it seems like should be possible to keep this test here (I feel like it belongs to this particular test suite, otoh - if that's problematic in the current setup... it's definitely not something worth fighting for). Do you happen to know what's the difference between those other tests and this one?
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.
It was only if you needed the dependency to be optimized during build time. We're currently only testing deps optimization at build time in the optimize-deps
playground (or when using the test-build-without-plugin-commonjs
script). By default deps aren't optimized during build and plugin commonjs is used to do interop.
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.
Hm, so I don't really want to get those deps optimized anyhow (I think?), i'd only like to apply commonjs interop here. Or is the 'module'
condition handling part of the optimizations in Vite?
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.
It works fine during build if you use index.cjs
instead of a .js
file in the @vitejs/test-resolve-exports-with-module-condition-required
. This is also how other CJS packages are constructed in the resolve playground. I thought yours should work too though.
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.
Thanks for the tip. I changed the extension and it seems to work now - the CI should pass shortly
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.
Another way is to use the file:
protocol like "file:./exports-with-module-condition-required"
in the package.json
so it's hardlinked instead, but either way also works fine.
@sapphi-red would you check this one when you have some time? If I recall correctly you also wanted to apply this change. |
594a48f
to
716ca9a
Compare
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've been confused of how the module
condition work because the webpack docs doesn't really explain it well. I didn't know esbuild supports it too, and as usual it has excellent docs 😄
/ecosystem-ci run |
📝 Ran ecosystem CI: Open
|
Would this also fix #11389? |
Note that I'd consider part of those docs to indicate a problem with It seems though that the only current choices for the platform are node, browser and neutral. Neutral is supposed to be "please configure everything yourself". So I guess that this is somewhat OK right now but I'd consider the wording to be misleading as other projects might assume incorrect semantics based on that sentence. Relevant code in esbuild: https://github.com/evanw/esbuild/blob/e6a8169c3a574f4c67d4cdd5f31a938b53eb7421/pkg/api/api_impl.go#L1409-L1412
Should I be worried about the failures here? or are those flaky?
Yes. I verified this manually and marked this PR as closing that issue. |
Marko and Nuxt are also failing in main right now. Qwik is green there though https://github.com/vitejs/vite-ecosystem-ci/actions/runs/5129068924/jobs/9226347832 I'll re-run qwik now. We're about to start the beta for 4.4, so maybe we could merge it there. |
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.
Qwik was a glitch, it is green after re-running. I think we could still include this in a patch for 4.3. @sapphi-red what do you think?
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.
Thanks 💚
This current behavior has existed for a long time, so I vote to wait for Vite 4.4 just to be sure: 39820b9#diff-9b81bb364c02eab9494a7d27a5effc400cacbffd3b8f349c192f890c37bfc83fL543-R560
1d002cb
Description
In this PR I remove filtering out of the
module
condition. It's a condition specifically meant to help package authors have their packages consumable usingrequire
andimport
in bundlers while avoiding the dual package hazard.Additional context
@garronej has found this bug in Vite here: https://github.com/garronej/vite-dual-package-repro-repo . This affects Emotion and all UI libraries built on top of it.
How Vite handles this right now is inconsistent with other bundlers (such as webpack, Rollup with its
@rollup/plugin-node-resolve
, bun, and esbuild).What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123
).cc @bluwy @patak-dev
fixes #11389