You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Deno's npm integration doesn't create a local "node_modules/" directory in each project, instead it uses a single global cache just like in case of "http"/"https" imports. This is great for a lot of users who provided feedback on the feature, however it causes some problems when trying to run certain project.
As an example, if we have a frontend project that is build with vite, then vite's bundler (rollup) expects that all packages will be available in "node_modules/" directory in the project root directory. Because of this fact, currently users need to npm install when using vite in Deno (#15427 (comment)).
Ideally we'd be able to tell these tools to use Deno's cache, but it's sort of "chicken and egg" problem, maintainers of these tools might be reluctant to add additional codepaths when there isn't much usage of these tools in Deno. On the other hand, even if maintainers were willing to do that, we are missing certain APIs to obtain a path to cache (one can do that, by spawning a subprocess with deno info subcommand).
To fix this problem, I propose we add a flag (let's name it "--symlink-npm" for the sake of discussion) that would create a "node_modules/" directory with symlinked packages that reside in the Deno cache (controlled by DENO_DIR env var). This would work similar to pnpm package manager, which also maintains a single copy of each package on the machine.
Such flag would be an escape hatch for users who really need to have "node_modules/" directory but wouldn't be a burden for users who don't need (and actually might prefer not to have it).
The text was updated successfully, but these errors were encountered:
Deno's npm integration doesn't create a local "node_modules/" directory in each project, instead it uses a single global cache just like in case of "http"/"https" imports. This is great for a lot of users who provided feedback on the feature, however it causes some problems when trying to run certain project.
As an example, if we have a frontend project that is build with
vite
, thenvite
's bundler (rollup
) expects that all packages will be available in "node_modules/" directory in the project root directory. Because of this fact, currently users need tonpm install
when usingvite
in Deno (#15427 (comment)).Ideally we'd be able to tell these tools to use Deno's cache, but it's sort of "chicken and egg" problem, maintainers of these tools might be reluctant to add additional codepaths when there isn't much usage of these tools in Deno. On the other hand, even if maintainers were willing to do that, we are missing certain APIs to obtain a path to cache (one can do that, by spawning a subprocess with
deno info
subcommand).To fix this problem, I propose we add a flag (let's name it "--symlink-npm" for the sake of discussion) that would create a "node_modules/" directory with symlinked packages that reside in the Deno cache (controlled by
DENO_DIR
env var). This would work similar topnpm
package manager, which also maintains a single copy of each package on the machine.Such flag would be an escape hatch for users who really need to have "node_modules/" directory but wouldn't be a burden for users who don't need (and actually might prefer not to have it).
The text was updated successfully, but these errors were encountered: