Nicholas Zakas

Especially when PMPM came out after one of the attacks.

I was like, okay, we're not going to let people install any package that's newer than seven days old or something in the hopes that that would prevent people from rapidly downloading

compromised packages before they could be caught and removed.

And that PNPM moved faster than NPM, I think was a bit of a wake up call for me.

Now they're doing it on the client side.

So

Now, how big of an effect does that have?

I would guess like not huge, but they were trying to do something that they seemed like might help and was within their power to do so, which I applaud them for.

And like with NPM, it just felt a little like, okay, these were some stuff that we were planning on doing anyway, and we're just going to roll those out.

And yeah, we'll see what happens.

Yeah, so I think the short answer is that, like, the inertia behind NPM is so great that it's very difficult to extricate ourselves from it at this point.

Like, any JavaScript package that you want to install, you look at the readme, it says install from NPM.

People don't even know what else to do besides go to NPM to look for these packages.

And Deno started an alternative package manager called JSR.

which I actually had high hopes for because I think that they put the type of thought into security and stability and stuff like that up front that NPM has kind of been adding on as it goes.

Just like right from the start, like not allowing package name squatting, reserving certain package scopes that could be confusing to people.

Like when I went to go sign up for JSR and I tried to grab the ESLint scope because my initial reaction was like, oh God, like here's another place that I need to grab all the usernames on.

And ESLint had been reserved.

Like you couldn't actually go on the website

And just say like, okay, I want the ESLint scope.