Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming breaking changes for npm v12

github.blog

Post reply on HN
Print view View original

211–220 of 221 posts

Re: Upcoming breaking changes for npm v12

#211

Post by hinkley »

amitport wrote: post #69
joeyhage wrote: post #3

Earlier quoted context omitted.

Most people know this but the _real_ reason it explains things is that GitHub is owned by Microsoft. Oh, and Microsoft moved GitHub to Azure

To be fair, NPM sucked long before it got acquired by Github/Microsoft. And to be fair 2: The other package repos also suck.

Maybe I have nostalgia blinders on but I do NOT remember putting up with this much bullshit in the Ruby ecosystem and I didn't even like ruby. Gemfiles were pretty okay, and gemfiles are what everyone assumed npm would be a copy of.

It wasn't.

Re: Upcoming breaking changes for npm v12

#212

Post by hinkley »

peterkelly wrote: post #112

Now all the malware can move from the install script to the module itself where it will inevitably still be run

But at least we have ways now to stay a week behind everyone else and see how many people drop dead before us.

So what it'll really be is people injecting exploits that are patient.

Re: Upcoming breaking changes for npm v12

#213

Post by hinkley »

cute_boi wrote: post #8

They should have added a 1-day age limit by default, so security scanners have some time.

I would have been fine with 24 hours but some of my co-maintainers asked for longer.

Which was a little weird for the modules that don't run standalone but whatever.

Re: Upcoming breaking changes for npm v12

#214

Post by hinkley »

zarzavat wrote: post #52

There's an easy way to stop most supply chain attacks: 1. Publishing users must approve each and every release from a smartphone app. 2. Publishing users must provide verified government ID. The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release. The second step discourages attacks where a user tries to get a malicious package used by others.…

No, because we've already had documented cases of people socially engineering exploits into OSS projects.

See also https://wikipedia.org/wiki/Confused_deputy_problem

You don't need permission to publish an exploit, you just need someone or something else to do it for you.

Re: Upcoming breaking changes for npm v12

#215

Post by tomnipotent »

7bit wrote: post #202
tomnipotent wrote: post #190

Earlier quoted context omitted.

No one said anything about bankruptcy, you seem to have made that up for your "argument" or whatever this is. The company didn't have a viable business model and was running out of cash. MSFT right-sized the team for the project they wanted it to be, rather than the business model the prior company was trying to be.

Learn to read > Would you rather the company went under after it ran out of money and had to fire everyone instead?

Apparently you don't understand what bankruptcy means. A company can run out of funds and not be able to meet payroll without declaring bankruptcy, they're different things. But by all means keep talking out of your ass.

Re: Upcoming breaking changes for npm v12

#216

Post by sneak »

altruios wrote: post #198
sneak wrote: post #197

Earlier quoted context omitted.

I don't think Microsoft is trying to extend and extinguish javascript or typescript. I do, however, think they are using their standard anticompetitive playbook to disadvantage IDEs that aren't VS Code and agents that aren't Copilot. For example, it requires some hackery to use your Copilot subscription via the Copilot extension in VSCodium (the f/oss distribution). They want the default to be writing javascript (whe…

> The response is to refuse to use Microsoft software. Use a Mac Or Linux: an actual FOSS OS.

Linux can’t run Lightroom or Premiere or After Effects, sadly.

Re: Upcoming breaking changes for npm v12

#217

Post by account42 »

sneak wrote: post #216
altruios wrote: post #198

Earlier quoted context omitted.

> The response is to refuse to use Microsoft software. Use a Mac Or Linux: an actual FOSS OS.

Linux can’t run Lightroom or Premiere or After Effects, sadly.

It can however run actual FOSS alternatives of these. It's a bit weird when you want to avoid MS software due to their bad business practices but are OK with Adobe.

Re: Upcoming breaking changes for npm v12

#218

Post by amitport »

hinkley wrote: post #211
amitport wrote: post #69

Earlier quoted context omitted.

To be fair, NPM sucked long before it got acquired by Github/Microsoft. And to be fair 2: The other package repos also suck.

Maybe I have nostalgia blinders on but I do NOT remember putting up with this much bullshit in the Ruby ecosystem and I didn't even like ruby. Gemfiles were pretty okay, and gemfiles are what everyone assumed npm would be a copy of. It wasn't.

[dead]

Re: Upcoming breaking changes for npm v12

#219

Post by Timon3 »

partsch wrote: post #107

I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.

Though I mostly use pnpm these days, yarn still has a feature that I frequently miss: the project-local cache[0]. Basically, every dependency archive fetched from a registry is stored in your repo in .yarn/cache, so unless you're adding/updating dependencies a `yarn install` will work fully offline.

I'm sure there are drawbacks to this method regarding repo size etc., but it just feels good knowing that my repo contains everything needed to install and run any version of my project.

[0]: https://yarnpkg.com/features/caching#offline-mirror

Re: Upcoming breaking changes for npm v12

#220

Post by Timon3 »

Timon3 wrote: post #219
partsch wrote: post #107

I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.

Though I mostly use pnpm these days, yarn still has a feature that I frequently miss: the project-local cache[0]. Basically, every dependency archive fetched from a registry is stored in your repo in .yarn/cache, so unless you're adding/updating dependencies a `yarn install` will work fully offline. I'm sure there are drawbacks to this method regarding repo size etc., but it just feels good knowing that my repo conta…

I should add: this is enabled by adding `enableGlobalCache: false` to .yarnrc.yml, though I think it was the default for a bit when Yarn 2 first released.
Post reply on HN