last night I’ve spent hours to install Meteor from scratch on our development server. It’s not the fastest system as the /home partition is mounted via NFS, and so it took hours for the standard installation procedure. Actually,
I saw many similar files and analyzed the installation a little bit further today.
There are files like es6.math.acos.js, part of meteor-esmascript-runtime, which are more than 800 times in the archive. Counting the files existing more than 20 times gives about 60,000 files of the overall 112,000 files. The installation contains only about 17,000 different files.
So, removing duplicates would improve the installation speed by a factor of 6.
I don’t know why the application, especially the installation package, is built in the way it is, but keeping an eye on this issue would improve the developer experience for new developers as well as reduce the times for updates, as I saw similar issues there.
I’d like to help sending a PR, but I don’t feel comfortable doing such a huge change without understanding more of the architecture of these inner parts.
At least, I circumvented the low performance of the /home partition (NFS) by putting the Meteor installation into /opt/meteor (local partition) and setting
export METEOR_WAREHOUSE_DIR=/opt/meteor
The tar ball extraction was 100 times faster, and meteor update is super fast now
Correct me if I’m wrong but basically, each Meteor package has their own node_modules NPM directory, which can contain duplicated NPM packages across Meteor packages. Depending on the Meteor package, the versions of the contained NPM packages can differ. I believe this duplication will be resolved when Meteor moves to the NPM eco system.
And modules in node_modules may contain their own node_modules directory again. There are files in the archive containing eleven times node_modules in the path
I also expect that moving to NPM would solve this issue.
Hopefully, the NPM way of installation is as easy as the current one. I really like to demonstrate the simplicity to get a running Meteor installation in workshops
It’s solved when we move to the “npm eco system” on a recent version number. This particular idiocy only came about because npm version 1 wasn’t able to do dependencies other than by putting said dependencies into subfolders. And if the dependency had dependencies of its own, it put those into another subfolder. And shared dependencies are ignored - if 5 modules need a particular dependency, it gets pulled in five times, by Jove!
It was obviously a quick’n’dirty solution which should never have seen the light of production.
It also makes deleting those folders on Windows a particular delight because nesting node modules 5 levels deep runs into the “255 character limit for directory names” pretty quick.
