3 ms·

So, who's going to be the person to find all these dumb packages and replace them with PR's to their dependents? Make PR's to repos using is-even, is-odd, etc w

So, who's going to be the person to find all these dumb packages and replace them with PR's to their dependents? Make PR's to repos using is-even, is-odd, etc with n % 2 == 0; etc?

handrous 5y ago
Replacing it with just that would be a bad idea, since (see upthread, where the code's posted) it also verifies that its argument is an integer, erroring if it's not. Some code out there might be relying on that functionality, and hell, type coercion might even do something crazy without those checks, turning erroring-bugs into data-corrupting bugs.
dvtkrlbs 5y ago
I did similiar to a repo using a npm package called empty-string. The whole library was basically this `module.exports.empty_string= ""`
zamadatix 5y ago
I went looking through the dependency chain of this for even more popular simple packages and picked a 4 million/month package that was calling is-number thinking it must be added to most of these as a joke/snuck it in and it turned out it was the original/main dev that added the dependency. So it seems the best case scenario of "fixing it by PR" is every PR request is accepted even though it was (at least sometimes) intentionally added by the main dev and this is done continuously and endlessly for this and every package like it (there seem to be hundreds of equally trivial packages that are popular) yet they problem will still continue to exist anyways. Not that there is anything wrong with greatly reducing the usage rate when we can just the real interesting problem presented with this package isn't literally the package itself it's troubles in the dependency ecosystem of NPM. All that said I'm going to try to tackle a handful after work, particularly of is-number which is about as many lines to import as define and unchanged for many years.
- lloydatkinson 5y ago
  Do share your progress!
  - zamadatix 5y ago
    Turns out the vast majority of the uses are semi reasonable basic utility packages by the same authors as the clearly trivial packages. They include their own work many times and a few larger projects legitimately use the reasonable basic utility packages. This results in millions of downloads of these frivolous packages with no interest from the maintainer in removing their own fluff dependencies. The only way to get past (the vast majority of) these would be to rewrite the mid level utilities and get projects to sign off on that larger switch (either as a dependency change or as a duplication of that code directly). Unfortunately that's not a "if a bunch of us clear 5 out tonight NPM's dependency hell will be fixed" kind of solution.

So, who's going to be the person to find all these dumb packages and replace them with PR's to their dependents? Make PR's to repos using is-even, is-odd, etc with n % 2 == 0; etc?

handrous 5y ago

Replacing it with just that would be a bad idea, since (see upthread, where the code's posted) it also verifies that its argument is an integer, erroring if it's not. Some code out there might be relying on that functionality, and hell, type coercion might even do something crazy without those checks, turning erroring-bugs into data-corrupting bugs.

dvtkrlbs 5y ago

I did similiar to a repo using a npm package called empty-string. The whole library was basically this `module.exports.empty_string= ""`

zamadatix 5y ago

I went looking through the dependency chain of this for even more popular simple packages and picked a 4 million/month package that was calling is-number thinking it must be added to most of these as a joke/snuck it in and it turned out it was the original/main dev that added the dependency. So it seems the best case scenario of "fixing it by PR" is every PR request is accepted even though it was (at least sometimes) intentionally added by the main dev and this is done continuously and endlessly for this and every package like it (there seem to be hundreds of equally trivial packages that are popular) yet they problem will still continue to exist anyways. Not that there is anything wrong with greatly reducing the usage rate when we can just the real interesting problem presented with this package isn't literally the package itself it's troubles in the dependency ecosystem of NPM. All that said I'm going to try to tackle a handful after work, particularly of is-number which is about as many lines to import as define and unchanged for many years.

lloydatkinson 5y ago
Do share your progress!
- zamadatix 5y ago
  Turns out the vast majority of the uses are semi reasonable basic utility packages by the same authors as the clearly trivial packages. They include their own work many times and a few larger projects legitimately use the reasonable basic utility packages. This results in millions of downloads of these frivolous packages with no interest from the maintainer in removing their own fluff dependencies. The only way to get past (the vast majority of) these would be to rewrite the mid level utilities and get projects to sign off on that larger switch (either as a dependency change or as a duplication of that code directly). Unfortunately that's not a "if a bunch of us clear 5 out tonight NPM's dependency hell will be fixed" kind of solution.