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.