feat(import-glob): support read module from alias pattern

[sun0day]

Description

refs #12180

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[sun0day]

Can you help review this pr ? @bluwy @sapphi-red Thanks.

[patak-dev]

After this PR, the resulting obj from import.meta.glob will have duplicated entries for each module, no?

const jsons = import.meta.glob('@/jsons/*.json', { eager: true });
// jsons have both jsons[`@/jsons/1.json`] and jsons[`/src/jsons/1.json`]

We could only include the aliased path but I think this may be more confusing that the current behavior. Maybe what we need here is to update the docs to be explicit about an aliased path in glob returning absolute paths?

[sun0day]

Yeah, it will have duplicated entries for each alias module. Reserving two entries is for compatibility. Will this be more confusing? I think it's intuitive that visit a module via alias path while using alias pattern in import.meta.glob

[patak-dev]

Having both isn't possible because then users would need to de-duplicate them. Imagine if they do a glob and iterate over the result to do something with each.

So if we change something, I think the paths could keep the alias instead of using absolute paths. But I don't know how much ergononic is to have the unresolved path as the key instead of the absolute path here. cc @brillout @antfu, interested in your opinion here.

[brillout]

I think we should preserve the path format. In other words:

• If the glob path is relative => return relative paths.
• if the glob path is absolute => return absolute paths.
• If the glob path contains an alias => return paths containing the same alias.

The pro here is that the user has the flexibility to choose the format. And, AFAICT, I don't see any drawback for this.

I believe that's what we decided back in the days of vite-plugin-glob (but correct me if I'm wrong @antfu).

Having both isn't possible because then users would need to de-duplicate them. Imagine if they do a glob and iterate over the result to do something with each.

Agreed.

I think the paths could keep the alias instead of using absolute paths

I think so too.

But I don't know how much ergononic is to have the unresolved path as the key instead of the absolute path here

If the user wishes to have absolute paths, then he can provide an absolute glob path instead of an aliased one.

[bluwy]

I've been thinking of a solution for this, I feel like the current behaviour while strange is able to scale to more cases. For example,

import.meta.glob(['@/data/*.json', '!@/data/draft.json', './extras/*.json'])

It would be hard to determine what the keys should be. Some will have aliases, some will not. Today, the keys for this is ['/src/data/one.json', '/src/data/two.json', '/src/pages/extras/one.json'].

The keys are root-relative if one of the globs are not relative.

---

So to summarize and document how it works today:

1. If the globs are all relative, the keys will be relative to the file.
2. If one of the globs are not relative, the keys will be relative to the root (with root-relative syntax).
3. For virtual files, the keys will also be relative to the root (makes sense in general).

If we want to change something, I think we need to add compat keys to prevent a big breaking change, maybe through a Proxy. But in this case, I think documenting it should be enough.

[bluwy]

I'll move this off the Vite 5 milestone for now. From the above comment, we could start with a documentation update. If we want to change the behaviour, we might need to plan out a migration path and some sort of compat so it doesn't cause a big breaking change.