3 ms·

> Most of the packages on NPM are complete garbage And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to fi

by notJim 6y ago

> Most of the packages on NPM are complete garbage And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code. The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the source and adapt it rather than installing the package.

ggregoire 6y ago
So if you need that package in your 10 projects, do you copy those 20 lines of code in your 10 projects? Yikes. Then what happens when it requires a change? Do you make the change in all your projects? Double yikes. When it becomes 30 lines, do you still copy/paste those 30 lines in all your projects? Do you also copy/paste the tests related to those 30 lines in all your projects? ... Having reusable code wrapped into packages is basic software engineering.
- nightski 6y ago
  Or you create a library which contains a collection of 10-20 line of code modules and share it among your projects.
  - ggregoire 6y ago
    Yes I agree it's better to have one library with 20 helper functions than 20 libraries with 1 function each. Think Lodash. Although some people will then complain about the size of the library...
    - speedgoose 6y ago
      Yes. Every Lodash function is available in its own npm package too. I use it like this, I rather have 4 lodash packages than the big whole lodash library in one package with almost everything left unused.
      - runawaybottle 6y ago
        JS libraries only did that to reduce bundle size being sent to the browser. It’s done out of necessity, not because it makes any sense. Exporting out one method at a time is pretty absurd.
        speedgoose 6y ago
        Lodash has a lot of features that are not needed anymore or even dangerous sometimes. If you don't need them, why would you install them?
        runawaybottle 6y ago
        Because it’s simply not a big deal on the server.
      - Master_Odin 6y ago
        These will go away in v5 (if a v5 is ever released) and is not recommended if using a bundler as it'll end up wasting space rather than saving as it'll include duplicate code that each individual function could share. https://lodash.com/per-method-packages https://lodash.com/per-method-packages
        speedgoose 6y ago
        Thanks for the information. I think it will be about time to completely remove lodash from my code bases.
tomxor 6y ago
I'm not afraid to say I agree with you, i'm not sure why you are being down voted... This is one of the attributes that is part of my argument against NPM, packages which are at the extreme end of too small, delivering almost no value at the cost of a lot of risk. This is also an opinionated subject, and as with most things in life there is a balance somewhere in between the two extremes. However the NPM packages you refer to (and yes I have seen the <10 line offenders you refer to) are clearly at a stupid end of extremely useless shared code that amount to the most trivial stackoverflow JS examples. In response to the sibling comment on duplication: all I can say is that it cuts both ways, deduplication to the extreme also has downsides: when someone changes that code you don't control, it now affects a large number of dependencies that the author may not care about. But even ignoring those issues and assuming you package-lock everything and never look back, extreme de-duplication in general can result in highly illegible code due to a lack of holistic view: whether it's achieved with thousands of tiny external packages or thousands of tiny 3 line functions in the same file - many have covered this topic in detail before, deduplication for deduplication sake never ends well, abstractions always have a cost.

by notJim 6y ago

ggregoire 6y ago

So if you need that package in your 10 projects, do you copy those 20 lines of code in your 10 projects? Yikes. Then what happens when it requires a change? Do you make the change in all your projects? Double yikes. When it becomes 30 lines, do you still copy/paste those 30 lines in all your projects? Do you also copy/paste the tests related to those 30 lines in all your projects? ... Having reusable code wrapped into packages is basic software engineering.

nightski 6y ago
Or you create a library which contains a collection of 10-20 line of code modules and share it among your projects.
- ggregoire 6y ago
  Yes I agree it's better to have one library with 20 helper functions than 20 libraries with 1 function each. Think Lodash. Although some people will then complain about the size of the library...
  - speedgoose 6y ago
    Yes. Every Lodash function is available in its own npm package too. I use it like this, I rather have 4 lodash packages than the big whole lodash library in one package with almost everything left unused.
    - runawaybottle 6y ago
      JS libraries only did that to reduce bundle size being sent to the browser. It’s done out of necessity, not because it makes any sense. Exporting out one method at a time is pretty absurd.
      - speedgoose 6y ago
        Lodash has a lot of features that are not needed anymore or even dangerous sometimes. If you don't need them, why would you install them?
        runawaybottle 6y ago
        Because it’s simply not a big deal on the server.
    - Master_Odin 6y ago
      These will go away in v5 (if a v5 is ever released) and is not recommended if using a bundler as it'll end up wasting space rather than saving as it'll include duplicate code that each individual function could share. https://lodash.com/per-method-packages https://lodash.com/per-method-packages
      - speedgoose 6y ago
        Thanks for the information. I think it will be about time to completely remove lodash from my code bases.

tomxor 6y ago

I'm not afraid to say I agree with you, i'm not sure why you are being down voted... This is one of the attributes that is part of my argument against NPM, packages which are at the extreme end of too small, delivering almost no value at the cost of a lot of risk. This is also an opinionated subject, and as with most things in life there is a balance somewhere in between the two extremes. However the NPM packages you refer to (and yes I have seen the <10 line offenders you refer to) are clearly at a stupid end of extremely useless shared code that amount to the most trivial stackoverflow JS examples. In response to the sibling comment on duplication: all I can say is that it cuts both ways, deduplication to the extreme also has downsides: when someone changes that code you don't control, it now affects a large number of dependencies that the author may not care about. But even ignoring those issues and assuming you package-lock everything and never look back, extreme de-duplication in general can result in highly illegible code due to a lack of holistic view: whether it's achieved with thousands of tiny external packages or thousands of tiny 3 line functions in the same file - many have covered this topic in detail before, deduplication for deduplication sake never ends well, abstractions always have a cost.