Hacker News Reader

Comment by axiosgunnar | Hacker News Reader

You can think of these NPM micropackages as Github Gist snippets that you can programmatically link to your code.

The first advantage to just copy-pasting is that the snippet author might update it (e.g. if he finds a faster/safer way to do the one thing his package does), and you don't have to do anything.

Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!

The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.

View on HN

> Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!

That sounds like a security nightmare, and broken functionality waiting to happen.

How on earth have we got here?

Abstractions over expertise and effort, driven by expectations outside of the practitioner’s control.

There are issues with micropackaging functions and code, and the fact that they didn't exist as a concept when the JavaScript language was being designed may contribute to that - but I don't think that it's clear whether micropackaging will turn out to be a good or bad trend overall.

Hundreds of thousands of untested, unaudited implementations of a roughly-similar function _could_ be far worse in terms of overall ecosystem stability and security than a small number of frequently-used (albeit yes, potentially flawed and vulnerable) micropackage dependencies.

The outcome for each micropackage may depend on how much scrutiny and test coverage is available when updates occur, and how well-defined the package's API is.

In a sense, that's not hugely different to version upgrades for other, larger library dependencies. Incremental library changes tend to be easier for developers to audit and integrate, so perhaps eventually this is a better approach?

In my opinion Microsoft (via GitHub and NPM) are likely best-placed to make significant progress on evaluating and improving the situation.

When a micropackage is updated, they're in a position where they could run continuous integration tests not just for the package itself, but also for dependent packages, to gain an early sense for the correctness and disruption potential of the change.

That kind of information would be useful to make a micropackaging ecosystem more viable and healthy, although it would also increase the ecosystem's long-term dependence on Microsoft.

There is a middle ground between hundreds of thousands of untested, unaudited implementations of a roughly-similar functions, and packages which auto update without the developer doing anything at all.

At the least you want some oversight when a dependency changes under you.

Yep, pinning specific package versions should probably be a more commonplace practice than it currently is.

Hardcode the version and it will never update.

Otherwise you can (and should) review the update manually or using automated tools.

As someone studying programming languages I used to be shocked by such practice as well — but later on I realized that, for people doing this, they really don’t have any practical motivation to care much beyond getting it to work first for immediate business needs.

Similarly, many more “principled” programmers don’t really understand many parts of our computing stack either and it did bring troubles to even the most experienced veterans in the industry.

It is always a trade-off between risk, cost, and benefit.

> The first advantage to just copy-pasting is that the snippet author might update it

The first disadvantage of “micro packages” over copy-pasting is that the author might update it to do something completely different - either because the author is malicious, or because of a transfer in maintainership of the package to someone who is malicious, or because of a compromise.

Or even without any malicious intent, simply because the functionality provided by the package is under/poorly specified.

> The first advantage to just copy-pasting is that the snippet author might update it (e.g. if he finds a faster/safer way to do the one thing his package does), and you don't have to do anything.

First, please don't copy paste solutions. Understand them and implement correctly. Stackoverflow is not a magic library you should take books from without understanding.

Wow, I've just imagined it. Props for the great horror story, but... it's a security nightmare. You basically surrender all control over your project for almost nothing.

> The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.

Writing this utility in a separate code unit (namespace, project, whatever) gives exactly the same advantage. And micropackages will litter my building process / dependency tree.

That would be true if it was "the community". But it's not. It's one person. So you're literally giving Julian Gruber commit access to your production environment in the hope that he finds a better way of doing something that is a polyfill for something that browsers now do better.

I don't understand how that is a rational decision that people are making. Can anyone explain?

The downside is, your code and your heavier libraries now have their dependencies changing constantly, which can lead to things breaking if either depend on specific behavior, or if the micro package author does something wrong.

It's a trade off, although personally I've been bit by that enough to keep strict version numbers in my dependencies.

What a nightmare!

"if he finds a faster/safer way to do the one thing his package does"

That seems to have happened here, though who knows across X number of browsers and whatever JS engine updates happen.

https://github.com/juliangruber/isarray/commit/1052c9d94dc87...

Reply on news.ycombinator.com