Skip to content
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

TODO: try not to use vite's createIdResolver #17

Open
dario-piotrowicz opened this issue Sep 19, 2024 · 1 comment
Open

TODO: try not to use vite's createIdResolver #17

dario-piotrowicz opened this issue Sep 19, 2024 · 1 comment
Assignees

Comments

@dario-piotrowicz
Copy link

dario-piotrowicz commented Sep 19, 2024

Currently we're using createIdResolver from vite to create module resolvers that we use in the module fallback service callback.

We should explore if we could instead use a separate third party solution (like import-meta-resolve, enhanced-resolve, resolve, etc...).


Why would that be beneficial?

  • The vite team exposed the createIdResolver utility especially for us, but this is not a utility that they would like to have to expose and maintain (discussion)
  • We could reuse our module resolution implementation in vitest-pool-workers whilst it still needs to use vite@5 (PS: this would be pretty valuable in the short/middle term, not at all in the long term as vitest-pool-workers should ideally just reuse our vite environment solution under the hood)
  • Our module fallback solution could become fairly generic, we could even externalize it in its own package and it could be used in non-vite projects (although I am not sure if/what use cases for this there are)
@dario-piotrowicz dario-piotrowicz self-assigned this Sep 19, 2024
@dario-piotrowicz
Copy link
Author

I'm kind of rethinking this... does it make sense for us to try to implement our own solution/reuse an existing third party one?

Ideally we, as any other environment author, would need to have the same exact module resolution for both dev and production. Vite already provides its own solution for the production side of things so reusing the same strategy, with the same exact options and behaviors for dev does make most sense.

Any third party solution would potentially try to mimic as close as possible the prod behavior in dev, which could be challenging and create a good amount of code that unnecessary re-invents the wheel and can potentially get out of sync with Vite's prod (built-in) behavior.

@dario-piotrowicz dario-piotrowicz transferred this issue from flarelabs-net/vite-environment-providers Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant