[bfred_it]

That's one way to bloat your repo.

There's no reason to commit your dependencies if your intent is security. Just use the lock file. The packages won't change on npm and you'll always get the same version for all sub-dependencies.

[Silhouette]

That's one way to bloat your repo.

Perhaps, but building from a controlled body of code fully under your own control also has some big advantages over the typical package management and development culture in the JS world, which I think it's fair to say has been a pretty good representation of how not to do robust, professional software development for years.

This article is about the latest high-profile mess with event-stream, but it follows years of interrupted work because NPM was down again, several generations of tools that couldn't meet basic requirements like reproducible builds, excessive dependence on near-trivial packages like left-pad, and of course the overall problem that managing thousands of such dependencies is basically an impossible problem and inevitably leads to problems with trust, reliability, licensing and legal matters, and so on.

[izacus]

Doesn't JavaScript world know anything like Java Maven proxy servers? Which retrieve artifacts on first lookup and cache them forever?

[leipert]

Well, the Java World is not free from it's problems when it comes to dependencies: https://blog.autsoft.hu/a-confusing-dependency/

Personally I do not understand why Java libraries which are binary blobs are not targeted more often.

[purple_ducks]

> Java libraries which are binary blobs

Java libraries are JAR -> Java Archives. You can unzip them and there is JVM bytecode inside which can be decompiled. Not really binary blobs.

[randallsquared]

Well, just an actual HTTP proxy would work for that, properly tuned. But the JS world mostly doesn't bother, maybe due to long history as a browser-based language, where the webserver serves that function for the browser.

The ones who do are focused on caching private npm servers like verdaccio.

[canadev]

Another solution is to check them in as git Large File Storage files.

https://git-lfs.github.com/

[vvillena]

That's what I was thinking about. The Java ecosystem solved this problem 20 years ago!

[Silhouette]

It probably is fair to say that the state-of-the-art tools for JS development today are at least 1-2 decades behind the state-of-the-art for programming more generally. Trying to build larger applications in JS is a relatively new thing, and a community full of people who are enthusiastic and keen to do new things but often lacking in experience with larger and more long-lived software systems is getting a crash course in what does and doesn't work at that scale. Give it another 5-10 years and/or the more dramatic replacement of JS with better languages if new possibilities like WebAssembly change the landscape, and hopefully more of the experience will transfer over and the tools will catch up.

[leipert]

Well, yes there actually is a reason:

You actually see the diff on dependencies on updates. Vendoring is done in the Go world. Together with `yarn autoclean` it can be reasonable.

Reference: https://yarnpkg.com/lang/en/docs/cli/autoclean/

[TeMPOraL]

> The packages won't change on npm and you'll always get the same version for all sub-dependencies.

Until they decide to stop hosting old versions you need, because reasons.

[gamanoid]

Aren't there several sites that cache npm packages or redistribute over CDNs?

Though I agree, over reliance on just npm can be a bad thing (the 2016 issue over kik)