let's allow only string context, by default - compiler.context, otherwise virtualConfig.context

I’m curious why this isn’t true by default 🤔, like auto, where we automatically set the context for virtual modules. Since the virtual module ID and the context value are almost the same, it feels like setting the same value twice. I’d prefer to minimize users’ exposure to the context option unless there’s a very specific use case.

I agree, that is why I think we don't need support function and true type, only string, also I don't think we need to check on undefined we by default use compiler.context

Makes sense. For now, I’ve kept only the default value "auto". This avoids requiring users to configure the context option and also prevents configs from being cluttered with repeated "auto" values, like { mod1: { context: "auto", source() {} }, mod2: { context: "auto", source() {} }, mod3: { context: "auto", source() {} } }.

I am afraid that it is a breaking change, auto is the new behavior, old virtual modules can be broken, right?

Do I understand correctly this feature, if I have /path/to/src/components/button.js, context will be path/to/src/components/?

This won’t affect existing virtual modules. Previously, virtual module paths like "virtual:routes" were only used as unique IDs, and their context was always fixed to compiler.context. With context: "auto", for "virtual:routes" the computed context is still compiler.context, so nothing changes.

Now we’d like to extend virtual module paths so they’re not just IDs, but virtual paths with context information — for example, virtual:src/components/button.js. In that case, the context would be resolved to something like /path/to/src/components/button.js.

@xiaoxiaojx Got it, I see the default value should be auto, but I don't see this in our code

@xiaoxiaojx If I understand correctly, I agree with @alexander-akait that this is a breaking change, because if anyone was already using slashes in their virtual module ID, the context will now be different.

I think that's a reasonable breaking change, though :)

Let's move validate under the new hook for such things

There is an interesting question, change this potentially can break existing code for developers which already use it (right?). So we should decide it is a fix (and our current behavior is wrong and it should be auto by default) or do not change it by default on auto, what do you think?

Yeah, the default "auto" might not be the best choice. It was originally set to avoid having to configure the context option for every module. I recently did a small refactor here and added a fallback options to provide default settings.