81–90 of 105 posts
32,000 files for a hello world... jeez, i'm going back to java.....
Not a lot better: $ unzip -l /usr/java/jdk1.8.0_77/jre/lib/rt.jar | wc -l 20138 It's just less of a burden on the host filesystem because those files are usually loaded straight from the jar (i.e. zip file).
Why isn't npm managing packages like ruby gems? SHARED_DIR/npm_modules/NAME/VERSION
Because package-lookup and the package manager are 2 completely separate systems in javascript. When you `require` or `import` a file in node.js, it looks for a node_modules and looks for that name in there. If it can't find it there, it starts walking up the directory tree until it finds something it can use (to a point). This is hardcoded and will be extremely difficult to change without a crazy amount of breaking.…
Earlier quoted context omitted.
Buble's purpose is that it is supposed to be significantly faster to compile from ES6 to ES5 with minimal configuration, since it actually does things out of the box.
But that has nothing to do with it's size. If Buble was 10% larger than Babel it would still solve it's purpose.
Although there definitely is a performance cost to Babel's large dep tree as each of these modules have to be found by Node (which is inefficient). If you use Babel with npm2 it is super slow, because npm2's folder structure causes more lookups.
This person is counting the node_modules directory. While JS is a bit insane and this directory will have a ridiculous number of files, they are concerned: "because my deployment (google app engine) allows only 10K files" meaning, they don't realize that node_modules is for development and not related to the application they would actually deploy.
Hope this comment stays at the top before all the "wow JS sucks!!!" people arrive :-) Though to be fair a "modern" JS dev environment does use a ton of stuff! IIRC Angular 2 production builds are actually pretty efficient.
[1] - http://monkberry.js.org/
Earlier quoted context omitted.
Because package-lookup and the package manager are 2 completely separate systems in javascript. When you `require` or `import` a file in node.js, it looks for a node_modules and looks for that name in there. If it can't find it there, it starts walking up the directory tree until it finds something it can use (to a point). This is hardcoded and will be extremely difficult to change without a crazy amount of breaking.…
Everyone knows it shouldn't be. Even a naive attempt by the average developer to write a package management system would take versions into account.
And it's easy to say "even a naive attempt by the average developer" would do it better, but I really don't think they would have.
Still, the fact is that this is what we have, and complaining about what could have been isn't going to do anyone any good, improving the system will.
Earlier quoted context omitted.
This sucks so hard. It's also quite easy to hit path length limits for certain operations (on windows) when you have this mess there.
Totally. We just ran into this issue. Running npm install inside a linux vm resulted in an endless loop, because the nfs mapping created path names that exceeded the length limit.
Earlier quoted context omitted.
But that has nothing to do with it's size. If Buble was 10% larger than Babel it would still solve it's purpose.
That's right, Buble's secret sauce to being fast is that is skips the code generation step, not because of the number of dependencies. Although there definitely is a performance cost to Babel's large dep tree as each of these modules have to be found by Node (which is inefficient). If you use Babel with npm2 it is super slow, because npm2's folder structure causes more lookups.
Interesting fact that I recently came across: bower and many other npm packages, has some dependencies that eventually depends on a package called "wordwrap". And this "wordwrap" package somehow has its test folder exposed in npm. The result: Every single person using bower would have one or more copies of In Praise of Idleness by Bertrand Russell on your local machine, depending on how many of your projects has a np…
Interesting fact that I recently came across: bower and many other npm packages, has some dependencies that eventually depends on a package called "wordwrap". And this "wordwrap" package somehow has its test folder exposed in npm. The result: Every single person using bower would have one or more copies of In Praise of Idleness by Bertrand Russell on your local machine, depending on how many of your projects has a np…
I used to `touch node_modules/.metadata_never_index` to prevent Spotlight from wasting disk cycles by indexing that stupid folder. After searching "In Praise of Idleness", it doesn't seem to prevent it. :/ Anyone knows how to prevent all node_modules folders from getting indexed by Spotlight?
Earlier quoted context omitted.
I used to `touch node_modules/.metadata_never_index` to prevent Spotlight from wasting disk cycles by indexing that stupid folder. After searching "In Praise of Idleness", it doesn't seem to prevent it. :/ Anyone knows how to prevent all node_modules folders from getting indexed by Spotlight?
Just ignore your whole dev/code folder from Spotlight. It's not a good way to get to it anyway.
Old-school grepping or using Notepad++'s find in files feature is far away the best method I've come across, which is... kinda sad.