vite also needs to resolve index.{gjs,gts}

[patricklx]

blocked by #1876

[mansona]

This will likely be fixed by #1794, or at the very least we should add a failing test somewhere after that is merged before we make any more changes like this 👍

[patricklx]

this is the import that would fail to resolve

[patricklx]

one test failed while fetching node...

[ef4]

Idea here is that we should try switching at least the gjs/gts support to rely on vote's own resolve-extensions, so that it composes with vite's built-in index search.

We may or may not be able to do that for hbs given that within app code the hbs support is more complex, given the existence of template-only components, etc.

[patricklx]

somehow after adding the extensions to resolve.
the module-resolver resolveComponent is receiving type: ignore results...

[patricklx]

the commit 5559000 makes esbuild resolver behave the same as vite, when we have a not-found we report it as external.
now another issue:
all imports that are resolved via resolveWithinMovedPackage do not get dep optimization, because the importer is in node_modules. this causes the vite app to use duplicate modules @ef4

[patricklx]

I think for virtual files we want to add a suffix instead of a prefix. It should then be able to generate correct imports that use the dep optimization

[patricklx]

2 issues:

• resolveWithinMovedPackage changes importer to be in node-modules, which makes vite/esbuild ignore it.

1. solution: generate links to rewritten-packages that are resolvable via node resolution and just rewrite the request specifier
2. Change the specifier to a special prefix that will be treated specially? How?

• virtual modules start with a prefix, which changes all its imports to @id/fs/... full path. Can be fixed by using a suffix instead.

[ef4]

I think this is going to need pairing at office hours to sort through. Changing from prefix to suffix seems like a workaround for what is actually breaking.

[patricklx]