[leetrout]

My personal take having “grown up” with all of this - JS is one of the worst ecosystems for relying on external packages for everything. It’s more the culture than the tooling.

One of the things I love about Go is generally people are a little more forgiving to copying something around a couple times instead of making a lib for everything.

[pixelrevision]

Go in particular has an amazing standard library and very clear guidelines on how to write code. JavaScript does not have either of those things so it promotes people releasing competing libraries with similar functionality written in various different styles.

[erik_seaberg]

Copying code is pinning a dependency, committing to never update it, and hiding the evidence.

[lioeters]

That's not always true.

Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever).

Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first.

Regarding the article, sometimes copying code keeps the entire codebase easier to understand and manage without having an external dependency.

[erik_seaberg]

I guess that's not impossible, but it seems to reinvent git submodules without the tool support I'd want, and I think explicitly depending on our fork of their library would be clearer and safer.

[lioeters]

> explicitly depending on our fork of their library would be clearer and safer.

I complete agree. To temper my comment, I've seen plenty of bad examples of copying dependencies, bundling old un-updated versions, with undocumented changes. In such case, it's true that copying leads to a worse kind of dependency.

[leetrout]

Perhaps.

[smitty1e]

Inviting the question of why the culture hasn't sprouted a "package rationalizer" to produce a curated, tested, noise-filtered distribution of useful functionality.

Come to think of it, something that does for packages what jQuery did to bring (some) sanity to browser incompatibilities.

[ng12]

Because we can't even agree on whether React or Vue or Angular is best.

In fact this is the root of the issue. It's important to realize that `node_modules` for any project in Popular Framework X will be almost identical. Most of the packages are related to compiling, bundling, and the development environment and a small minority are actual client-side dependencies. Even the frameworks themselves are pretty light -- React has a grand total of 2 dependencies. It's packaging the entire toolchain that causes most of the bloat.