Legacy plugin not compatible with vite 2.7.x

[elmassimo]

Legacy plugin not compatible with vite 2.7.x

[StefSchenkelaars]

@khalwat I created a PR for my commit anyway at vite. Mainly to get the discussion going there ;)
See: vitejs/vite#6208

[ElMassimo]

Hi Stef! Thanks for providing a detailed report!

I'll follow up with a comment in the pull request, thanks!

[ElMassimo]

Released [email protected] and [email protected].

[khalwat]

Are we sure this isn't a regression/mistake in Vite? \u0000 is the Unicode character for null which makes me think it could potentially be a mistake on their end?

I see your link where the modules are prefaced with the id as per: https://github.com/vitejs/vite/blob/e19ba6a98d85586d1f54e6b0eed11dcf72e6c651/docs/guide/api-plugin.md#conventions

...but I'm not sure that's what is going on here, because that's 0 as an id is a different thing than null

[StefSchenkelaars]

Well I'm not a sure but when I started on fixing this issue in vite itself, I found that there was more code surrounding this and not just a simple typo. I created a fix within vite but I wasn't really sure on how to properly write a test / spec for this. If you look at the commit that introduced the character, it is also explicitly checked in the build step. But I agree with you that the difference between the \u0000 character and the 0 are indeed interesting.

So in short: I'm not sure but it works 😅

[khalwat]

hmmmm you're right, this does look done on purpose: vitejs/vite@3127219

But I wonder if something isn't amiss with, however \0 gets translated into \u0000 during the build process, because the latter is what ends up in the manifest.json

I'd think that this is what we should end up using:

const polyfillId = '\0vite/legacy-polyfills'

Rather than:

\u0000vite/legacy-polyfills

[khalwat]

In vite 2.7, the name of the legacy-polyfills entry has changed from "../../vite/legacy-polyfills" to "../../\u0000vite/legacy-polyfills". This filename has changed since this polyfill is a so called virtual file (as explained in the plugin api docs).

One thing to note from the API docs is that it says:

Internally, plugins that use virtual modules should prefix the module ID with \0 while resolving the id, a convention from the rollup ecosystem. This prevents other plugins from trying to process the id (like node resolution), and core features like sourcemaps can use this info to differentiate between virtual modules and regular files. \0 is not a permitted char in import URLs so we have to replace them during import analysis. A \0{id} virtual id ends up encoded as /@id/x00{id} during dev in the browser. The id will be decoded back before entering the plugins pipeline, so this is not seen by plugins hooks code.

So this id prefixing is internal and should be undone before it is saved out to the manifest.json I'd assume. Sounds like something isn't quite right with this round-trip, at least as far as productions builds with manifest: true are concerned.