-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
documentation for server.deps.fallbackCJS
is confusing
#6352
Comments
Asking because I'm having an issue with vitest-fail-on-console, and it's unclear to me what the expected behavior of vitest is. |
I think the only way to correctly describe what this does is to understand this code vitest/packages/vite-node/src/externalize.ts Lines 29 to 54 in 85fb94a
And probably it's a typo of "invalid ESM package", but note that this fallback guessing is only a heuristics, so we cannot really say what is "invalid ESM package" or not. I think nowadays Regarding your main issue on thomasbrodusch/vitest-fail-on-console#59, I think their packaging is not ideal and goes wrong with "exports": {
".": {
"type": "./dist/index.d.ts",
"default": "./dist/vitest-fail-on-console.es.js"
}
} |
We're shipping both `./dist/vitest-fail-on-console.es.js` and `./dist/vitest-fail-on-console.umd.js` with "type": "module". Since Vitest only runs `esm` in the test environment (doesn't use require), we can only ship the default export as `./dist/vitest-fail-on-console.es.js` Thanks to @hi-ogawa - vitest-dev/vitest#6352 (comment)
We're shipping both `./dist/vitest-fail-on-console.es.js` and `./dist/vitest-fail-on-console.umd.js` with "type": "module". Since Vitest only runs `esm` in the test environment (doesn't use require), we can only ship the default export as `./dist/vitest-fail-on-console.es.js` Thanks to @hi-ogawa - vitest-dev/vitest#6352 (comment)
Describe the bug
In the main documentation:
I'm not sure what this means. If a dependency is valid ESM, why would it look for a CJS version? What does it mean to "have the wrong ESM file"?
The IDE documentation:
This seems to contradict the previous statement. Does this setting take affect when an ESM dependency is valid or invalid?
Reproduction
View the documentation
System Info
Used Package Manager
npm
Validations
The text was updated successfully, but these errors were encountered: