-
-
Notifications
You must be signed in to change notification settings - Fork 7.2k
Description
Clear and concise description of the problem
In development, there is a common workflow for linking a developing lib to vite app. I use these steps:
- Link
foo
pkg to global by executingpnpm link --global
underfoo
workspace. - Link in
foo
pkg to vite app by executingpnpm link --global foo
. - Continuously watch foo's modification and produce dist artifacts for debugging the program in vite side.
There are some issues with this usage.
-
The security machanism of vite disallows us import pkg which is outside of the vite app workspace. We have to configure the vite.config.ts through
server.fs.strict
orserver.fs.allow
. The most convenient way is to turn off the strict restriction in dev env. -
The vite optmizeDeps rules won't transpile the linked cjs/umd format lib to esm, caused by some my own reasons, we can't emit the lib as esm format. By comparison, if we publish the cjs/umd lib, vite can handle it well by the pre-bundle machanism.
-
We can't list the linked lib as the optimizeDeps in monorepo vite app, since vite bootstrap fails to force resolving the lib(it is located in pnpm-global).
-
Even if we have some ways to pre-bundle the lib, we expect to having the hmr machanism for debugging the lib or vite app.
There are some related issues/documents but not about linking local pkg.
Suggested solution
Some enhancement or doc guidance to this workflow.
Alternative
No response
Additional context
No response
Validations
- Follow our Code of Conduct
- Read the Contributing Guidelines.
- Read the docs.
- Check that there isn't already an issue that request the same feature to avoid creating a duplicate.