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 npm dependency of this package:
https://github.com/substack/node-wordwrap/blob/master/test/i...
Don't believe me? Try searching for "In Praise of Idleness" in Spotlight.
Edit: Someone had already sent a PR about this on GitHub: https://github.com/substack/node-wordwrap/pull/14
Anyone knows how to prevent all node_modules folders from getting indexed by Spotlight?
"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.
IIRC Angular 2 production builds are actually pretty efficient.
[1] - http://monkberry.js.org/
Though to be fair a "modern" JS dev environment does use a ton of unnecessary stuff!
I fixed your comment.
this.
Granted, it's the same with everything- if you expanded every compressed file and counted every class, most languages and frameworks would just be incredibly nuts, because all of them aren't needed.
But, something could be done about that; you could better differentiate what is there for convenience, and what needs to be there and make the developer more aware of what they are using. It can make development more difficult if done poorly, but good examples of minimalist development are out there, e.g. Sinatra and similar frameworks that said X is too much- just use this.
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?
$ unzip -l /usr/java/jdk1.8.0_77/jre/lib/rt.jar | wc -l
20138
I'd rather look at comparable thing like JEE server + Spring + some server-side renderer like Thymeleaf.
Try exploding every Jar in the JDK and counting how many class files and resources there are.
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 better, tree shaking works better, and it lets you do things like swapping out one package for another with the same API.
I would be perfectly fine if npm pulled down "distribution" versions for tools like gulp, typescript et al
SHARED_DIR/npm_modules/NAME/VERSION
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.
The package manager is free to install however, but it needs to put things where the package-lookup can find them.
Essentially, all they need to do is:
1. leave the current behavior for backwards compatibility; then
2. provide a flag like npm -G that exposes the correct behavior as suggested in the grand parent of using the same path like SHARED_DIR/node_modules/NAME/VERSION for package imports and package management.
With time, newer npm versions will default to the correct behavior. For folks that need backwards compatibility, this would require explicitly setting a npm --compat flag or similar.
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.
node_modules/
a/
node_modules/
c/ (1.0.0)
b/
node_modules/
c/ (1.0.0)
c/ (2.0.0)
node_modules/
versions/
a@1.0.0
node_modules/
c -> ../../c@1.0.0
b@1.0.0
node_modules/
c -> ../../c@1.0.0
c@1.0.0/
c@2.0.0/
a -> versions/a@1.0.0
b -> versions/b@1.0.0
c -> versions/c@2.0.0Maven repositories have following structure, that allows to avoid duplication and take versions into account: /<vendor namespace>/<library>/<version>/<library artifact.ext>
Vendor namespace itself is hierarchical and usually related to domain name, e.g. "com/mycompany/myapp".
No idea, why this approach is not yet used in JS world (except the webjars), but it's high time to fix it this way.
Plus, it started out broken. I had to search elsewhere to find the solution to the error the tutorial produced.
Minify it, run dead code elimination. Exactly as you would with any other language with a compiler.
Also, worth noting that the tutorial being broken isn't symptomatic of JS, that's a problem with Angular (which has a history of sucking, and IMO Angular 2 just takes all of the problems with Angular 1 and adds more baggage to it).
Be aware as well that Angular 2 is a full-fledged Web Framework. Even after all of this compression and such, it is not going to be as lightweight as you'd expect simply due to the nature of what you've installed.
If you want something really lightweight, go with Rivets or React.