# NPM Security Crisis and Infrastructure Neglect

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-01-29

## Transcript

Welcome friends, I'm Jared, and you are listening to the Changelog, where each week we interview the hackers, the leaders, and the innovators of the software world.
As the creator and longtime maintainer of ES Lint, Nicholas Zakis is well positioned to criticize GitHub's recent response to NPMs in security.
He found their response insufficient and has other ideas on how GitHub could secure NPM better.
On this episode, Nicholas details his ideas, paints a bleak picture of NPM alternatives like JSR, and shares our frustration that such a critical piece of internet infrastructure feels neglected.
But first, a big thank you to our partners at Fly.io, the platform for devs who just want to ship, build fast, run any code fearlessly at Fly.io.
Okay, Nicholas Sakis, talking MPM on the changelog.
Let's do it.
This is the year we almost break the database.
Let me explain.
Where do agents actually store their stuff?
They've got vectors, relational data, conversational history, embeddings, and they're hammering the database at speeds that humans just never have done before.
And most teams are duct taping together a Postgres instance, a vector database, maybe a lasting search for search.
It's a mess.
Well, our friends at Tiger Data looked at this and said, What if the database just understood agents?
That's agentic Postgres.
It's Postgres built specifically for AI agents, and it combines three things that usually require three separate systems.
Native, model context protocol servers, MCP, hybrid search, and zero copy forks.
The MCP integration is the clever bit.
Your agents can actually talk directly to the database.
They can query data, introspect schemas, execute SQL without you writing fragile glue code.
The database essentially becomes a tool your agent can wield safely.
Then there's hybrid search.
Tiger Data merges vector similarity search with good old keyword search into a SQL query.
No separate vector database, no elastic search cluster, semantic and keyword search in one transaction.
One engine.
Okay, my favorite feature the forks.
Agents can spawn subsecond zero copy database clones for isolated testing.
This is not a database they can destroy, it's a fork.
It's a copy off of your main production database if you so choose.
We're talking a one terabyte database for it in under one second.
Your agent can run destructive experiments in a sandbox without touching production, and you only pay for the data that actually changes.
That's how copy on write works.
All your agent data, vectors, relational tables, time series metrics, conversational history lives in one queryable engine.
It's the elegant simplification that makes you wonder why we've been doing it the hard way for so long.
So if you're building with AI agents and you're tired of managing a zoo of data systems, check out our friends at Tiger Data at TigerData.com.
They've got a free trial and a CLI with an MCP server.
You can download to start experimenting right now.
Again, Tiger Data.com.
Well, friends, we're here with our new friend and good friend, Nicholas Azekis.
Known by many things, created ES Lint, author of many books, and uh a person on the internet with angst, you know.
So who doesn't have a little angst out there?
Yeah, we all get some angst.
But this one recently against the GitHub's stewardship and securing of NPM, which I know a lot of people have an issue with.
So when I saw this post and I read this post, I get you on the podcast.
So here you are.
Welcome to the show.
Yeah, thanks for having me.
I think thanks for having me back.
I think I've been here before.
JS Party, maybe, right, Jared?
JS Party?
You know, we were talking about it yesterday, and I like I I know him online.
I feel like I've met him before, but I didn't actually go back in our catalog and look you up.
So I would only assume it was either an old, old episode of the changelog or a not quite as old episode of JS Party, but for sure you've been on the network.
Yes, definitely.
I wasn't on the podcast.
That's why I said that.
Oh, okay.
Then welcome to the podcast.
Yeah, welcome to to the both of us and the three of us.
What is the best way to open this can of worms?
Honestly, I mean, we can could should we go to the end and and work way back?
How should we begin this discussion on securing NPM and what GitHub can do about it?
Yeah, that's a good question.
Um, I think it might help to talk a little bit about 2025 and what was going on with npm then, and then we can jump off from there.
So in September alone, there were 500 packages that were compromised on NPM.
Never mind the rest of the year, just 500 packages in that one month.
And those attacks didn't really look any different than any of the attacks that we've seen before.
Which is basically like somebody steals some credentials one way or another.
They start publishing compromised packages, and they usually add like a pre-install or a post-install script that executes the malicious code, and then they publish that to the registry and they just wait for people to download it.
And then as it downloads and that pre-install or post-install script runs, like that's when the trouble starts happening.
And we've seen a bunch of different iterations of this.
Sometimes it just is like looking to steal crypto.
Um, other times it's looking for secrets.
I mean, that was one of the big things last year was running truffle hog to discover secrets on the user's machine and then using those secrets to propagate itself.
I think one person lost like $500 in crypto or something like that.
But it was getting to the point where to me it's looking a lot like somebody or a bunch of somebody are trying to figure out how to get packages into NPM that will get distributed as quickly as possible to do something that is a lot more damaging than what we've seen so far.
And that was basically what led me to stop and think about what's actually going on with NPM, what could change, and I think more like what could the next attack look like if things don't change?
And from a maintainer's perspective as well, right?
Because you're looking at it from the lens of somebody who's maintaining highly used open source projects over the course of forever, right?
Yeah.
So like ESLint, which I help maintain over 200 million downloads a month.
And we have had from time to time these very mysterious pull requests that show up where all it is is somebody like changing a dependency with no description or anything.
And when we ask them, hey, like what are you trying to do on this?
What's the point of this pull request?
We get nothing.
Doesn't happen a lot, but it's happened frequently enough that it's always felt to me like a penetration test to see how easy it would be to land a pull request on ESLint because it's downloaded so much.
And knowing that it's going to go out, you know, basically immediately to all kinds of CI systems and personal laptops and what have you, like we're always very, very careful about changing dependencies and thinking about which dependencies you want to add into the ESLint package.json file.
Because there is a big responsibility when you have a package that's downloaded so frequently by so many different people.
And it just kept coming back to like no matter what I'm doing, no matter what security practices we're putting into place, it seems like there's always some way for somebody to get in and cause trouble.
And we did have, I want to say maybe nine or 10 years ago, we did actually have a compromised package get into ESLint, but it was one of our own packages.
And it was, you know, kind of traditional, somebody had reused their credentials on another site, that site had been hacked, and they ended up having their npm credentials stolen as a result.
And then they could publish ESLint packages using that.
After that, we change so that nobody's individual NPM account has published rights for ESLint packages.
But we're still in the situation where like we use so many dependencies, and not to mention like dependencies of dependencies, that it's almost impossible to protect our users if some malicious package gets in the dependency tree somehow.
So GitHub did respond to this, or they have done some changes.
I don't know if it was in response or the timing was correct that it seemed like it was in response.
And at the time, I think GitHub had announced some changes but hadn't actually done them yet or rolled them out.
Um you addressed some of those from a maintainer perspective.
It seems like your read on the GitHub changes to the way it works is more maintainer burden and perhaps too tightly scoped.
Is that fair to say?
Or you want to give your impressions of some of the things they're doing to react to this because they're in the position of the as a platform to be the most influential reactor, or like are they the ones that have to basically make some changes, right?
Yeah.
So my read on the changes that they made was that it was pushing more responsibility onto maintainers.
So eliminating the kind of older style tokens I can understand fine-grained tokens are way more secure.
Like that makes sense.
But then limiting um the lifetime of those tokens um they went through a bunch of iterations.
I think they finally landed on like 90 days.
That alone, like if you're doing token-based publishing like now you need to remember to update your tokens every 90 days or you have to implement some sort of automation to do it for you on top of whatever else you're already doing.
And the response to that was well you know if you use um trusted publishing the open ID connect feature that they have in GitHub actions then you don't need to actually store a token anymore.
It's generated on the fly and you can just publish using that.
And that sounds great.
Like it's a good solution to not just have a token laying around.
Yeah.
Somebody can use it.
It's kind of a lock in thing though, right?
It's kind of a lock in thing.
Well it is.
I mean, number one, that's great if you're on GitHub or GitLab also supports it, but what if you're not on either of those platforms?
Right.
Like not every company in the world that's publishing NPM packages is using GitHub.
You know, they might have private repositories that might be publishing directly from their internal repositories and not having stuff out on GitHub or GitLab.
And then the other problem is that there's no two factor authentication for trusted publishing.
And as a result the OpenJS Foundation even came out and just said for critical packages, we recommend that you don't you tr use trusted publishing because if somebody is able to get access to your GitHub repo all of a sudden they're going to be able to publish your packages and you won't know until it's too late.
Can you break that down?
What exactly is trusted publishing?
Yes how do you explain that?
So trusted publishing is basically, you go into NPM, and for your individual package, you say, I want to enable trusted publishing from this source code repository specifically, and then this workflow specifically, the exact name of the file.
And when you enable that, then you can upload your GitHub Actions workflow file into your repository and set the permissions for ID token.
And then GitHub Actions will, when it runs that workflow, will request a token on your behalf from NPM and then bring it back in and use it just for as long as the workflow is running, and then a token is no longer useful anymore.
So basically it's on demand one-time use tokens for NPM.
Is that uh used by a lot of maintainers?
Is it well it's not fully implemented though, right?
Well, so it's partially implemented now without two-factor authentication.
That's the big thing that's missing.
And there are a lot of people who are moving to it specifically because they don't want to have to deal with rotating tokens every 90 days.
Like that's just a lot of work.
And especially if you consider like I I think for me, I might be a maintainer for something like a hundred packages, maybe more than that, I'm not sure.
Um, some of them are pretty small and inconsequential, but sometimes those are the ones that make their way into larger dependency trees, and you can get in trouble with those.
And so the initial reaction from myself and a lot of maintainers, we read the post about the changes, was like, how are we going to scale this?
How am I going to update all of these packages to do all of this?
And there was no batch operation to update a bunch of packages.
You have to go in individually to each package and go through like multiple two-factor authentication approvals as well, just to do it for one package.
And I've been told that there's gonna be a batching tool coming out.
I'm still not there yet.
Um, but in the meantime, they still rolled out these changes fairly quickly to people to kind of force changing over to the granular tokens with shorter um TTLs and the trusted publishing.
And so there were just a lot of maintainers.
And the tools to help us do that work aren't even there yet.
Can you walk through why trusted publishing is trusted?
What makes that trusted with this part of the workflow?
Like the single workflow YAML file and actions?
What makes that trusted?
Yeah, so it's trusted because it is known ahead of time that that is the one location that you can publish from.
Like any other workflow that you add, you can ask to get the ID token and publish to npm.
Um, but that workflow is untrusted.
So it can't actually use a token to publish to NPM.
So it ends up being just a form of validation between that workflow and npm to validate that it is allowed to publish that package.
So the I guess pre-ceremony, the the PETA factor of this pre-ceremony is what makes it more trustable because you're going to go through the emotions of actually setting it up, naming it, defining it, putting the repo.
There's some sort of song and dance between GitHub and NPM to trust that singular YAML file, and that's the one that's trusted, that workflow.
Yeah, which again, like is actually a nice system.
Um if you're on GitHub or GitLab and you don't worry too much about needing two factor authentication, it's a decent system, but to me, again, it's still GitHub and NPM saying, like, okay, maintainers, like you need to do more to protect everybody from you being a victim of your credentials being stolen.
Which is why in my post I use the analogy of credit cards, where like there's a lot of fraud using credit cards, and that's why credit card companies keep introducing new ways of um validating that you're the authorized user of the card that you're using, whether that be the CBC number on the back or the chip that is in the card, or in Europe needing to add a pin in addition to your chip.
They do all of that stuff to hopefully prevent people from using your credit card number without your permission.
Um, which again is great.
Like we should do that.
There needs to be some way to help consumers of credit cards, users of NPM to protect themselves from having their information stolen.
But credit cards don't just stop there, right?
They're also doing anomaly detection with each transaction that's coming through to figure out like, does that look like something you would normally do?
And so if you've ever been traveling or just make a big purchase, you may get a text message that says, Hey, we just got this charge for this amount at this location.
Was this you?
And if you say yes, it says great, you know, go right ahead.
If it says no, then it will block the transaction and they start the fraud investigation process.
And in that way, they know that hey, nobody's going to be a hundred percent at protecting their information from being stolen for a variety of reasons.
So let's not just rely on that.
Let's also do some analysis and see if we can figure out if something bad is going on before it gets too far down the line.
And that's where I think that NPM has been kind of missing some clear actions that they could be taking to protect us better.
What makes you think they're not doing that already and just doing it poorly?
Well, from what I can tell, they have some ability to do this.
And I just feel like the technology is there to prevent the mess before it happens.
Um, and for whatever reason, I'm guessing, probably lack of resourcing, um, that it's just not getting done because I have talked with folks who work on NPM, like they're really dedicated, they're really smart.
And the sense that I always get is just like there's a really big backlog, there's not enough people to work on it.
And so the stuff just kind of sits until there's an emergency.
And my read on the response last year, and I have no inside knowledge of this at all.
This is just my interpretation of what I was seeing.
Um, was that the things that they were rolling out were things that were probably already on their roadmap and just needed a little push.
And this was the push of like, you know, running it up the chain and just saying, hey, these like three things we've been trying to get through for the past nine months.
Like this would actually really help with these attacks.
So can we prioritize and resource these?
And that's why we got those.
Again, just my theory, but it just it seems like, and and I gave this feedback directly to them too, that I just feel like all of this is attacking the problem from the wrong end at this point.
Well, friends, I don't know about you, but something bothers me about GitHub Actions.
I love the fact that it's there.
I love the fact that it's so ubiquitous.
I love the fact that agents that do my coding for me believe that my CI CD workflow begins with drafting Toml files for GitHub Actions.
That's great.
It's all great.
Until, yes, until your builds start moving like molasses.
GitHub Actions is slow.
It's just the way it is.
That's how it works.
I'm sorry, but I'm not sorry because our friends at namespace, they fix that.
Yes, we use namespace.so to do all of our builds so much faster.
Namespace is like GitHub Actions, but faster.
I mean, like way faster.
It caches everything smartly.
It caches your dependencies, your Docker layers, your build artifacts.
So your CI can run super fast.
You get shorter feedback loops, happier developers because we love our time.
And you get fewer.
I'll be back after this coffee, and my build finishes.
So that's that's not cool.
The best part is it's drop-in.
It works right alongside your existing GitHub Actions with almost zero config.
It's a one-line change.
So you can speed up your builds, you can delight your team, and you can finally stop pretending that build time is focus time.
It's not.
Learn more, go to namespace.so.
That's namespaced.so, just like it sounds, like it said.
Go there, check them out.
We use them, we love them, and you should too.
Namespace dot so.
Well, there's one big difference between the credit card companies and GitHub slash Microsoft.
Otherwise, I agree with you entirely with the methodology of like, you know, inference and fraud detection, like analysis, be more proactive than reactive, etc.
Is that the credit card companies get paid per transaction, you know?
So like there's money directly tied to that process.
And what is NPM to GitHub to Microsoft?
You know, it's it seemed like it was a fig leaf at a time when NPM needed one, you know, to continue to exist.
And so acquisition, but where is the revenue coming from?
Like what's it doing for GitHub?
What's it doing for Microsoft?
And so I understand, although we tend to get cynical over time, I understand why it's hard to actually allocate more resources because it's like this is not their main thing, it's not even their like seventh main thing.
It's just like a thing that they have that's hanging off another thing that they bought.
Like they bought the GitHub and they got the NPM, and they're like, well, you know, like I understand it's for the rest of us, it sucks.
And what do they lose?
When we have these that they lose a little bit of goodwill, right?
A little brand tarnishment, but not much.
They're not losing enough trust that they're not making money on transactions, where it's like credit card companies, you gotta trust that credit card company in order to actually use their card.
And for Microsoft, you know, if there's another NPM security breach, I'm I'm sure they don't like it.
Nobody likes it, but it's not revenue generated.
And so, how do you actually get that done?
And that's probably explaining some of the what you're sensing is the lack of resourcing, is probably the reason why.
I'm not sure if you ever, if we ever bridge that gap, you know, like how is it ever going to be worth it for them?
Yeah.
And I think that's exactly the problem, is that the NPM registry is a huge cost sink.
Yes, like it is wildly expensive to run, requires a ton of bandwidth, all kinds of companies are relying on it every day, running in their CI.
Um, and when the NPM company, npm Inc.
Um, was running, like they needed to sell because they couldn't afford to run the registry anymore.
Right.
And it really was GitHub being like, hey, you know, we are a haven for JavaScript developers.
They didn't have to do that.
They didn't need it.
Because at the time, I think it was just a few months earlier, they had actually announced their own NPM compatible registry built into GitHub, um, which is still there, but doesn't seem like people use all that much, except maybe as like private repos inside of companies.
Um, so they didn't really need to buy npm.
And I don't know who would have bought it otherwise.
But at the same time, it's like, you know, if you adopt a dog, you should take care of the dog.
We all agree on that.
Like you can't just adopt it.
Take care of the dog, GitHub.
Well, I mean, I think they would argue, well, we are taking care of it.
We have a staff of three and their entire point, and we're paying, I'm just baiting out that number.
But you know, like, well, there's three people, full timers.
We can calculate that out.
We're talking a million dollars a year that we're just keeping the dog alive, you know, or whatever the number is.
Yeah.
Yeah, absolutely.
And it's not going to get better than that.
They're not going to go to two million.
There's no reason to, as long as the dog's still alive.
Now, maybe it gets so bad that the dog eventually dies.
Right.
Well, so my counter to this argument, which uh I'm I completely understand, is that all it takes is one attack that costs people millions of dollars in some way, or costs a company millions of dollars before this becomes not just a like, oh yeah, hey, we're keeping it alive, but you know, like there's a responsibility because if you don't take care of that dog, it's gonna start biting everybody in the neighborhood.
Um then you're looking at not just like, oh, this is you know, it tarnishes our reputation, like it doesn't look good.
Um, now you're looking at like significant financial repercussions.
And you know, I'm sure there's stuff in the terms of service that says that they can't be sued.
Um but that's I was gonna ask, like you actually go after them legally to negligence or something.
Um but you know, there still might be some big company out there that's like, hey, you know what?
We're just gonna try it because we're a you know multi billion dollar company and we have the money to throw it lawyers, and uh why not?
We'll give it a shot and see what happens.
Um but this has been my concern for several years now is that when you treat these attacks as a nuisance, you leave the door open for more sophisticated attacks that are gonna cause more trouble in the future.
And I don't know what those look like.
Um I mean, I could imagine another type of situation where we had the crypto stealing um package, like what if that wasn't targeting a crypto website?
Like, what if that was targeting like a major banking website or um a major stock exchange website?
Um, what would happen in that situation?
And would those people uh who lost money through an NPM package that was compromised, would they even understand what was going on um or would it just be like oh by virtue of being on the laptop I just got screwed so that big I feel like that bigger attack is coming if something major doesn't change it's likely right I mean it's likely that a large player in some game with uh you know deep implications is using dependencies from get or npm it's you know it's like a 99% likelihood that someone's using it somewhere on the front end and it's a tag vector you may already be exploited right yeah you may you know these little pokes may actually be just the precursor uh Nicholas do you have any insight into how staffed npm is given you know your presence in the community I don't um I've only had direct contact with one person um and I don't feel at liberty to discuss what we've what we've right talked about.
But I don't have an idea of how big the team is.
My only sense is that it's fairly small.
Yeah, I would I would say demystify the black box of staffing just so the community knows.
Yeah.
Is it being staffed?
Is it is it understaffed?
Is it, you know, like I don't know.
I mean, if we're relying on this registry and ecosystem, at least be clear on what is uh what's not clear with that part of it.
Like tell us.
Yeah.
I mean, it's I think last year I opened up an issue on NPM, and maybe by the end of the year it got a response.
Like, not even a like, oh, this is a good idea, this is a bad idea, just a like, oh hey, that's interesting.
And that was a good indicator to me that it was probably not resourced um yeah appropriately.
I mean, especially when like P NPM came out after one of the attacks and was like, okay, we're not gonna let people install any package that's like newer than seven days old or something, in the hopes that that would prevent people from like 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 you know how big of an effect does that have?
I would guess like not huge.
Um, but they were trying to do something that they seemed like might help and was within their power to do so, um, 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 gonna roll those out.
And um yeah, we'll see what happens.
Yeah.
Let me ask a question that's maybe been asked, but maybe not directly like this.
Like, is it still prudent to even use npm given like the fact that she put an issue out there and it took that long to get a response, or just the seemingly lack of speed or initiative on the nuances?
Like, I don't think security is a nuance, but you'd mentioned that they're a nuisance, which is a close N-word to that.
You know, what's going on?
I mean, should we keep using NPM?
Are there alternatives?
Should we create an alternative?
If it was a possibility, what would that organization look like?
Do you have any insights there?
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, I mean, any JavaScript package that you want to install, you look at the README, it says install from NPM.
Like people don't even know what else to do besides go to npm to look for these packages.
And you know, Dino started an alternative package manager um called JSR, uh, which I actually had high hopes for because I think that they put the type of thought into um 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 uh scope.
You actually had to apply for it and prove that like you're the right person to be handling that scope.
And they approved me really quickly because they they knew who I was and that I was involved with ESLint.
So I was able to get that.
Um they had trusted publishing right from the start, or else you have to use two-factor authentication to publish locally.
They, you know, no pre-install or post-install scripts.
There's just a lot that was really good about JSR, and it basically suffered the same fate as NPM, just on a much faster timeline, which was basically, you know, there was a lot of like a lot of interest early on, um, a lot of activity, a lot of iteration.
Like I was filing issues on the JSR GitHub repo.
They were getting answered like sometime within hours, um, and things just getting fixed and pushed out.
But eventually that timeline started expanding to the point where I wasn't getting any responses anymore.
Uh, even to you know, bug reports.
There was uh, I mean, I was finally able to get one response when a new version of Dino was pushed out, and that broke the command line, the JSR command line tool.
Was finally able to get a response from them to get that fixed fairly quickly.
Um, they had announced that it was going to be an open governance uh registry for JavaScript, and they had formed uh a committee that had people from like NPM and Dino and I think OpenJS Foundation and Volt, and that just kind of went nowhere.
Um, there hasn't been any updates since then.
Like JSR is still running, but as far as I can tell, it's mostly an abandoned project at this point, and there's just you know, some of the Dino diehards like really like to use it, but it doesn't seem like it's ever going to be a real competition for npm registry.
What is the downside to pre and post-install hooks?
I get what they do.
Well, what is the downside?
You said there's none on JSR.
Is that something you agree with?
Is there a way to do it safely?
What are your thoughts?
Yeah, so pre-install and post-install scripts on npm are designed to let you run uh additional commands after install in order for a package to work.
And you know, npm was based on a package manager at Yahoo, where I worked for five years, um, called Yinst.
And Yinst was the way that all of the machines were built inside of Yahoo.
And these pre-install and post-install scripts could run in Yinst to help you set things up after you got resources installed.
And that turned out to be pretty helpful to be able to set up machines.
That was copied over into npm with the same idea.
The difference though is that Yinst was an internal system.
So there was implicit trust with all of the packages that were published in Yinst.
For NPM being a public system, you don't have that implicit trust.
And I think that this is probably something Isaac would have rethought when he was designing the system, um, knowing what he knows now.
Um but the npm ecosystem kind of became dependent on those scripts because of the ability to publish native NPM packages that were actually compiled, like C C packages, where you can't publish the uh the compiled artifact itself because it has to be compiled individually for each machine.
And so these post install scripts are what allow these native modules to be used and installed on any machine, because it just downloads the source code, and then on your machine it compiles it into the form that can be used, and then you can just run it.
And there are a lot of packages that use that now.
Because you know, every once in a while somebody will say, like, well, we'll just ban like pre-install and post install packages.
But if you do that is you can actually say, you kill off a non-trivial portion of packages on npm install dash dash ignore scripts and it won't run any of those scripts.
And that's a great solution unless you end up with one of those packages in your dependency tree that needs to be compiled, and you might not even be aware of it.
And so, you know, just disabling that or just always saying like don't run those scripts, that also has the effect of potentially breaking people's experiences in ways that they didn't anticipate.
And if you've ever had any trouble with a deep dependency that needs to be compiled that wasn't compiling, it is really difficult to debug.
And so I think any package manager that would start from scratch, or any registry that would start from scratch now, would be wise to not even have this concept of pre-install and post-install scripts, and just say, you know, we're not dealing with compiled packages at all, which is what JSR does.
But if you want to enable compiled packages, it's kind of the necessary evil you have to accept.
Do you mean the post install or pre-install is going to install a compiled binary?
And that's the threat, is that it's compiled and you can't see into it?
No, so the threat is that the pre-install and post-install can run anything.
Yeah, exactly.
Like it might not compile anything.
And this is what what happened last year was these packages would download and install Treffle Hog, which is a secret scanner, and just execute it and find all the secrets and tokens on your computer when you downloaded it.
It's one of those situations that like Dino was trying to prevent with its permission system of like, okay, you have an NPM package.
Like, should it be able to call back out to the internet for some reason by default?
Like that kind of seems like a bad idea.
And so the permission system in Dino was built so that any time a package was trying to do something that was unanticipated, um, reach out to the network, read something on the file system, you would have to opt into that behavior.
And I know there's been some experiments with that on npm.
Um, I don't think that those permissions actually apply to pre and post install scripts, if I remember correctly.
Um that is something that they could look at as well of just like, okay, maybe preinstall post install scripts are not allowed to just willy-nilly like go out to the internet.
Maybe they need to um get like opt-in permission from the user in order to do that first.
Um, I imagine that would be a little bit more complicated than I'm making it sound.
Um it's you know, uh another another option around those.
I mean, my preferred option, which I talked about in the post, is just say, hey, you know, if a package previously did not have a pre-install or a post-install script, and then it adds one.
Like, don't allow it to be a patch or a minor version upgrade.
Like force it to be a major version upgrade.
Um, because for most people that will not be installed automatically, um, as like the minor and the patch versions are.
So if we just said, like, oh, hell hold on.
For this like one dot x branch of this package, you never had a post-install script before.
Um, and now you do.
Sorry, you gotta bump that to 2.0.0 um before we're gonna publish it for you.
And I think that that alone would slow down um attackers tremendously.
Yeah, because people will just not automatically be downloading those packages anymore.
And hopefully someone, like maybe it's socket or maybe it's npm themselves, um, will then have the time to identify that as malicious and get it pulled down before it is downloaded millions of times.
That's also gonna suggest, like, if it's uh I like your idea, of course, as well.
I think uh a major version bump is gonna slow it down.
It's not gonna prevent publishing, it still allows movement.
So if it's your package, you can still move along, but anyone else has to sort of adopt that based upon their SEMVR.
But what if you were constantly scanning any any package or project that had a pre or post install script, anytime those were added or included in forevermore, that one gets special attention, special scrutiny on that script.
If you're base64ing something, if you're doing something nefarious, if you're making a network call, if you're doing an install of any sort, it's looked at and it has to be scanned and verified, like a security verification so that at least you have some check and balance.
Yeah, I like that idea a lot.
I think that for too long, we've just been saying, like, oh, you know, they go and add a post install script, and gosh, like that's terrible.
Um, but yeah, I think it's great if it's done wisely.
Yeah, I like the idea, you know, a lot.
But there are all kinds of things that I think can be done with these packages to just make sure that they're safe.
And yeah, I love that idea of just providing extra scrutiny to those.
I mean, it it could be the case that like you know you even need like a waiting period.
Um, if you're changing or adding post install scripts, like uh, and this is the thing that that I found a bit frustrating, is I feel like there are some low-hanging fruit options that are out there that would actually not be very resource intensive to implement on npm, um, which is why my suggestion of just requiring a major version bump was one of the things that I put out there.
Like, I don't think it's super complicated to implement.
But like let's just start doing something during the published process instead of just relying on people discovering it after something has been published and then downloaded a bunch of times.
I mean, you can even introduce, I mean, you got verified publishing, why not verified publishers?
You know, if you're gonna give somebody the PTA factor to, you know, make a token, you know, renewable in some way, shape, or form, or a just in time credential that makes sense for the for the maintainer.
Why not only give certain types of ability, like the pre and post-install, for example.
If it's such a powerful thing, anyone who wants to use that, in addition to that, verify all maintainers or the organization or the maintainer, the kind of core maintainer.
Uh have some sort of connection to one real person inside of that package, project, whatever.
And if you can't, if you can't do that, then I'm sorry, you don't get that very special ability for this trusted network or should be trusted network.
It takes people though, right?
A lot of software can uh can automate a lot of that, really.
I mean, you could do a lot with that process.
Yeah, I think that the resources for that would probably be fairly high and probably more than they could get in a short term.
Let me say though, I think if you if you're GitHub though, right, if this is GitHub, which it is, then you have GitHub at your at your ready.
So for those publishers, one easy way you can do it, or one easier way is you can leverage the already need for securing GitHub, which is that project or that person has to use GitHub auth.
So you have a one person or somebody there, like you can leverage at least GitHub auth and all the security put behind GitHub itself to have one verified member or at least one member in the party.
Gotcha.
Yeah, yeah.
Interesting.
I I think potentially an easier solution, which is a little bit um heavy-handed, is you could just say, okay, all packages that have pre and post-install scripts right now, you can keep doing it.
Anybody else, you don't get to do it.
Um, we're we're basically cutting that off now and saying that you know, we're grandfathering in all those old packages so they will continue to work.
But new packages, sorry, you're out of luck, we're just not going to do it for you.
You need to figure out a different way to distribute stuff.
And you can just tell your users a couple steps before and after, right?
I mean, yeah.
That's that's the easiest probable, you know, method that you could do is is just tell your users you got to do something before and do something after to make this work right.
Yeah.
It's unfortunate.
Yeah, just go ahead and write your own shell script.
You know, or if you know, here's the shell script, download it, and you need to run this, and then after that, it's fine.
Right.
It's yeah.
But you know, again, I I feel like there are some lightweight solutions that could be done instead of putting more responsibility on maintainers every time there's an attack.
Well, friends, this episode is brought to you by Squarespace.
I love Squarespace.
I'm a user of Squarespace, and Squarespace is an awesome all-in-one platform where you can stand up a professional site, offer paid services, get paid the whole thing without writing a single line of code or debugging CSS.
They've even got Blueprint AI now, which takes basic info about what you're building and generates a fully custom site with actual design recommendations.
Not a template you have to fight with, but a starting point that already looks like you thought about how it should look.
And for the data nerds out there, I know you.
That's me too.
Built in analytics are cool.
See your traffic, see your revenue, see your bookings, see your sales, figure out where to focus, all from one single dashboard.
No third-party apps, no GDPR headaches.
Just there for you.
And whether you're launching a side project, selling a course, or finally replacing that under construction web page you've been kicking around.
Squarespace handles the website part so you can focus on the thing you actually want to build and the content you want to create.
So head to squarespace.com/slash changelow for a free trial.
And when you're ready to launch, use our offer code changelog to save 10% off your first purchase of a website Bory Domain.
Once again, squarespace.com slash changelog.
I'm saddened by your report about JSR.
I had high hopes for it.
It seemed like like you said, it was off to a good start.
And I wonder what happened there, like what why?
But um what about Volt?
You mentioned Volt, that's another one that's been up and coming uh from longtime, you know, JS ecosystem people, Darcy Clark and friends, and then backed by a lot of people who have been around the ecosystem forever and have you know benefited and had issues with NPM over the years.
Is Volt been manifest?
Is it a thing?
Is it still becoming a thing?
Is it a viable option?
Because eventually we can't make GitHub do anything, and so if they're not going to do anything, we can continue to tell them they should and try to convince them.
But having some other alternative, which I was hoping JSR would become, would be at least somewhere you could put your efforts into and say, let's all do this instead.
And it would be grassroots and it would be a lot of work.
And I understand there's billions of things being downloaded every month off of NPM.
But if the package maintainers had somewhere to point people and say, you know what, for new versions of Yes Blint, you gotta go here, you know, put it in your post install script.
This is an old version of ESLint.
For the new version, I'm only publishing on this other platform for you know, go read my blog for the reasons.
If you can get like the top hundred packages from maintainers to do that, like you could probably make a dent, but we have to have somewhere to go.
And uh if JSR is not gonna be it, is Volt an alternative?
What do you know, what do you know about that one?
Yeah, so Volt, as far as I know was not in the business of providing a registry.
It was more around tooling around NPM.
Like a c a new client that does fancier stuff or yeah, basically new client does fancier stuff, um more secure, et cetera.
Um I I haven't seen anything notable come out of that.
In fact, again I I'm starting to think this might be me.
Um, you know, I opened I I was trying out one of the Volt tools, and I went and I I found a problem and I opened an issue on the GitHub repo.
And again, it just sat there for months, just no response um at all until like very, very late.
I I mean, again, maybe by the end of the year, somebody was like, Oh, this is fixed in the latest version.
It's just I don't know what's happening over there.
And uh it just it I don't think that JavaScript registries are good business.
Fun fundamentally.
And I think that um, you know, npm Inc figure that out, and glad for them that they were able to get out and and get the registry into um a place where it would at least be up and running.
I feel like JSR basically the same thing happened where you know JSR was being funded primarily through Dino, even though they wanted to make it more of a community thing, but like fundamentally, like they came up with it, they were running it, you know, they had it on their infrastructure.
But you know, they are a startup, like they need to figure out ways to make money, and JSR was just a way to spend money.
I mean, it's nice, it's a nice gift to the ecosystem, but they still need to figure out a way to turn a profit to pay back investors.
So the chances I think that JSR is going to grow up into something else is probably pretty slim.
And like you, I was pretty excited about it.
I think they got a lot of stuff right, but one of the challenges of again, like having a uh competitor to npm is like number one, you can't actually do quote unquote binaries like ESLint on JSR.
You can't just say like JSR install eslint and then just run ESLint.
Like it doesn't work that way.
And then two, any alternative to npm needs to be compatible with npm.
Because unless you're able to use all of the packages just on that new registry, you're gonna have to mix and match between npm and that new registry.
Sure.
And that's also something that JSR just did not get right.
Um if you try to use JSR packages in with npm packages in a package that you want to publish, just straight up doesn't work.
Um you have because we tried to do this um with one of our ESLint packages because the nice thing about JSR is Dino published a bunch of like standard library type packages on there, and they're really good.
And so we wanted to use one in one of our packages.
Um, and it ended up being such a pain that we just copied the source code from the JSR package into our repo in order that so we could package it and publish it up onto npm.
So like that story was just not there at all.
Um, it was okay if you were just building up an application that you were not gonna be publishing to npm, you're just gonna be deploying.
Like that worked okay.
Um, but then going and publishing that back to npm just did not work at all.
So we're stuck.
Yeah.
I don't know.
I got an idea.
All right, let's hear it.
Well, what if, and I know Bun is not a registry, but what if Bun is very fast?
What if by the sheer weight of anthropic behind Bun now saw this as a blind spot and an opportunity?
They obviously invested in Bun anyways.
I'm not sure of the implications behind it.
There's a lot of speculation, of course.
But with the sheer weight they have with just the weight, their deep coffers, their money, their et cetera.
What if they can recreate what NPM is?
They're already npm compatible.
What if they could redo but better with maybe AI, native provenance, et cetera, anomaly detection, taker advice, Nicholas, et cetera.
Like, what if what if they took it on and they said, you know what, we're gonna do this?
Could they could they sway all the maintainers away from npm by the sheer weight of who they are right now?
Yeah, I don't think so.
Okay.
And part of the reason is it seems like a lot of developers are very skeptical of AI companies and providing data that can be used to train AIs.
Like there's there was a lot in 2025 of people being like, oh, look at this, like terms of service, they've now included that your data can be used to train AIs.
And I feel like if Anthropic were to start a registry, that would be like day one, people being like, wait a second.
Am I just feeding Anthropic like my copyrighted materials so it can continue to train Claude?
Uh I think that would be a major barrier to that.
I think that's a fair point.
Yeah.
What about they just what about the users?
You know, all they need to do is convince Claude to use their registry, and then the rest of us are just riding.
It's true.
We're just riding Claude's back anyway at this point, all right.
Yeah.
I well, I I think it it would be interesting if uh if they started having Claude say, like, no, you got to use the anthropic official registry.
Um but I could also imagine, you know, similar upset developers.
User backlash against Claude now.
Yeah, totally.
Yeah, and and also just you know, from an operational standpoint, um, I don't know that anthropic has the operational experience to be able to keep a high volume registry up and running at this point.
I mean, that that's something that I mean, there were really smart people.
Explain that.
What does it take to do that?
I would be lying if I said I knew exactly.
Um, so you're speculating.
But well, no, because I know, like I knew a bunch of the people who started NPM Inc., we worked together at Yahoo.
Really, really smart people coming from Yahoo that had really, really good operational systems and being able to pull people you know from that ecosystem in to help build up NPM.
I mean, people forget now, but like the NPM registry used to go down a lot in the early days.
And even after they got their funding, like it took a while before it reached stability.
And there's you know a lot of, again, I'm not gonna lie and say I know how to keep a registry online myself, because I've always been more of a front-end developer than a back-end developer.
Um, but just you know, off the top of my head, how many like read replicas that you need and where you need them?
What sort of traffic are you getting from publishing and how frequently?
And like how do you cache effectively to make sure that CI systems are up to date and also not unstable?
There's a lot that goes into managing the registry.
I would say, you know, it's probably kind of similar to like running YouTube in a way.
Because YouTube, before they got bought by Google, like this was also a problem of just like managing the scale that was going on.
And part of why Google was an ideal destination for YouTube was they had the infrastructure and the operational knowledge in order to keep that site up and running, even with all of the traffic and all the bandwidth that it eats up every day.
Um, and again, if you look at Claude, like how frequently does Cloud go down because they run into like bandwidth issues.
Like it still is more frequently than you'd like to admit.
They're getting better, but like it still happens.
So you're you're not down with you don't think the world will be down with anthropic slash bun registry, NPM compatible, anomaly detection, AI native, et cetera, et cetera, et cetera.
I don't personally.
I I think that for a registry to have a chance to compete with npm, I think it has to come from a company or a person starting a company that is already trusted by the community.
And that's why I thought JSR had a real shot.
Because coming out of Dino, coming from Ryan Dahl, already had like a lot of trust in the community, and you know, always presenting himself as like wanting to do the right thing for the JavaScript ecosystem.
I thought JSR really had that shot.
And to see it kind of fade away has been really disappointing.
Well, I think JSR was open source and supposed to be it is.
Like you said, governed open.
So there's opportunity for somebody else to pick up the mantle and run with it if there's no movement from the Dino team any further.
If we look around all these different package ecosystems, like how do they all do it?
Or is NPM at such scale that it doesn't really matter how RubyGems does it, how Perl continues to do it.
I know Pearl has like CPAN, which is mirrored around the world on different servers.
Uh Rust, I think is the Rust Foundation, but it's like way smaller in terms of how many crates there are compared to NPM packages.
Um Java.
I think Java isn't Maven run by like a single entity that sells commercial services.
Are these all just like the scale isn't the same, so it doesn't really matter how they're doing it successfully?
Or what are your thoughts on that?
Yeah, I think that's exactly it.
I think it's a scaling problem.
Um because like there are package managers around before npm existed.
And you know, RubyGems, um crates came around afterwards and was kind of inspired by NPM, but like they don't have anywhere near the scale.
No, but what about PyPy, for instance?
Like Python has huge scale.
Yeah, I don't know that much about the Python ecosystem.
Uh I mean, neither knows the Python's foundation, Python what foundation?
Yeah, it seems to me these other languages usually follow a predictable pattern of at some point.
Some developer was like, we need a package manager.
They made one, people started using it, they started a foundation or a nonprofit or something that just kind of gets donations to keep it up and running.
Yeah.
And I think that that's where like the JavaScript story kind of went sideways.
Of like, you know, it was started as you know, a side project by Isaac Schluder.
And trying to find a home for that, he started NPM Inc., right, a for-profit business.
And I think that that was probably the point at which the divergence from other languages hurt the long-term plan for the registry.
Like because again, like once you become a startup, you take VC, you're on the hook for making money, you're figuring out how.
And then if you can't figure out how they want you to sell to try to get as much money as possible to get it back, like you know, maybe in some ideal world, um the NPM registry would have ended up instead of it a for-profit company, in you know, at the time the jQuery Foundation, which went on to become the OpenJS Foundation.
Right.
I think that an ideal world that is probably what would have happened.
Although I don't know, you know, ESLint is part of the OpenJS Foundation, so I do have some insight into how the foundation works.
And I also don't know how the foundation would have been able to afford to keep the registry running.
Probably the same way any foundation does is just donations.
They'd have to just beat the streets for bigger donations from funded companies that really want JavaScript to win, like Google, for instance.
When the web wins, Google wins, at least historically.
Yep.
And so they would be probably a sponsor, and it would just be like, let's just break even and continue to break even and pay these bandwidth costs and AWS costs or whatever it takes to run the thing.
And that's how they're all running.
But like you said, the scale is bigger than the I did confirm Python Software Foundation.
I'm not sure what I was talking about with Python Science Foundation.
The PSF has oversight and donations, sponsorships, AWS Google Data Dog, provide 10,000 Fastly provides $10,000 per month hosting.
That's just reading this from a LLM lookup.
So fact check that.
But it makes sense that like that's that's the way it's working.
It probably doesn't always work great.
There's I'm sure there's push and pull on the direction, and there's probably drama around all the things, but like that's kind of how community-run important things are maintained and continue, but they don't have the profit mode and beh motive behind them.
And so I think you're right on track there with like turning it into a business.
And had it gone to the OpenJS Foundation versus to GitHub, perhaps that would have killed it off for good, or perhaps it would have given it a better chance.
I don't know.
Obviously, we can't do the uh parallel histories, but it's not in it's in an okay place as it continues to exist.
It operates pretty well, but it's so important now that the stakes have been, you know, ratcheted up on the security side, and there are more things that need to be done, and there's really not much of incentive besides, like you said, some pending nuclear moment of terrible press and like user backlash and all these things.
A huge security breach, perhaps legal action that would actually motivate them to really go after it.
Or just the cool factor, man.
Just the cool factor of of uh implementing anomaly detection and like these verified users, and like that would be that'd be a fun job, you know, to to save potentially.
I mean, it's not a save, because I mean you're gonna keep using it, but you're kind of using it begrudgingly.
You're not exactly thrilled that your MPM is not as secure as it should be.
It's like the road to there is paid with potholes and thieves and you know, people with weapons and stuff trying to take me out.
It's like that's not a good road.
That's an exaggeration, of course.
But uh, but uh you know, you've only got the one road to go down and not much choice.
And even if there was choice, based on what you've said, Nicholas, is that even with that choice, there might not be a mass uh exodus away from MPM to something else just because of its gravity.
I mean the packages behind NPM is three point.
I mean, if this math is correct, as of late 2005, 3.1 million packages is according to Wikipedia.
So Wikipedia is better.
I mean, that's a lot of packages.
That's a lot of people to move.
I mean, you don't want to swap out your just-in-time credentials, let alone move to something else with maybe different tooling, maybe better tooling.
Who knows?
Yeah, they'd have to have a good reason.
Yeah.
And security rarely moves people very fast or far.
Uh, it might this community though.
I mean, if there's a lot of fear of its uncertainty because of security in particular.
It seems like the profit incentive could be there though.
And when you see companies like Volt and companies like Socket springing up, basically because of these problems.
Right.
Like it seems like there's some possibility there of um GitHub just saying, like, look, you know, there are companies that are willing to pay for these types of services.
Like, maybe we can offer those services and use that to offset some of the cost of implementing these changes on NPM to say, hey, if you want like the fastest notification of potential security threats or what have you, like you sign up for the service, we're gonna use that money, funnel it into the NPM team, and you know, start funding it that way.
I mean, I I just I feel like there's a lack of creativity in the solutions at this point.
Because there's there's a whole world of possibilities out there to be able to turn it from turn npm from just like a cost sync into something that could maybe break even.
Yeah.
Or you know, maybe at least just not be the albatross that you're dealing with constantly.
Um, like I think it's wishful thinking at this point that GitHub would willingly spin off NPM into a foundation.
I mean, they could certainly do it.
Like it wouldn't hurt them financially to just say, hey, you know what?
We want to start a foundation or give it to the OpenJS Foundation as part of that.
We've come to an agreement with you know Google and Meta and whoever else that like we're gonna jointly fund registry operations um by donations to the OpenJS Foundation.
OpenJS Foundation will be in charge of like hiring engineers to work on it based on that.
Like maybe that's an off-ramp for them.
Uh I don't know if they'd be open to that, but say uh there's just there's a lot more options out there than I think are being discussed or even considered at this point.
For sure.
For sure.
Let me take this uh as an opportunity to invite anybody who has insight into the underpinnings, the behind the scenes of NPM.
Uh open invite.
Come on.
Let's talk about whatever you want to talk about.
Let's even spip all some ideas live here on the podcast.
Maybe even spin up a cloud code session and whip up a new feature for you.
Who knows?
And I'm trying to say, well, we'll get some we'll get some action here.
I was gonna say get Nicholas hired on there to come in and write the ship, you know, bring him in.
He's got good ideas.
Would you do that, Nicholas?
Hey, happy to.
If uh if I can help.
There you go.
I'm I'm out here willing to help.
Yeah, what is your day?
What do you what is your day-to-day look like?
What are you up to?
Uh well, I'm at the moment independent software engineer, so I just take on you know contracting, consulting work.
I work on ESLint um as I'm able.
And I do uh coaching for software engineers, just helping people when they kind of reach those upper levels of the IC track, you know, tech lead, staff engineer, principal engineer, um, which I did, you know, in a former life.
Um, just helping people kind of navigate companies and leadership and communication and politics and all the things.
Is that one-on-one?
Is it one with is it a small group?
How does that work out?
Yeah, it's one-on-one.
Um, just do remote Zoom calls and yeah, just talk about you know the challenges people are having and give some tools and suggestions, suggestions of how to deal with situations that might come up.
Because uh, you know, anybody who became a tech lead, they'll know that basically when you become a tech lead, they say, Hey, congratulations, you're a tech lead, go do tech leading stuff, and uh don't really tell you what that entails.
So that's when I come in and just help people figure out how to work effectively in those roles and you know, manage your manager and um get stuff done.
How likely is it that person is already employed and a tech lead?
And they're just like, hey, can uh now that I get this role, can I use some discretionary spending for some leveling up?
Yeah, that's a hundred percent of the people that I work with are people who are already employed at a company.
Um, a lot of times the company will even pay for the coaching through their professional development expensing.
And uh, you know, sometimes the managers reach out to me and just say, Hey, um, I have this person that I'm working with, um, that I really like to get them some coaching, either because they just don't have more senior people at the company.
Like I work with a lot of startups that just don't have those really senior people that can help mentor people.
Um, or sometimes the really senior people are just too busy, don't actually have the time to sit down and do that sort of coaching and mentoring.
Um, sometimes it's the engineers themselves who reach out, and and I always encourage them to talk to the manager to see if they have professional development funding that might be able to pay for it too, because you know, if the company is going to benefit from you becoming a better employee, then um seems only fair that they should pay for it too.
Well, how can they reach out to you?
What's the best way to say, hey, Nicholas, I uh I need some help.
Yep.
So you can drop by my website.
It's uh human who codes.com slash coaching, and that'll give you all the information about like what I do, how it works, and see some testimonials.
Uh, and there's a button for you to apply and fill out a form that just tells me about you and I can figure out if it would be a good fit.
Because I I'm one of those people who I want to make sure I can help you with the situation that you're dealing with.
And if not, then I'll try to help you find somebody who can.
And how should GitHub contact you to come help fix NPM security?
The same way slash coaching yo.
The the folks at GitHub, um, I'm in a Slack with them already, so they can reach out at any time.
Uh DN near you.
All right, get out of the the tables are turned back to you.
Come on the pod.
Let's talk about NPM.
Or reach out to Nicholas, whichever you prefer.
That's your next move.
There you go.
Let's make it happen.
Nicholas, anything else on your mind?
Anything else you want to talk about?
It could be on topic, off topic regarding what's going on in software world or anything before we let you go.
Yeah, I just uh just wanted to say about AI.
Um I don't think it's hype.
I still see people out there saying, oh, this is just a hype train.
It's not like personally myself, I have seen like a 10x productivity improvement in the amount of code that I can now generate versus writing.
And especially when you're like jumping around from project to project, um saving me a ton of time.
Like there's it would be really difficult for me to be productive writing code for ESLint right now.
But uh with AI, like hey, you know, I know what I need to get done, and I can describe it fairly quickly and just kind of let AI go off and do it.
So if you're one of the stragglers out there who's still not embracing AI uh in your day-to-day, like 2026 is the year.
You gotta start doing it now.
2026 is the year.
There you go.
How about resources for maintainers who have to maintain NPM modules, packages, whatever?
Do you have any resources for them?
Any any advice for them?
Maybe they're not paying attention as much as they should to the details.
Where could they go to become leveled up?
Yeah, that is a good question, but I don't know.
I have an answer to.
I'd love to see that resource exists because I feel like that's just like a natural thing, too.
Because I mean, MPM, I don't even I don't know.
I don't know NPM's docs, but I would imagine like that's the need there, but they're already not doing the other things as well as they could.
So let's just do those things better.
Yeah.
But the docs can be, you know, maintainers out there who've been down the road, have the bloody knuckles and the scars to prove it, and the backward facing desire for everyone else following them or following NPM or the ecosystem to be leveled up in some way, shape, or form.
I'd love to see that happen.
So if you're out there doing something like that, or you got that resource, or that's your next big AI generated things.
I mean, that really could be something you can AI generate over a weekend.
You can invent 100 new docs that were never there with a few prompts and uh your buddy, your new buddy Ralph and Claude just circling around whatever, get it done.
If I'm remembering correctly, I think OpenJS Foundation might have put out something along these lines.
Just not a hundred percent sure.
Very cool.
Well, Nicholas, thank you for coming on the pod sharing your time again with us back here on the changelog.
And thank you so much for your angst and sharing that and uh just pushing the needle on what could be a secure NPM coming to you sometime soon.
Yes.
Thanks for having me.
All right, that's your changelog interview for this week.
Thanks for riding along with us.
What do you think about NPM?
Is it being neglected?
Is there a way to save it?
Are we being overly dramatic?
Let us know in the comments.
Links in the show notes.
Thanks again to our partners at Fly.io to Breakmaster Cylinder for the beats and to you for listening.
We appreciate you more than you know.
That's it.
This one's done.
But on Friday, come on back.
We're talking ClaudeBot slash Moltbot, personal software, and the death of software as a service.
Talk to you then.