Closed genffy closed 3 years ago
Nuxt3 case, nuxt/bridge#204
Vite docs specifically warn about using global
here: https://vitejs.dev/config/#define, because it is common to want to use define in this way. But this isn't a Vite issue.
Because it's implemented as straightforward text replacements without any syntax analysis, we recommend using define for CONSTANTS only. For example,
process.env.FOO
and__APP_VERSION__
are good fits. Butprocess
orglobal
should not be put into this option. Variables can be shimmed or polyfilled instead.
@antfu @pi0 closing this issue, as it is already tracked in nuxt/bridge#204
This define rule should be removed, let's see what that was trying to workaround, maybe it isn't needed anymore: https://github.com/nuxt/framework/blob/bf716f39783508e001a590c01956ac57937f6bd2/packages/vite/src/client.ts#L21
@patak-js Indeed makes sense to be fixed on the Nuxt side but how do you suggest to shim process
and global
for client modules?
BTW worth mentioning rollup's replace plugin uses escape to prevent some edge cases like this (https://github.com/rollup/plugins/blob/master/packages/replace/src/index.js#L44)
shimming can be done in html file by writing window.global = window
or window.global = globalThis
issue should maybe be reopened again to improve define
so it won't touch file names. I remember a similar issue, I'll try digging after it
About the process, and other node builtins in general, it is an issue for Vite in general. I think the ideal would be to invest time in getting something like https://github.com/snowpackjs/rollup-plugin-polyfill-node to work smoothly in Vite (this was working for Snowpack IIUC, so I think it should be an option). I think the community hasn't spent time in this because most of these cases end up being solved by switching an old dependency to a modern alternative, or by fixing the dep so they don't depend on node builtins.
About improving the regex, we have been merging small changes there. If there is a PR, we can check it with Evan.
@Niputi the paths are replaced in import statements, no? In that case, I think it is working as expected
@patak-js it was this issue I remembered https://github.com/vitejs/vite/issues/4796 which seemed like define
renames file names.
Thanks for the pointers @patak-js @Niputi. For now, I decided to remove global
replacement until finding better replacement (https://github.com/nuxt/framework/pull/1835)
shimming can be done in html file by writing window.global = window or window.global = globalThis
This seems a good idea. I would polyfill using globalThis.global = globalThis
which works similarly but also in workers (envs that are neither Browser nor Node.js).
About the process, and other node builtins in general, it is an issue for Vite in general. I think the ideal would be to invest time in getting something like https://github.com/snowpackjs/rollup-plugin-polyfill-node to work smoothly in Vite (this was working for Snowpack IIUC, so I think it should be an option). I think the community hasn't spent time in this because most of these cases end up being solved by switching an old dependency to a modern alternative, or by fixing the dep so they don't depend on node builtins.
I would be more than happy to help with this. With Nuxt 3 and Nitro, we had to create a Node.js shimming framework unjs/unenv. It basically returns a framework agnostic preset of shims and polyfills. It already covers common use cases but I tend to increase Node.js coverage including fs
support (Unimplemented shims are deep-mocked using mock/proxy .
Before starting unenv, I tried rollup-plugin-polyfill-node
which is great but assuming to polyfill "Node for Browser" and based on browserify implementations which was not convincing at least for Nuxt since we needed Worker support as well.
We plan to use unenv for Nuxt 3 with vite soon (https://github.com/nuxt/nuxt.js/issues/12786) will let you know how it goes and (probably adding process
and global
shims in the same PR)
Regarding this issue, I let you judge worth improving on vite's side or not. The behavior seems expected for replacement -- however vite could cover more edge cases and bade replacements out of the box on the other hand, it can add more codebase complexity.
https://github.com/unjs/unenv looks great @pi0, and it would be great for Vite if there was an easy way to drop it in as a Vite plugin or something similar so we could recommend if users are facing issues with their deps. I still think that long term we should keep pushing for the ecosystem to fix this in each package, but this could alleviate a lot of temporal pain.
@patak-js , As @pi0 mentioned, I recommend vite to add dev mode warning for define’s key that contain some private or inside keywords in JavaScript. That is if no plan to make this replacement smoothly.
Describe the bug
if some lib, folder or file-name have some keyword defined in
define
property, and runvite build
will casue[vite]: Rollup failed to resolve import
error.After checked source code and found some casue on follow picture.
Reproduction
open this link https://stackblitz.com/edit/vite-hxw2x7 and see
Terminal
outputSystem Info