Rename #embroider_compat/* to @embroider/virtual/*

[BlueCutOfficial]

Rename #embroider_compat/(component|helper|modifier|ambiguous)/<path> for invokable to @embroider/virtual/(component|helper|modifier|ambiguous)/<path> to stop confusing esbuild.

• Implement the rename by looking for references to #embroider_compat.
• shared-internals/src/paths.ts: pay attention to const postfixRE = /[?#].*$/s; that used to match #embroider_compat pattern: if we no longer have any request from a file starting with #, then there's no reason to separate postfixRE and postfixREQueryParams cases. cleanUrl('@embroider/virtual/fancy?query="p"', false) returns @embroider/virtual/fancy and we no longer need a special pattern to have a #embroider considered part of the path name.

[patricklx]

is this because otherwise it wont pass the bare import filter in vite internal dep scan hook?

[BlueCutOfficial]

Yes 👍

[patricklx]

Okay, just note that there are multiple ways to refer to the same file

• embroider_compat/helpers/addon-helper

• app-template/helpers/addon-helper
• ./helpers/addon-helper

For each esbuild would generate a separate bundle id. I'm not entirely sure if it also generates different chunks or just generates another file which imports the same chunks. But it would be less efficient anyway.

So. I'm not sure how much this would help in the end. Short term to get more scan through esbuild. It looks nicer at least :)

Furthermore, when adding new import during dev, vite additionally checks if the import is resolvable with default node resolve and only then makes a new dep scan on it.

We would need to alias all of those to one same import specifier and make it node resolve able.

[ef4]

This is not going to be necessary. The work in https://github.com/embroider-build/embroider/pull/2029 demonstrates that we can do full resolution in our esbuild plugin before vite's depscan sees anything.