-
Notifications
You must be signed in to change notification settings - Fork 125
rspack/webpack virtual modules can't do relative import #483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
/cc @SoonIter @chenjiahan |
I've also just verified that the same issue occurs in webpack, in a NextJS project. I think these are the two targets that use virtual modules in this way. |
@hardfist cc |
the current virtual module implementation in rspack is not ideal and should be implemented on top of compiler.inputFilesystem which will not change the original path so the resolve behavior should not be affected. |
@hardfist Thanks for your response. Yes, verified. I just built a clear production repo: https://github.com/edemaine/unplugin-rspack-relative-import
With webpack, the virtual modules seem to resolve to the root directory of the project (instead of |
I'm not sure whether it's a unplugin bug or civet plugin bug but then the right resolved path is thrown away |
after some investigation, I think the root cause is here https://github.com/unjs/unplugin/blob/main/src/webpack/index.ts#L123, and it's very tricky to move virtual module path to node_modules/.virtual, I'm gonna try to align webpack's implementation with rollup's and don't change the original directory folder to support virtual module, but i may take some time |
Environment
[email protected]
Node 23.4.0
Windows 11 version 10.0.26100 Build 26100
Reproduction
Repo: https://github.com/edemaine/unplugin-rspack-relative-import
Run:
npm install
npm run build
Error:
Describe the bug
From #416 I gather that webpack/rspack virtual modules get put inside
node_modules/.virtual
. Then the relative import of./index.css
is getting resolved within that directory, which fails.Additional context
I tried logging calls to
resolveId
, and I see the following:This suggest to me that the virtual prefix is getting stripped incorrectly on Windows; I don't think the leading
\
should be there. #421 might be the same issue, and #422 might fix this.But I don't think that this is the cause for this particular bug. rspack itself isn't going to strip virtual module names; only unplugin will. So rspack is going to resolve relative paths incorrectly, unless they're handled by an unplugin. I'd rather not have my unplugin help resolve all files, only the ones it's supposed to do (
.civet
).I guess the workaround is for my unplugin's
resolveId
to fix the paths for all imports, perhaps when theimporter
is recognized as something my unplugin generated.I think a better fix would be to put virtual modules in the same directory as the source file. I understand that the
node_modules/.virtual
choice was made to avoid it appearing in VSCode or Git. But I don't see how relative imports could work in this scenario.Let me know what you think and I can try to work on a fix.
The text was updated successfully, but these errors were encountered: