search

vitejs / vite-plugin-vue2

Vite plugin for Vue 2.7
MIT License
549 stars 46 forks source link

feat: allow custom normalizer id #62

Closed cshawaus closed 1 year ago

cshawaus commented 1 year ago

Allow the normalizer identifier to be changed via the plugin options. This helps resolve a particular use case with AEM (Adobe Experience Manager) whereby its internal namespace validator incorrectly identifies _plugin-vue2:normalizer as an XML namespace.

The default behaviour will continue to use the existing behaviour while enabling developers to customise what this identifier is during builds.

haoqunjiang commented 1 year ago

That's weird. Does it only error on plugin-vue2:normalizer but not on plugin-vue2:hmr-runtime?

cshawaus commented 1 year ago

That's weird. Does it only error on plugin-vue2:normalizer but not on plugin-vue2:hmr-runtime?

@sodatea Yep, that is correct. HMR works fine because there is no deployment activity between Vite and AEM. It only fails on full deployments due to how AEM validates the contents of a package.

haoqunjiang commented 1 year ago

Could you provide a reproduction?

While I want this plugin to work well with AEM, I feel that simply allowing customizing normalizerId isn't enough. virtual:my-module is the conventional pattern of virtual module names in Vite, as recommended in the official documentation https://vitejs.dev/guide/api-plugin.html#virtual-modules-convention So even if this PR worked around the issue in @vitejs/plugin-vue2, there still will be problems with @vitejs/plugin-vue (\0plugin-vue:export-helper) and other plugins that use virtual modules.

cshawaus commented 1 year ago

@sodatea Apologies for the very prolonged delay in replying back to this issue. Until now we have been using a forked version of the package but I decided to spend some time working out how to create custom XML namespaces in AEM; low and behold I found a solution that eliminates this workaround in its entirety.

I also 100% agree with you that within the Vite ecosystem, these proposed changes only look to introduce side effects beyond just this one edge case.

For anyone using AEM and would like to know how this is solved, please refer to https://www.aemvite.dev/guide/backend/custom-namespaces/.