Live data from Hacker News

Huge no. of files for Angular 2

stackoverflow.com

61–70 of 105 posts

Re: Huge no. of files for Angular 2

#61
post #54

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.…

But it is still possible to have the best of both worlds. 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 corre…

The problem isn't in the "package manager" it's in node.js

node loads modules in a given pattern. Changing that pattern would be global to your project, and would cause issues with tons of 3rd party tools.

the best possible scenario would be to introduce a "new_node_modules" type directory and change to the new system, then look in "new_node_modules" first, then the legacy "node_modules" next, but that's a ton of work, a ton of 3rd party tool breakage, and a lot of possibility for new bugs and breakage for not all that much benefit.

That's not to say it shouldn't be done at some point, just that there are much bigger areas that need to be addressed sooner in the node ecosystem.

Re: Huge no. of files for Angular 2

#63
post #5

32,000 files for a hello world... jeez, i'm going back to java.....

No, 32k source files for the whole Angular 2 SDK. The deployable hello world app would be one JS file.

Try exploding every Jar in the JDK and counting how many class files and resources there are.

Re: Huge no. of files for Angular 2

#64
post #58

Earlier quoted context omitted.

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)?

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.

Re: Huge no. of files for Angular 2

#65
post #46

Earlier quoted context omitted.

Instead of "50% in size" I'll assume "50% fewer dependencies", because I think that's the point here. 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…

This is the major part of the whole "left-pad" fiasco I don't get. If there is a well written, well tested, and widely used micro-library out there that does one thing and does it very well, why not use it? Even if you think you can re-implement it in 5 minutes, will yours be as fast? Will yours be as well tested? Will yours have an interface that many other developers already know and use? Sometimes reinventing the…

This is even more true, if like me you only delve into JavaScript on an occasional basis. The language is full of quirks and gotchas, so for me it would be the sensible choice.

Re: Huge no. of files for Angular 2

#66
post #6
post #3

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…

I've built a fairly hacky solution to this before (for a different package manager) - it can be pretty simple:

    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.0

Re: Huge no. of files for Angular 2

#67

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…

Very nice! The file can also be found by searching for "Saran finds some mischief", which fees like an apt phrase.

Re: Huge no. of files for Angular 2

#68
post #3

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.

To me it looks like a silly architectural mistake made by NPM/Node developers, considering that there's already pretty good dependency management solution on the market that does the things right.

Maven repositories have following structure, that allows to avoid duplication and take versions into account: ////

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.

Re: Huge no. of files for Angular 2

#69

Earlier quoted context omitted.

This is the major part of the whole "left-pad" fiasco I don't get. If there is a well written, well tested, and widely used micro-library out there that does one thing and does it very well, why not use it? Even if you think you can re-implement it in 5 minutes, will yours be as fast? Will yours be as well tested? Will yours have an interface that many other developers already know and use? Sometimes reinventing the…

> If there is a well written, well tested, and widely used micro-library out there that does one thing and does it very well, why not use it? Because every dependency comes with a cost. First of all, it needs to be available and the author might decide to pull it - maybe not from npm, but from github. Second is a matter of trust: Someone just needs to take over the left-pad authors npm account an all of a sudden he c…

I still maintain that those problems can be solved with better tooling and package management rather than "bundling" dependencies.

Bundling to me is such a sledgehammer solution. Yeah, it can somewhat prevent many of those issues, but it also comes at a pretty large cost.

* it leads to code duplication

* it can ruin the performance of tree-shaking and minification systems

* it prevents you from swapping out a small module with another globally

* it makes it harder to inspect and debug the code that you have installed in the node_modules directory

* it makes it harder to verify that the code on your machine is the same as the source code

* the bundler can introduce bugs into the source code

* The package now needs to maintain a build step and needs to maintain a separate source and "binary"

And more. Plus, in the end you might not even be helping anything. A big repo like lodash can have just as many contributors as tons of little dependencies, and big repos aren't immune to the org running it going belly up.

I guess I see those problems as more of a "large amount of code" problem instead of a "large amount of dependencies" problem.

Re: Huge no. of files for Angular 2

#70
post #5

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).

JRE is a platform, so if you counting platform files, why not also counting NodeJS or browser sources too?

I'd rather look at comparable thing like JEE server + Spring + some server-side renderer like Thymeleaf.

Post reply on HN