41–50 of 105 posts
Earlier quoted context omitted.
https://github.com/alexanderGugel/ied
I was just about to write a comment to ask why it can't be done like this (using CAS / symlinks). So I guess it can. Are there any disadvantages to using ied over npm?
Earlier quoted context omitted.
Well to be fair, does anyone expect a compiler to be small?
https://gitlab.com/Rich-Harris/buble Buble says "Files (940 KB)" but it doesn't do everything Babel does (just a strict subset).
Is anyone's quality of life really impacted by the size of babel vs buble?
Does the size of a compiler really change anything for the average developer (obviously within reason)?
Earlier quoted context omitted.
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.
it's like an entire eco-system is fundamentally broken
It's just that this problem can't be solved entirely by npm. Node has to make changes to it's module loader as well.
Has npm finally figured out how to de-dupe dependencies? In one project, I have something like 47 copies of the same version of the same library, distributed at all levels of the node_modules hierarchy. I try not to think about that JS tooling too hard, lest I start pulling my hair out and devolve into a screaming crazy person.
It's actually not possible due to the way Node looks up dependencies. You could have a situation like: node_modules/ a/ node_modules/ c/ (1.0.0) b/ node_modules/ c/ (1.0.0) c/ (2.0.0) Both a and b depend on c version 1.0.0, but since there's a version 2.0.0 in the root node_modules folder c can't be placed there, and has to be duplicated in a and b's own node_modules folder, otherwise Node couldn't find it for each o…
Evaluating a framework by the number of files its dependencies are broken into is a a pretty poor measure of quality.
Why? If framework X does roughly the same as framework Y which is 50% in size then you can estimate that the code of Y is more effective.
I believe that creating a module without relying on other modules will likely lead to reinventing the wheel. Well, lots of wheels.
However, that might still be fine. But what about that one corner case you missed? It might already be solved in a third-party module that focuses on one thing only.
It's really not that bad to try and use specialized modules as much as you can. You can benefit from other people's cleverness and focus on more relevant work.
Yes, there will probably be a lot of on-disk overhead. But is that really relevant today?
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…
Earlier quoted context omitted.
https://gitlab.com/Rich-Harris/buble Buble says "Files (940 KB)" but it doesn't do everything Babel does (just a strict subset).
I know that it's possible, but what's the purpose? Is anyone's quality of life really impacted by the size of babel vs buble? Does the size of a compiler really change anything for the average developer (obviously within reason)?
babel 6 with jsx transformer used to install a comparable number of files due to module duplication. At one point it was a 100M install with some modules being duplicated 45 times. Much of this was the fault of npm 2. But with latest babel and npm 3 it's now a 35M install with 5700 files over 814 directories. I guess that's considered lean by modern standards.
Is there a "distribution" bundle convention for npm ? Analogous to static linking, it would be one .js file that would bind all dependencies into a bundle (e.g. gulp.dist.js) . In that case you would end up with a much smaller number of dependency files to manage.
There is for your final output (meaning the stuff you would upload to the server and serve to the user). but not for the development. IMO it's a pretty big anti-pattern to do that. It just hides the problem of managing dependencies (see, it's not 10,000 files, it's just one!), but doesn't fix any of the issues associated with it. Keeping each dependency small, and having tons of them means that deduplication can work…
I would be perfectly fine if npm pulled down "distribution" versions for tools like gulp, typescript et al