Nice article @areknawo
!
I'm wondering why having the downloaded modules stored out-of-sight, somewhere on your machine is better than having the node_modules folder? To me seems like one is visible and the other an invisible black-hole-like :)
The link to Tokio is not working.
Your article sparked my curiosity. My next POC will be built in Deno! I find very funny the why of the name of this new runtime.
Thanks!
Thanks!
I've already fixed the link to Tokio.
As for external modules, Deno has a single directory on your disk to serve as a cache for all the URL-referenced dependencies. In this way, you only download them once per the specified version. This results in a single dependency of the given version being accessible right from the cache across multiple Deno projects. Also, more optimizations can be applied to the cache's structure, while keeping it away from the user.
So, to summarize the advantages of this approach:
no duplicate dependency downloads - even across multiple projects
greater potential for structural optimizations of the cache
no need to see the node_modules black hole ever again ;)
I tried to solve that problem in my projects using docker with a shared mount volume. It worked, but only when the dependencies of the projects where the same, and usually they aren't, then I needed to reinstall all the dependencies when switching from one project to another. No the best developer experience :)
When using Yarn after have downloaded the packages the first time the reinstallation was really fast because of the global cache that Yarn creates as @simonhaisz
mentioned.
This world of dependencies management is really big :)
Thanks for the response!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article @areknawo !
I'm wondering why having the downloaded modules stored out-of-sight, somewhere on your machine is better than having the node_modules folder? To me seems like one is visible and the other an invisible black-hole-like :)
The link to Tokio is not working.
Your article sparked my curiosity. My next POC will be built in Deno! I find very funny the why of the name of this new runtime.
Thanks!
Thanks!
I've already fixed the link to Tokio.
As for external modules, Deno has a single directory on your disk to serve as a cache for all the URL-referenced dependencies. In this way, you only download them once per the specified version. This results in a single dependency of the given version being accessible right from the cache across multiple Deno projects. Also, more optimizations can be applied to the cache's structure, while keeping it away from the user.
So, to summarize the advantages of this approach:
node_modulesblack hole ever again ;)Yarn already caches download packages globally. But because of how node works these are duplicated in all of the projects that use them.
True, but this duplication is where the real difference is.
I tried to solve that problem in my projects using docker with a shared mount volume. It worked, but only when the dependencies of the projects where the same, and usually they aren't, then I needed to reinstall all the dependencies when switching from one project to another. No the best developer experience :)
When using Yarn after have downloaded the packages the first time the reinstallation was really fast because of the global cache that Yarn creates as @simonhaisz mentioned.
This world of dependencies management is really big :)
Thanks for the response!