The Everything NPM Package

Post by felixfbecker » Sun, Jan 07, 2024, 6:30 AM UTC

BeefWellington wrote: post #75

cybrox wrote: post #61

Earlier quoted context omitted.

I mean... just don't install everything then? Over-reliance on third party dependencies is a choice. One could argue that it's unreasonable not to do it if you want to stay competitive but good luck changing human nature then. If there are shortcuts, they will be taken.

While this is true, when the shipped standard library by NodeJS lacks so many VERY BASIC features that every other language has, OF COURSE developers choosing/being instructed to use JS so that frontend and backend languages are synced are going to reach for packages to solve whatever functionality should already exist in code like: "Jim".leftPad(4)

Post by paulddraper » Sun, Jan 07, 2024, 6:45 AM UTC

Uehreka wrote: post #37

charlie0 wrote: post #10

Earlier quoted context omitted.

Devs working with core developers to create more 1st party packages would be a good start. I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. I just need 1 really good sorting library. With it, we can move to less overall dependencies on random packages.

> I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. This feels like a bit of a strawman, since sorting is already in the standard library and there aren’t in fact popular sorting packages for each framework (that would in fact be ridiculous). If you want to start a real debate though, bring up date/time pickers. There are multiple date picker, time picker and date…

  [5, 14, 1, 2].sort()

  [5, 14, 1, 2].sort((a, b) => a - b)

Post by firtoz » Sun, Jan 07, 2024, 6:48 AM UTC

quickthrower2 wrote: post #91

jonorsi wrote: post #73

Earlier quoted context omitted.

I’ve started thinking package management has too much trust now. Ideally, but probably unpractically, projects should check in their packages like they used to under /lib or /third_party, and be much more suspicious of new package dependencies. Basically, you would need to start accepting that you are responsible for any dependencies you choose to include. Any upstream changes you would need to evaluate and bring in…

If NPM made some tweaks this might become trivial. Keep a node_modules/packagefiles with all the .zips that you commit to your source control. The expanded files can be kept out as they are now recoverable just using zip!

Post by coderedart » Sun, Jan 07, 2024, 7:18 AM UTC

cxr wrote: post #76

superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

I know it's five hours later and this question has already spawned dozens of responses, but it's worth thinking and speaking clearly if we're trying to arrive at a solution for something. We can start by saying exactly what we're talking about—how do you make what different? Because you mention npm "and their policies" but then switch gears and talk about "is-odd", which is not a policy issue. It's rather something e…

Post by StressedDev » Sun, Jan 07, 2024, 7:46 AM UTC

6510 wrote: post #95

cxr wrote: post #76

Earlier quoted context omitted.

I know it's five hours later and this question has already spawned dozens of responses, but it's worth thinking and speaking clearly if we're trying to arrive at a solution for something. We can start by saying exactly what we're talking about—how do you make what different? Because you mention npm "and their policies" but then switch gears and talk about "is-odd", which is not a policy issue. It's rather something e…

You design a language for a purpose (which could be anything) you develop and mature it's features to better fit it's use case. html, a crappy defective xml implementation refuses to grow up, js, while great for little html tweaks is not adopting any of the useful features found in popular npm packages. It was actively developed for 2 weeks. Ripping off it's head (nodejs) gave us a poor sailor jargon ~ but without th…