Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Huge no. of files for Angular 2

stackoverflow.com

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Huge no. of files for Angular 2

#51

Post by Klathmon »

sotojuan wrote: post #48
Klathmon wrote: post #43

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

I personally don't care but I've had super long install times when using slow internet—which in many parts of the world is the standard speed. I'll keep using Babel, but I like that there are alternatives that install faster if need be.

I agree. Also there are multiple ways that you can install these things.

The "recommended" way is to install babel for each project independently. Space is cheap, internet speeds are fast for many, and avoiding version issues outweighs the savings.

But you can install globally, so you'd install babel once and can use it in all projects that way.

Then throw in the possibility of different package managers and you get a crazy amount of freedom and choice. People get overwhelmed with "javascript fatigue" and I just don't get it. You don't need to do everything, but having the option to is amazing.

Re: Huge no. of files for Angular 2

#52

Post by Klathmon »

currywurst wrote: post #50
Klathmon wrote: post #40

Earlier quoted context omitted.

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…

In this case, most of the files pulled down are the development dependencies which are not going to be exposed to the production code. I would be perfectly fine if npm pulled down "distribution" versions for tools like gulp, typescript et al

It might just be me living in a bubble, but I'd much rather have the full version downloaded to my machine in it's "raw" form than a "compiled" version.

Even just for the ability to dive into the source i'm using if i'm debugging something, or be able to look at the actual code i'm running if I want to understand how a tool works.

This is one of the reasons why I like how lodash handles their library. You can install the "regular" version of lodash and require it like "normal", or you can install a single big compiled lodash file, or you can install one that exports as ES6 modules, or you can install a single function at a time...

Obviously every package can't afford to spend that much time on packaging, but a framework similar to that along with some changes to NPM to allow tagging a package as an "alias" of another (so lodash-as-one-big-file will be treated as lodash for other packages) would go a long way into making everyone happy.

Re: Huge no. of files for Angular 2

#53

Post by Klathmon »

fuzzy2 wrote: post #46
huuu wrote: post #11

Earlier quoted context omitted.

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.

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 wheel is needed, but most of the time using a well working wheel that someone else made is the best choice.

Re: Huge no. of files for Angular 2

#54

Post by sah2ed »

Klathmon wrote: post #38
jbverschoor wrote: post #33

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

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 correct behavior. For folks that need backwards compatibility, this would require explicitly setting a npm --compat flag or similar.

Re: Huge no. of files for Angular 2

#55

Post by maaaats »

moderndeveloper wrote: post #39

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.

Just because of the way npm2 ordered the dependencies, the runtime of babel got incredibly slow [1]. Npm3 fixed that drastically, but I wonder how much is still wasted just because of navigating the file tree to the dependencies.

[1]: https://github.com/babel/babelify/issues/206

Re: Huge no. of files for Angular 2

#57

Post by zuck9 »

paradite wrote: post #20

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?

Re: Huge no. of files for Angular 2

#58

Post by Akkuma »

Klathmon wrote: post #43
sotojuan wrote: post #36

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

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.

Re: Huge no. of files for Angular 2

#59

Post by SquareWheel »

rplnt wrote: post #4
douche wrote: 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.

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.

This used to be the case. In npm3 and beyond it installs dependencies in a flat way, which seems to have solved the Windows file length limit problem.

Re: Huge no. of files for Angular 2

#60

Post by Xylakant »

Klathmon wrote: post #53
fuzzy2 wrote: 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…

> 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 can inject arbitrary code into all projects using the dependency. I'd bet that 90% of folks don't even bother to check the left-pad code. So basically you need to trust each and every author of dependencies that they're benevolent and competent, that is: They don't drop the ball, get hacked, loose access, ... And that task gets harder and harder the more dependencies you have to vet. In a lot of instances just inlining the code would be better. A larger stdlib that can be selectively included would be better. It's a tough problem and npm just sits on an extreme end of the scale.

Post reply on HN