You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fix for #17582 was reverted so we should re-open it - but it is currently locked, so I thought I'd just create a new one to restart the conversation.
Not enabling per-environment aliasing creates a lot of friction as we move into a Vite Environment world where it is quite likely that each environment would need to alias imports differently depending upon the Environment it is targeting.
The current workaround is to alias these APIs to a virtual module, which is then processed in a resolveId() hook. But not only does this add complexity to the plugin, making it harder to understand, debug and maintain, it also doesn't appear to work well with pre-bundling of dependencies, where the id are not being resolved during the import analysis stage, since the pre-bundler is using a "top-level configuration" which doesn't trigger the plugin's resolve hook.
Suggested solution
The solution proposed in #17582 was to allow aliases to be provided per-environment. But in #18005 it was said that "it isn't clear if this option should be per-environment, as it may require other tools reading Vite aliases to be aware of environments."
So it is not clear to me what the solution is, but also why per-environment aliases are different to other per-environment options.
Actually, we have reworked out Node.js compat support not to need Vite aliases, so this is no longer a necessity for us.
Feel free to close if this is not something you want to implement.
Description
The fix for #17582 was reverted so we should re-open it - but it is currently locked, so I thought I'd just create a new one to restart the conversation.
Not enabling per-environment aliasing creates a lot of friction as we move into a Vite Environment world where it is quite likely that each environment would need to alias imports differently depending upon the Environment it is targeting.
For the Cloudflare Vite Plugin, the obvious example is polyfilling Node.js APIs. Our plugin needs to alias some Node.js APIs to polyfills but this is not appropriate for the client environment, nor for other possible environments running on different backends (e.g. Node.js itself). See https://github.com/cloudflare/workers-sdk/blob/ed3bc2f3be45be55d20299ed3f481e75c63ba285/packages/vite-plugin-cloudflare/src/node-js-compat.ts#L77-L86
The current workaround is to alias these APIs to a virtual module, which is then processed in a
resolveId()
hook. But not only does this add complexity to the plugin, making it harder to understand, debug and maintain, it also doesn't appear to work well with pre-bundling of dependencies, where the id are not being resolved during the import analysis stage, since the pre-bundler is using a "top-level configuration" which doesn't trigger the plugin's resolve hook.Suggested solution
The solution proposed in #17582 was to allow aliases to be provided per-environment. But in #18005 it was said that "it isn't clear if this option should be per-environment, as it may require other tools reading Vite aliases to be aware of environments."
So it is not clear to me what the solution is, but also why per-environment aliases are different to other per-environment options.
How can we help with moving this feature forward?
Alternative
No response
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: