I recently made a post about the issue of having node_modules calculated in the project size folder found: Smarter storage functionality
The staff replied back quickly stating they already have plans in place to fix this issue, I believe I also have a solution after working around with nodejs for a few days.
Currently, each user is given a workstation to administrate various types of nodejs applications or web services, the project dependencies are downloaded from NPM on document change, similar to what you will find with “gulp” to always host an updated revision of the site.
I believe we can apply the same concept with the package management. I believe it can be achieved through “Lerna Hoisting” where packages that are declared are called from a singular distribution that multiple workstations can access for their own applications. Hoisting refeers to scooping the packages in the node_module folder to a superglobal position on the filesystem that other workstations can simply share them instead of downloading their own.
Lerna can reduce the time and space requirements for numerous copies of packages in development and build environments, by “hoisting” shared dependencies up to the topmost, Lerna-project-level node_modules directory instead.
https://github.com/lerna/lerna/blob/master/doc/hoist.md
Okay cool, so we got a concept down called hoisting that removes the need for workstations to host their own modules as each declaration is essentially symlinked to a globally accessible version on the network reducing storage costs. How do we make the workstations be better overall to support this?
Thats where the Lema part comes into play in this fix idea, the package describes itself as “A tool for managing JavaScript projects with multiple packages.” which is underselling it if you ask me…
https://github.com/lerna/lerna
They do go into detail about the purpose of the package, stating that "…making changes across many repositories is messy and difficult to track, and testing across repositories gets complicated really fast.
To solve these (and many other) problems, … Projects like Babel, React, Angular, Ember, Meteor, Jest, and many others develop all of their packages within a single repository.
Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.
Lerna can also reduce the time and space requirements for numerous copies of packages in development and build environments - normally a downside of dividing a project into many separate NPM package."
So Lema is basically a package manager that operates as a high-level proxy for NodeJS packages, this proxy operates as a cache allowing one package to be stored nearby and accessible to all removing the need for any future project to need a god damn node_modules folder…
Concluding, having our node applications run on Lema would reduce the overall project size allowing developers to spend more time on them, I believe if this concept can be extended further, if Glitch decide to try to the hoisting approaching and start centralizing packages away from personal projects, I believe the service can benefit from technology that is applied in magic_ws which is basically Lerna for which its a package manger and proxy services but while Lema was for low level language implimentation, magic workshops semver on the enviroments and containers that they are operated in.
One of the main features on magic-ws is hot-swappable modules with multi workstation linking allowing groups and and policies to be created.
I shall leave you with a paragraph of the magic-ws description which hopefully enlightens everyone from my point of view on the matter.
"Magic Workspaces form a Virtual Environment
magic-ws is very robust since it forms something akin to a virtual environment where these hot-swaps happen. This means you can run any script that eventually calls into node and the swapping will still work (that’s why the npm example above worked). Additionally, if the node process execs, spawns, or forks, those too will keep the hot-swaps. Again, all this happens without actually mutating your code, so you could for example run your code’s test suite normally and with magic-ws in parallel."