-
Notifications
You must be signed in to change notification settings - Fork 142
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
Refactor the resolve function to be the only public api to module-resolver #1794
Conversation
0a7db59
to
ba9db49
Compare
Co-authored-by: Edward Faulkner <[email protected]>
b732e72
to
e8d94ad
Compare
any chance this refactor could land on stable first? I'd like to have one api to call from the code mod and not support maybe Promises maybe sync style nodeResolve |
To be honest, that's quite unlikely 😞 This is in the class of things where it could potentially break things but has very little gain to people who are not using Vite, and is the main reason why we forked stable from main.
I mean... I don't see any reason why you need to use stable for the codemod 🤔 why not use unstable? |
because I want to use the codemod and I use stable :) also it's more reasonable to give it to people who can't get to main and this could be the push/unblocker to get them there |
This is getting close. The remaining failure is in the vite-specific test, because as of this change we use the real esbuild and vite resolvers instead of the node resolver when locating components, and that is causing some trouble.
|
nevermind
in my testing, this has only been true when Maybe i've been confusing actual modules with not-quite-modules (js with no type=module) at least now we have a demo proving that self-imports are supposed to work 😅 |
The remaining failure here seems to be because our esbuild external-to-not-found workaround is too broad. It's causing a dep like qunit to be reported as not_found, when I think vite is telling esbuild that's it's external during depscan. |
No description provided.