4 ms·

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 t

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.

jen20 6y ago
> 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.
- usefulcat 6y ago
  Or even without any malicious intent, simply because the functionality provided by the package is under/poorly specified.
vbezhenar 6y ago
> 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! What a nightmare!
spicybright 6y ago
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.
Nursie 6y ago
> 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?
- toomuchtodo 6y ago
  Abstractions over expertise and effort, driven by expectations outside of the practitioner’s control.
- jka 6y ago
  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.
  - Nursie 6y ago
    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.
tyingq 6y ago
"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/1052c9d94dc87374cad15d7df017bfcccd8e3398#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346 https://github.com/juliangruber/isarray/commit/1052c9d94dc87...
marcus_holmes 6y ago
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?
ceceron 6y ago
> 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. > 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! 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.

jen20 6y ago

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

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

vbezhenar 6y ago

> 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! What a nightmare!

spicybright 6y ago

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.

Nursie 6y ago

toomuchtodo 6y ago
Abstractions over expertise and effort, driven by expectations outside of the practitioner’s control.
jka 6y ago
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.
- Nursie 6y ago
  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.

tyingq 6y ago

"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/1052c9d94dc87374cad15d7df017bfcccd8e3398#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346 https://github.com/juliangruber/isarray/commit/1052c9d94dc87...

marcus_holmes 6y ago

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?

ceceron 6y ago

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