8 ms·

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 everyth

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?

aaomidi 3y ago
Honestly, how go does package management is pretty good.
- speedgoose 3y ago
  It's personal tastes perhaps, but I don't find the appeal of packages management in Golang. I find PIP, NPM, RubyGems, Nuget, Cargo,… easier to work with. The go.mod syntax is what it is, and doing updates or fixing conflicts isn't easy. Not having a registry is neat, but I'm also unsure of what is going to happen over time as dependencies may be moved or removed. You can see that with old Maven pom.xml where some dependencies do not resolve anymore.
  - aaomidi 3y ago
    This is why you should vendor your dependencies. They are part of your codebase at that point.
    - speedgoose 3y ago
      I have better things to do though. This feels unnecessary.
      - aaomidi 3y ago
        “go mod vendor”. That’s it. That’s all you need to do.
        speedgoose 3y ago
        Oh like this. I’m not sure I would enjoy overloading my git repository and merge requests with the dependencies. I was thinking about having a proxy or forking all the dependencies.
        aaomidi 3y ago
        The thing is though that those dependencies are part of your code. Seeing how they're changing through PRs and commits is actually a feature IMHO and not a bug.
  - mseepgood 3y ago
    > I'm also unsure of what is going to happen over time as dependencies may be moved or removed That's what the Go module proxy is for. The authors can move or remove their repositories as much as they want, I as a dependent am not bothered by it. They would have to go through an official vetted process to get it removed from the proxy.
    - speedgoose 3y ago
      Oh I didn’t know that the proxy.golang.org was a thing. That’s good to know.
charlie0 3y ago
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.
- forrestthewoods 3y ago
  That’s a really good way to stagnate imho. I’d rather have 10 sorting libraries that each specialize or make different trade-offs than one library that tries to do everything. That said, you can still have a core set of “blessed” packages that serve the common needs.
  - charlie0 3y ago
    I don't see how creating a definitive sorting library is stagnation compared to having 10 mediocre libraries that are all missing some sort of critical functionality.
    - jddj 3y ago
      Right. I'd be very surprised if anyone looks at languages with strong standard libs and says "I wish they had the kind of sorting I can pull in from npm"
    - MetaWhirledPeas 3y ago
      Because who is going to bother working on any packages if they risk rejection in the end? Have fun with your ______ package because it's never going to improve.
      - hnlmorg 3y ago
        There’s plenty of languages with vast standard libraries and which also have 3rd party libraries that offer the same feature as something in stdlib but more enhanced against a specific metric. You see it in Go, Python, .NET, etc.
TobyTheDog123 3y ago
The entire reason this is a big deal is that people don't know what their dependencies are. The left-pad incident wasn't a big deal because it was pulled, it was a big deal because no one could easily fix their builds and didn't even know they were depending on it, because it was a dependency of a dependency of a dependency. While it's ridiculous to expect that people will audit every single dependency and sub-dependency, it's not ridiculous to expect tooling to do the same. Packages should be given an overall quality rating (and honestly it might be great for an ecosystem as large, diverse, and welcoming-to-beginners as JS/TS), part of the score comes from the number of different dependencies/sub-dependencies -- a social package score if you will. If a package causes the dependency graph to explode, give a warning before installing it. Then, if you're NPM, you don't need all of these convoluted and exploitable policies around un-publishing.
- aaomidi 3y ago
  This is why I prefer vendoring dependencies. I have to actually code review them.
  - mcny 3y ago
    I'd be called insane if I suggested it. I work with dotnet and I'd rather not add all the code in newtonsoft json and manually review each line. I mean where does it stop? Why not have everyone in the world code review asp.net and dot net libraries for every single website project at that rate?
    - sakjur 3y ago
      Rust’s Cargo vet offers an answer to that question. You can import a list of audits from trusted auditors, which should cover all popular packages. Now you have to audit dependencies that aren’t well-known in the community, which really is the set of dependencies that you should take an extra look at. The big popular JSON libraries can be audited by either Microsoft or some of the other large projects that are using them. You’d explicitly share your trust list in your audit file, and anything (updates or new packages) that isn’t trusted by you or one of your listed auditors is flagged for auditing. https://mozilla.github.io/cargo-vet/index.html https://mozilla.github.io/cargo-vet/index.html
notnmeyer 3y ago
i don’t know how you fix this for js, but in general i think well designed and robust standard libraries are a great place to start. the community shouldn’t need to write a bunch of tiny utility packages to do common things. in other words, make it easier to avoid the deeply nested dependency mess that js encourages.
- int_19h 3y ago
  This problem is a symptom of "move fast, break things" mentality that pervades the JS (and, more broadly, the web) ecosystem. The result is an ecosystem that is specifically optimized for moving fast and breaking things - which is a lot easier when the stable core is tiny.
o11c 3y ago
[flagged]
- bezier-curve 3y ago
  > There's a reason I still am skeptical of calling client-side devs "actual programmers". Nothing in your comment actually supports this last jab at web developers. Can you elaborate? I imagine you can't because you're arrogantly posturing.
  - o11c 3y ago
    Programming is, fundamentally, the imposition of a chosen order upon the world. You can easily distinguish somebody who's new to programming by the lack of choosing or the lack of effective order, and I think it quite fair to call them "not yet a programmer" while they're in that phase. Sure, theoretically web devs can be programmers. But in practice, choice is overwhelmed by happenstance, and/or order does not follow from the choice that is made. And this isn't just on random websites (after all, 90% of everything is crap), but even for core tooling.
    - throwitaway1123 3y ago
      This is a vague statement filled with poetic language that conveys very little useful information. I can't imagine trying to parse this as a non-native English speaker and extract any sort of meaningful information from this comment.
      - o11c 3y ago
        Okay, by example then: * if you just bash on the keyboard randomly until you get a result, or just copy-paste from StackOverflow, or just let an LLVM spew something, that's not programming - there's no choice. * if you do deliberately choose something, but your choice fails to produce a meaningful result, that's not programming - there's no order.
        3y ago
Bjartr 3y ago
IIRC, the Maven crowd was criticizing npm's decisions from the get go because they chose to ignore many of the problems the Java community already solved a decade before.
- SahAssar 3y ago
  So could you list those problems?
  - richbell 3y ago
    Namespaces, for one.
    - strken 3y ago
      Namespaces in Maven seem like they're clunky. The pseudo-DNS thing where the first section is an actual domain but the second is whatever you want is quite janky, as is not matching the namespace to the package. Plus domains are transferable themselves and it seems like a bad idea to use them as identifiers. Not to say that npm shouldn't have had namespaces by default, but I think there's good reason not to blindly do everything the way the Java community did.
      - richbell 3y ago
        > Not to say that npm shouldn't have had namespaces by default, but I think there's good reason not to blindly do everything the way the Java community did. I'm not saying that they should have blindly copied Java, but they should have had something.
  - Bjartr 3y ago
    One issue is npm will allow arbitrary code to execute as part of an install script for a package, which allows a class of attacks that aren't possible in the maven world.
ShadowBanThis01 3y ago
I never used Node and went right to Deno, partly because NPM and packages sounded like a mess. So far it has been a good experience.
baz00 3y ago
Personally I would like it and the ecosystem to just cease to exist overnight. Nothing on earth has caused so much pain, misery, suffering and agony, apart from possibly PHP. Our devops guys scream from the seething pain whenever the have to debug some pile of shit that decides it won't build unless all the runes are aligned precisely and all the RAM in the universe is available on the build runners. And pushing this to the developers results in importing more packages thus adding to the burning tyre fire. And after several hours of builds and 9000 layers of packages you wake up one morning and in that 50 meg chunk of javascript that is excreted from the process, someone managed to inject a "Slava Ukraini!" banner into your web app.
- cybrox 3y ago
  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.
  - BeefWellington 3y ago
    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)
    - felixfbecker 3y ago
      "Jim".padStart(4) has existed in JS (and Node) for 6 years now. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- ironmagma 3y ago
  I'm sorry, but there is no chance that the automake/autoconf suite of tools has caused less pain than `npm install`.
ploxiln 3y ago
Don't allow un-publishing package versions. If they are literally malware, they can be manually removed by npm admins. If a court orders a takedown due to copyright, that's also something npm admins can handle. If you want to be able to un-publish, then just publish on your own server (or github etc). If analyzing the dependencies for showing in the NPM web UI, while analyzing, as you exceed 40 direct or transitive dependencies, abort and highlight this package in red, for having excessive dependencies. If installing locally, you get what you get, don't install random or crazy packages, stick to well known high-quality minimal-dependencies packages. nodejs does include file reading and writing, http server, http client, json ... that will take you pretty far. Master the basics before getting too fancy. And remember, you don't need some company's client package just to make some http requests to their API.
cperciva 3y ago
how would you make it different? Have smarter users. If your package breaks because it depends on trivial code which got deleted, you shouldn't have depended on that in the first place. Preventing people from deleting their code -- always, or even just sometimes -- was never the right solution.
- technion 3y ago
  I know "have smarter users" sounds like a joke but a lot of the problem really is cultural. In most languages you would write a two line leftpad function, in the js world everyone will tell you you're doing it wrong and should use a library.
jonorsi 3y ago
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 or patch yourself. Definitely an impossible task given how broad and deep modern package dependencies are, but at least you’d start feeling the insanity of having all if them in the first place :P.
- quickthrower2 3y ago
  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!
  - firtoz 3y ago
    Yarn does that in some modes.
  - sakjur 3y ago
    Wouldn’t the opposite be better? I’m not sure you could take advantage of the vast majority of files in the zip files being unchanged if you kept compressed archives.
    - quickthrower2 3y ago
      Not sure what you mean but typically you don’t need to track changes of libraries to that level. At least not in the context of a repo using those libraries. I am thinking of treating them like binary .dlls.
      - sakjur 3y ago
        Source control is really good at compressing text files as they evolve over time, but isn’t optimized to handle binary assets. Since a single-line patch changes the entire zip archive, you’d risk growing the size of the repository based on the number of patches.
Stevvo 3y ago
The one thing clear in JavaScript is that if some developers think there is a better way, they will develop it and use it. That hasn't happened with NPM because its about as useful as it conceivably could be. The criticisms really amount to nothing, and tend to come from developers who don't even write JavaScript.
cxr 3y ago
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 else entirely. If you want answers, state clearly what _specific_ problem you're trying to solve. Whatever the solution to it might be, vague and fuzzy questions—while magnets for chatter since they can stand in for whatever someone wants to read out of them—are not the way to get there. (You could say that this is needlessly tedious because everyone already knows what we're talking about, but that this isn't true is exactly my position. It's certain that something like half the people reading, thinking, and writing are have in mind one thing, while the other half are thinking of another—and the third half are thinking about something different from either of those. We're also programmers, so dealing with tedium and the constraints of having to be explicit should be second nature.)
- 6510 3y ago
  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 the boats! Therefore there is nothing wrong with npm, she is a fine ship. The harbor doesn't want to take it's much desired cargo, it must sail the 7 seas forever mon capitaine!
  - StressedDev 3y ago
    HTML came before XML. Also, how is HTML crappy when it is used by millions of web sites and is one of the most successful technologies in the past 35 years? Does this mean it is perfect? No. Is it "crappy"? Nope. Also, while JavaScript had a rushed development cycle, it has grown over the past 20-30 years and you can clearly write some great programs in it. Also, it has some very good features. My favorite is you can pass functions as variable arguments. It got this before a lot of other mainstream languages.
floren 3y ago
When you use 'go get' to add a package to your Go project, it actually fetches the code through a Google proxy which saves a snapshot of the commit in question. Even if the original source goes away, they should have a copy of every version of the library ever fetched via their tool, and devs can continue to build existing stuff. (If you don't want Google to see what packages you're fetching, you can also turn this off with an environment variable.)
quickthrower2 3y ago
Soft deletes. You can delete a package and it stops being advertised but a shadow copy of referenced versions are kept for anything that depends on it. NPM spews warnings when this happens. Once the referencing packages are updated are deleted or modified the shadow versions can be dropped.
hannob 3y ago
The core of the problem is micro dependencies. It seems in the Javascript ecosystem, developers have no awareness of costs of complexity. When you wonder whether to add a dependency, you should ask yourself: What are the upsides and downsides of adding this dependency. One downside is always that by adding a dependency, you add a potential security problem, a potential point of breakage, and more complexity. There are situations where these are well justified. If your dependency is stable, from a trustworthy source, and if it is a functionality that you cannot quickly implement yourself. But if you include a dependency that is effectively one line of code, the question answers itself: The costs of adding a dependency is completely unreasonable. It your list of dependencies grows into the 100s, you're doing something wrong.
rfoo 3y ago
> how would you make it different? Make the cost of reusing software non-zero again. It doesn't have to be as painful as C++ without package managers, but should make every developer spend about 5~10 minutes labor work for adding each direct dependency, or one minute for each new dependency in the dependency closure.
throwawayqqq11 3y ago
The solution is a proper deprecation mechanism with a grace period for migration. Restricting removal or allowing instant removal are the extremes that cause trouble.
bandrami 3y ago
I don't know that there's a solution because the fundamental cause of the problem is that Javascript has a huge dev base and everybody wants to have at least one active NPM package they maintain for their resume. Nobody ever asked me as a Perl programmer what CPAN packages I've created because very few Perl programmers made them, but hiring managers will look at Javascript devs' NPM footprint.

aaomidi 3y ago

Honestly, how go does package management is pretty good.

speedgoose 3y ago
It's personal tastes perhaps, but I don't find the appeal of packages management in Golang. I find PIP, NPM, RubyGems, Nuget, Cargo,… easier to work with. The go.mod syntax is what it is, and doing updates or fixing conflicts isn't easy. Not having a registry is neat, but I'm also unsure of what is going to happen over time as dependencies may be moved or removed. You can see that with old Maven pom.xml where some dependencies do not resolve anymore.
- aaomidi 3y ago
  This is why you should vendor your dependencies. They are part of your codebase at that point.
  - speedgoose 3y ago
    I have better things to do though. This feels unnecessary.
    - aaomidi 3y ago
      “go mod vendor”. That’s it. That’s all you need to do.
      - speedgoose 3y ago
        Oh like this. I’m not sure I would enjoy overloading my git repository and merge requests with the dependencies. I was thinking about having a proxy or forking all the dependencies.
        aaomidi 3y ago
        The thing is though that those dependencies are part of your code. Seeing how they're changing through PRs and commits is actually a feature IMHO and not a bug.
- mseepgood 3y ago
  > I'm also unsure of what is going to happen over time as dependencies may be moved or removed That's what the Go module proxy is for. The authors can move or remove their repositories as much as they want, I as a dependent am not bothered by it. They would have to go through an official vetted process to get it removed from the proxy.
  - speedgoose 3y ago
    Oh I didn’t know that the proxy.golang.org was a thing. That’s good to know.

charlie0 3y ago

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.

forrestthewoods 3y ago
That’s a really good way to stagnate imho. I’d rather have 10 sorting libraries that each specialize or make different trade-offs than one library that tries to do everything. That said, you can still have a core set of “blessed” packages that serve the common needs.
- charlie0 3y ago
  I don't see how creating a definitive sorting library is stagnation compared to having 10 mediocre libraries that are all missing some sort of critical functionality.
  - jddj 3y ago
    Right. I'd be very surprised if anyone looks at languages with strong standard libs and says "I wish they had the kind of sorting I can pull in from npm"
  - MetaWhirledPeas 3y ago
    Because who is going to bother working on any packages if they risk rejection in the end? Have fun with your ______ package because it's never going to improve.
    - hnlmorg 3y ago
      There’s plenty of languages with vast standard libraries and which also have 3rd party libraries that offer the same feature as something in stdlib but more enhanced against a specific metric. You see it in Go, Python, .NET, etc.

TobyTheDog123 3y ago

The entire reason this is a big deal is that people don't know what their dependencies are. The left-pad incident wasn't a big deal because it was pulled, it was a big deal because no one could easily fix their builds and didn't even know they were depending on it, because it was a dependency of a dependency of a dependency. While it's ridiculous to expect that people will audit every single dependency and sub-dependency, it's not ridiculous to expect tooling to do the same. Packages should be given an overall quality rating (and honestly it might be great for an ecosystem as large, diverse, and welcoming-to-beginners as JS/TS), part of the score comes from the number of different dependencies/sub-dependencies -- a social package score if you will. If a package causes the dependency graph to explode, give a warning before installing it. Then, if you're NPM, you don't need all of these convoluted and exploitable policies around un-publishing.

aaomidi 3y ago
This is why I prefer vendoring dependencies. I have to actually code review them.
- mcny 3y ago
  I'd be called insane if I suggested it. I work with dotnet and I'd rather not add all the code in newtonsoft json and manually review each line. I mean where does it stop? Why not have everyone in the world code review asp.net and dot net libraries for every single website project at that rate?
  - sakjur 3y ago
    Rust’s Cargo vet offers an answer to that question. You can import a list of audits from trusted auditors, which should cover all popular packages. Now you have to audit dependencies that aren’t well-known in the community, which really is the set of dependencies that you should take an extra look at. The big popular JSON libraries can be audited by either Microsoft or some of the other large projects that are using them. You’d explicitly share your trust list in your audit file, and anything (updates or new packages) that isn’t trusted by you or one of your listed auditors is flagged for auditing. https://mozilla.github.io/cargo-vet/index.html https://mozilla.github.io/cargo-vet/index.html

notnmeyer 3y ago

i don’t know how you fix this for js, but in general i think well designed and robust standard libraries are a great place to start. the community shouldn’t need to write a bunch of tiny utility packages to do common things. in other words, make it easier to avoid the deeply nested dependency mess that js encourages.

int_19h 3y ago
This problem is a symptom of "move fast, break things" mentality that pervades the JS (and, more broadly, the web) ecosystem. The result is an ecosystem that is specifically optimized for moving fast and breaking things - which is a lot easier when the stable core is tiny.

o11c 3y ago

[flagged]

bezier-curve 3y ago
> There's a reason I still am skeptical of calling client-side devs "actual programmers". Nothing in your comment actually supports this last jab at web developers. Can you elaborate? I imagine you can't because you're arrogantly posturing.
- o11c 3y ago
  Programming is, fundamentally, the imposition of a chosen order upon the world. You can easily distinguish somebody who's new to programming by the lack of choosing or the lack of effective order, and I think it quite fair to call them "not yet a programmer" while they're in that phase. Sure, theoretically web devs can be programmers. But in practice, choice is overwhelmed by happenstance, and/or order does not follow from the choice that is made. And this isn't just on random websites (after all, 90% of everything is crap), but even for core tooling.
  - throwitaway1123 3y ago
    This is a vague statement filled with poetic language that conveys very little useful information. I can't imagine trying to parse this as a non-native English speaker and extract any sort of meaningful information from this comment.
    - o11c 3y ago
      Okay, by example then: * if you just bash on the keyboard randomly until you get a result, or just copy-paste from StackOverflow, or just let an LLVM spew something, that's not programming - there's no choice. * if you do deliberately choose something, but your choice fails to produce a meaningful result, that's not programming - there's no order.
      - 3y ago

Bjartr 3y ago

IIRC, the Maven crowd was criticizing npm's decisions from the get go because they chose to ignore many of the problems the Java community already solved a decade before.

SahAssar 3y ago
So could you list those problems?
- richbell 3y ago
  Namespaces, for one.
  - strken 3y ago
    Namespaces in Maven seem like they're clunky. The pseudo-DNS thing where the first section is an actual domain but the second is whatever you want is quite janky, as is not matching the namespace to the package. Plus domains are transferable themselves and it seems like a bad idea to use them as identifiers. Not to say that npm shouldn't have had namespaces by default, but I think there's good reason not to blindly do everything the way the Java community did.
    - richbell 3y ago
      > Not to say that npm shouldn't have had namespaces by default, but I think there's good reason not to blindly do everything the way the Java community did. I'm not saying that they should have blindly copied Java, but they should have had something.
- Bjartr 3y ago
  One issue is npm will allow arbitrary code to execute as part of an install script for a package, which allows a class of attacks that aren't possible in the maven world.

ShadowBanThis01 3y ago

I never used Node and went right to Deno, partly because NPM and packages sounded like a mess. So far it has been a good experience.

baz00 3y ago

Personally I would like it and the ecosystem to just cease to exist overnight. Nothing on earth has caused so much pain, misery, suffering and agony, apart from possibly PHP. Our devops guys scream from the seething pain whenever the have to debug some pile of shit that decides it won't build unless all the runes are aligned precisely and all the RAM in the universe is available on the build runners. And pushing this to the developers results in importing more packages thus adding to the burning tyre fire. And after several hours of builds and 9000 layers of packages you wake up one morning and in that 50 meg chunk of javascript that is excreted from the process, someone managed to inject a "Slava Ukraini!" banner into your web app.

cybrox 3y ago
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.
- BeefWellington 3y ago
  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)
  - felixfbecker 3y ago
    "Jim".padStart(4) has existed in JS (and Node) for 6 years now. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
ironmagma 3y ago
I'm sorry, but there is no chance that the automake/autoconf suite of tools has caused less pain than `npm install`.

ploxiln 3y ago

Don't allow un-publishing package versions. If they are literally malware, they can be manually removed by npm admins. If a court orders a takedown due to copyright, that's also something npm admins can handle. If you want to be able to un-publish, then just publish on your own server (or github etc). If analyzing the dependencies for showing in the NPM web UI, while analyzing, as you exceed 40 direct or transitive dependencies, abort and highlight this package in red, for having excessive dependencies. If installing locally, you get what you get, don't install random or crazy packages, stick to well known high-quality minimal-dependencies packages. nodejs does include file reading and writing, http server, http client, json ... that will take you pretty far. Master the basics before getting too fancy. And remember, you don't need some company's client package just to make some http requests to their API.

cperciva 3y ago

how would you make it different? Have smarter users. If your package breaks because it depends on trivial code which got deleted, you shouldn't have depended on that in the first place. Preventing people from deleting their code -- always, or even just sometimes -- was never the right solution.

technion 3y ago
I know "have smarter users" sounds like a joke but a lot of the problem really is cultural. In most languages you would write a two line leftpad function, in the js world everyone will tell you you're doing it wrong and should use a library.

jonorsi 3y ago

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 or patch yourself. Definitely an impossible task given how broad and deep modern package dependencies are, but at least you’d start feeling the insanity of having all if them in the first place :P.

quickthrower2 3y ago
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!
- firtoz 3y ago
  Yarn does that in some modes.
- sakjur 3y ago
  Wouldn’t the opposite be better? I’m not sure you could take advantage of the vast majority of files in the zip files being unchanged if you kept compressed archives.
  - quickthrower2 3y ago
    Not sure what you mean but typically you don’t need to track changes of libraries to that level. At least not in the context of a repo using those libraries. I am thinking of treating them like binary .dlls.
    - sakjur 3y ago
      Source control is really good at compressing text files as they evolve over time, but isn’t optimized to handle binary assets. Since a single-line patch changes the entire zip archive, you’d risk growing the size of the repository based on the number of patches.

Stevvo 3y ago

The one thing clear in JavaScript is that if some developers think there is a better way, they will develop it and use it. That hasn't happened with NPM because its about as useful as it conceivably could be. The criticisms really amount to nothing, and tend to come from developers who don't even write JavaScript.

cxr 3y ago

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 else entirely. If you want answers, state clearly what _specific_ problem you're trying to solve. Whatever the solution to it might be, vague and fuzzy questions—while magnets for chatter since they can stand in for whatever someone wants to read out of them—are not the way to get there. (You could say that this is needlessly tedious because everyone already knows what we're talking about, but that this isn't true is exactly my position. It's certain that something like half the people reading, thinking, and writing are have in mind one thing, while the other half are thinking of another—and the third half are thinking about something different from either of those. We're also programmers, so dealing with tedium and the constraints of having to be explicit should be second nature.)

6510 3y ago
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 the boats! Therefore there is nothing wrong with npm, she is a fine ship. The harbor doesn't want to take it's much desired cargo, it must sail the 7 seas forever mon capitaine!
- StressedDev 3y ago
  HTML came before XML. Also, how is HTML crappy when it is used by millions of web sites and is one of the most successful technologies in the past 35 years? Does this mean it is perfect? No. Is it "crappy"? Nope. Also, while JavaScript had a rushed development cycle, it has grown over the past 20-30 years and you can clearly write some great programs in it. Also, it has some very good features. My favorite is you can pass functions as variable arguments. It got this before a lot of other mainstream languages.

floren 3y ago

When you use 'go get' to add a package to your Go project, it actually fetches the code through a Google proxy which saves a snapshot of the commit in question. Even if the original source goes away, they should have a copy of every version of the library ever fetched via their tool, and devs can continue to build existing stuff. (If you don't want Google to see what packages you're fetching, you can also turn this off with an environment variable.)

quickthrower2 3y ago

Soft deletes. You can delete a package and it stops being advertised but a shadow copy of referenced versions are kept for anything that depends on it. NPM spews warnings when this happens. Once the referencing packages are updated are deleted or modified the shadow versions can be dropped.

hannob 3y ago

The core of the problem is micro dependencies. It seems in the Javascript ecosystem, developers have no awareness of costs of complexity. When you wonder whether to add a dependency, you should ask yourself: What are the upsides and downsides of adding this dependency. One downside is always that by adding a dependency, you add a potential security problem, a potential point of breakage, and more complexity. There are situations where these are well justified. If your dependency is stable, from a trustworthy source, and if it is a functionality that you cannot quickly implement yourself. But if you include a dependency that is effectively one line of code, the question answers itself: The costs of adding a dependency is completely unreasonable. It your list of dependencies grows into the 100s, you're doing something wrong.

rfoo 3y ago

> how would you make it different? Make the cost of reusing software non-zero again. It doesn't have to be as painful as C++ without package managers, but should make every developer spend about 5~10 minutes labor work for adding each direct dependency, or one minute for each new dependency in the dependency closure.

throwawayqqq11 3y ago

The solution is a proper deprecation mechanism with a grace period for migration. Restricting removal or allowing instant removal are the extremes that cause trouble.

bandrami 3y ago

I don't know that there's a solution because the fundamental cause of the problem is that Javascript has a huge dev base and everybody wants to have at least one active NPM package they maintain for their resume. Nobody ever asked me as a Perl programmer what CPAN packages I've created because very few Perl programmers made them, but hiring managers will look at Javascript devs' NPM footprint.