Hacker News Reader

Comment by bendmorris | Hacker News Reader

>Ultimately, you can't take dependencies for granted.

The problem is that JS dependencies are so modular that shifting the burden to vet your dependencies to developers is generally not realistic. Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that?

To compound things, this package could be a transient dependency of a transient dependency, so I may not even know the person who decided to depend on it in the first place, or the reason why, or what the package does.

It's not that people are taking dependencies for granted - it's that there is no reasonable alternative.

View on HN

There is a reasonable alternative, though...do not use that dependency! It's sure attractive (and easy) to use that one library with a thousand child dependencies, but that's a HUGE red flag that it's not as useful as you think it is.

Incidentally this can come into play even for exceedingly popular packages. For example, consider deciding to use Babel versus TypeScript for ESn -> ES5. I am a fan of both, for different reasons and uses. Both are excellent tools, widely used, of great quality.

Babel, configured in a typical way, will have at least hundreds of (transitive) dependencies. TypeScript has none, every line of code is from Microsoft.

I have pointed this out to numerous people in the process of deciding between these tools; so far I don't think a single one has given this consideration any weight in the selection.

I give it a lot of weight. Microsofts releases are backwards compatible in many cases, and when not, they always have a detailed transition path.

Their changes are never motivated by having to change to suit an upstream packages new version, and their entire codebase is cohesive.

Its what I like in a compiler: a stable tool that I never worry about.

Dependencies should be nailed to versions and upgraded conservatively. The default shouldn't be the latest and greatest, it should be the last thing that worked.

This also has security implications as in this approach you don't get the fixes to known vulnerabilities. If you update to 1.2.4 as soon as its out, you may be vulnerable to a takeover like this (which happen but are rare), but if you're still running 1.2.3 when 1.2.4 is out, you're definitely vulnerable to all the things that 1.2.4 fixed, and these risks are far more common.

If semantic versioning always behaved as it should be, the default shouldn't be the last thing that worked but rather the major/minor version of the last thing that worked followed by the latest and greatest patch version.

>If semantic versioning always behaved as it should be

The exploit in question specifically relied on this expectation, by creating a new patch release for the exploit. Even if you could trust well-intentioned maintainers to use it correctly, there's always this risk.

I agree, but you have to start from a known working state at some point - and at that point you are extending trust to that specific set of versions. Anyone who ran `framework create-project` for a framework that included event-stream as a dependency will have downloaded the exploit and then pinned it without knowing.

Stack (https://docs.haskellstack.org/en/stable/README/) for Haskell solves this problem by maintaining sets of curated version numbers that are known to work together.

In theory perhaps, but in practice what actually happens is that your dependencies gradually fall so far out of date that after a couple of years it becomes impossible to upgrade anything at all. Then it becomes impossible to add features and before you know it the whole application is dead end legacy code.

>Creating a new project with one of the current popular frameowrks will bring in hundreds or thousands of dependencies. Who can possibly vet that?

People who care if their software works correctly. Everyone else relies only on herd immunity. If you have dependencies, you either belong to the first group or the second, and you make that choice. Neither choice is wrong, but it is still a choice you have to make and account for.

Reply on news.ycombinator.com