Their benchmarks[0] report that a clean install with lockfile is about 3x times faster (7s -> 2.2s) and a no-op install is about 29x times faster (517ms -> 18ms)
Had to check the calendar to be sure it wasn’t somehow April 1st. No, it’s August. Huh.
I don’t see how it’s possible that the pnpm maintainers are unaware of the bun AI-rewrite-to-rust saga… so I’m baffled, befuddled, and overall at a loss to make sense of this decision.
To be fair to the pnpm maintainers, they have been working on this well before the bun AI rewrite. The first commit in their rust experiment is in 2021.
Perhaps – but it's a useful grammatical construct in everyday use, handy for structuring sentences.
And with the prevalence of AI, it rubs off on the smelly humans, who also find it useful and use it more as a result. (I used an en dash here instead of an em one – also valid, easier to type, and shorter).
This heuristic is commonly believed — and expressed on this website — but is idiotic. Plenty of people have known how to use em dashes when writing on a computer since the 1980s. (This was true even before UTF-8 was invented to make extended characters work across platforms; instead of ⌘⇧-hyphen, we'd just type "--" to approximate it.)
The reason LLMs tend to use a lot of em dashes is that the human-authored texts they were trained on used a lot of em dashes.
> Plenty of people have known how to use em dashes
Plenty? I don't think it's that many. And knowing how to use them, doesn't mean they would actually use them. In my experience, em dashes are mainly found in academic literature. Chances that an em dash in a new text comes from an LLM are pretty high.
Your use of it is dubious, I think. Commas would serve equally well --or better-- since it's a simple conjunction, not an interjection.
This is untrue and a naive understanding of modern model training.
Opus 5 does not speak like a normal, average, or common English user. For example, it says “stated plainly” or “worth stating plainly” (two very uncommon English phrases) every two or three responses.
In this case, the emdashes are just tip of the iceberg. The writing is so Claude that it’s painful to read (and in fact I stopped reading to save my mental health).
I got to the conclusion that boring is good enough, for me NPM is the best tool, is not that fast, but the installation speed is not that bad, considering how many times I need to run from scratch, the difference does not matter, it is stable and it's the default Node package manager, so I don't need to bother to install in CI any other tool, etc. My experience for long living projects is to stick with the defaults, because in a few years third party tools will change, it happen to my team with Yarn classic, now that we are with vanilla Node and NPM no worries, same with 3rd party dependencies, just use as less as possible.
I’m going to write a filter to remove comments that are just bitching about whether something is AI written or not. Seeing “slop” now starts to give me m$ vibes
Is "pnpm installs the other package managers" what you're talking about, or something else? That doesn't quite read like removing corepack support to me, though I might be missing something obvious.
What’s the problem with that? Seems to make sense to me with the example and it’s important to point out. I’d expect an llm to explain in more detail to be honest.
It doesn’t quite make sense at face value by itself. It’s too condensed and takes some effort to parse out what it’s actually getting at. It’s not communicating why the change was made. It’s just a shiny way of saying the words without actually helping me easily understand what’s happening, what’s changing, why, etc.
In plain English, maybe it’d be more like “Package specifiers for git repositories should no longer include the HTTPS/SSH protocol. Instead, reference the repository name, and pnpm will resolve it through HTTPS. If SSH is still needed, add an override in your global git settings”
yes! and this is sooo weird given that Opus 4.8 or 5 producing this are supposed to be "smart" models – how far into the benchmaxxing do you have to lean to get to this point?
If you spend all day talking to Claude then its mannerisms begin to grate on you like fingernails on a chalkboard.
There's nothing wrong with the English per se, it's grammatically correct, it just sounds so "Claude". Claude talks using pithy word soups that lack the niceties and structure of human writing.
Maybe the author is a non-native English speaker, and this enables him to communicate things he's not able to do himself. Should OSS maintainers start hiring professional translators? Are you going to fund that?
We really should stop jumping to conclusions and shaming people for using these tools just because you don't like the language of the LLM. How is a non native speaker meant to determine what is English slop and what isn't?
I should also note, I am a native speaker. There's absolutely nothing wrong with what's written in the part you chose to paraphrase, and it makes sense to me.
A non-native speaker most likely writes more 'understandable' English than the weird convoluted Claude style.
FWIW though, you can ask an LLM to write in 'Simplified Technical English' (see: https://www.asd-ste100.org/), which at times reads like its written for a child, but it is much better for inclusion of non-native speakers.
This is a recent degradation; they've been writing blog entries for years.
As a non native English speaker I can also attest to this trade being extremely demanding of English fluency:
> public static void DoTheThing(Configuration config)
Isn't something you can not understand and still function as a software engineer. Yes, some schools and universities teach in other languages, but the entire ecosystem from code to documentation to articles is nearly almost always in English.
It doesn't matter. I work with people who aren't native speakers (in a country where English-education is a very high standard) but are mostly fluent in day to day conversation and meetings and they are not comfortable writing long-form texts - and it shows. Your expectations are unrealistic.
Great question. As open-source projects grow internationally, professional translators can help maintain accurate, consistent, and culturally appropriate documentation. This is especially valuable for technical content where small translation errors can create confusion for users and contributors. Services like MarsTranslation can support OSS teams with professional translation and localization when projects need to scale across languages.
visit for more details: https://www.marstranslation.com/
I was also bothered by this. I don't care if you use LLMs to write most or all of your code, but at least have the courtesy of actually writing your blog posts & readmes, to demonstrate that you at least understand what the LLM generated for you.
Hey Claude, write in the worst possible claudism way you possibly can, and make it sound like every other text on the internet that is published nowadays.
"This post covers what pnpm 12 adds that pnpm 11 never shipped."
just why pnpm? you are stable, you are loved by the community. Now you feel the need to throw it away to rewrite for what? Can anybody give me a good explaination
> It is a rewrite of pnpm in Rust
Their benchmarks[0] report that a clean install with lockfile is about 3x times faster (7s -> 2.2s) and a no-op install is about 29x times faster (517ms -> 18ms)
[0]: https://pnpm.io/benchmarks
Had to check the calendar to be sure it wasn’t somehow April 1st. No, it’s August. Huh.
I don’t see how it’s possible that the pnpm maintainers are unaware of the bun AI-rewrite-to-rust saga… so I’m baffled, befuddled, and overall at a loss to make sense of this decision.
To be fair to the pnpm maintainers, they have been working on this well before the bun AI rewrite. The first commit in their rust experiment is in 2021.
https://github.com/pnpm/pn/commits/main/?after=e24c0b293f1f4...
Bun rewrite seems like a big success story.
https://bun.com/blog/bun-v1.4 has some pretty nice numbers indeed.
Whenever you see a lot of long dashes (—) in a writing, there's a high chance Claude has written it.
Perhaps – but it's a useful grammatical construct in everyday use, handy for structuring sentences.
And with the prevalence of AI, it rubs off on the smelly humans, who also find it useful and use it more as a result. (I used an en dash here instead of an em one – also valid, easier to type, and shorter).
This heuristic is commonly believed — and expressed on this website — but is idiotic. Plenty of people have known how to use em dashes when writing on a computer since the 1980s. (This was true even before UTF-8 was invented to make extended characters work across platforms; instead of ⌘⇧-hyphen, we'd just type "--" to approximate it.)
The reason LLMs tend to use a lot of em dashes is that the human-authored texts they were trained on used a lot of em dashes.
> Plenty of people have known how to use em dashes
Plenty? I don't think it's that many. And knowing how to use them, doesn't mean they would actually use them. In my experience, em dashes are mainly found in academic literature. Chances that an em dash in a new text comes from an LLM are pretty high.
Your use of it is dubious, I think. Commas would serve equally well --or better-- since it's a simple conjunction, not an interjection.
This is untrue and a naive understanding of modern model training.
Opus 5 does not speak like a normal, average, or common English user. For example, it says “stated plainly” or “worth stating plainly” (two very uncommon English phrases) every two or three responses.
In this case, the emdashes are just tip of the iceberg. The writing is so Claude that it’s painful to read (and in fact I stopped reading to save my mental health).
I'm curious, as it's not mentioned, are there any performance improvements as part of this rewrite?
I got to the conclusion that boring is good enough, for me NPM is the best tool, is not that fast, but the installation speed is not that bad, considering how many times I need to run from scratch, the difference does not matter, it is stable and it's the default Node package manager, so I don't need to bother to install in CI any other tool, etc. My experience for long living projects is to stick with the defaults, because in a few years third party tools will change, it happen to my team with Yarn classic, now that we are with vanilla Node and NPM no worries, same with 3rd party dependencies, just use as less as possible.
Unless you care about security, stability, DX, speed and correctness then npm is fine choice.
Describing NPM as boring is a stretch. Given its security model, i think spicy is a far more apt label.
I have switched to pnpm already.
I have the same experience - npm was bad, now it is fast enough.
Hooray!
Time to hop off I guess. They don't even bother to write changlog on their own.
Same here, what if the internals get the same absence of care? No thank you.
I’m going to write a filter to remove comments that are just bitching about whether something is AI written or not. Seeing “slop” now starts to give me m$ vibes
Or downvote and then remove.
Am I the only one that hates the decision to no longer support corepack?
pnpm 12 supports corepack (or better phrased - corepack supports pnpm 12).
they just don't recommend it.
nodejs stopped bundling corepack since node 25, maybe you're referring to that?
Is "pnpm installs the other package managers" what you're talking about, or something else? That doesn't quite read like removing corepack support to me, though I might be missing something obvious.
Same here. Corepack was fine and there is already too much churn
First I'm hearing of it, and it does dampen my enthusiasm for v12 a bit.
The more I read these ass Claude Opus writings the more I believe AGI is further away from us.
I thought 'how bad can it be?', yet only three paragraphs in "a specifier now names a repository rather than choosing a transport"
If you're going to serve us slop then at least serve us good slop, give it a pass through GPT 5.6 to clean up the English.
I remember the most interesting things to do with 3.5 Turbo was to ask it to rewrite paragraphs in different styles.
Why can modern LLMs basically not do that anymore? They each have their own very particular writing style?
It it all just beaten out of them in post training?
What’s the problem with that? Seems to make sense to me with the example and it’s important to point out. I’d expect an llm to explain in more detail to be honest.
It doesn’t quite make sense at face value by itself. It’s too condensed and takes some effort to parse out what it’s actually getting at. It’s not communicating why the change was made. It’s just a shiny way of saying the words without actually helping me easily understand what’s happening, what’s changing, why, etc.
In plain English, maybe it’d be more like “Package specifiers for git repositories should no longer include the HTTPS/SSH protocol. Instead, reference the repository name, and pnpm will resolve it through HTTPS. If SSH is still needed, add an override in your global git settings”
yes! and this is sooo weird given that Opus 4.8 or 5 producing this are supposed to be "smart" models – how far into the benchmaxxing do you have to lean to get to this point?
If you spend all day talking to Claude then its mannerisms begin to grate on you like fingernails on a chalkboard.
There's nothing wrong with the English per se, it's grammatically correct, it just sounds so "Claude". Claude talks using pithy word soups that lack the niceties and structure of human writing.
Maybe the author is a non-native English speaker, and this enables him to communicate things he's not able to do himself. Should OSS maintainers start hiring professional translators? Are you going to fund that?
We really should stop jumping to conclusions and shaming people for using these tools just because you don't like the language of the LLM. How is a non native speaker meant to determine what is English slop and what isn't?
I should also note, I am a native speaker. There's absolutely nothing wrong with what's written in the part you chose to paraphrase, and it makes sense to me.
A non-native speaker most likely writes more 'understandable' English than the weird convoluted Claude style.
FWIW though, you can ask an LLM to write in 'Simplified Technical English' (see: https://www.asd-ste100.org/), which at times reads like its written for a child, but it is much better for inclusion of non-native speakers.
This is a recent degradation; they've been writing blog entries for years.
As a non native English speaker I can also attest to this trade being extremely demanding of English fluency:
> public static void DoTheThing(Configuration config)
Isn't something you can not understand and still function as a software engineer. Yes, some schools and universities teach in other languages, but the entire ecosystem from code to documentation to articles is nearly almost always in English.
It doesn't matter. I work with people who aren't native speakers (in a country where English-education is a very high standard) but are mostly fluent in day to day conversation and meetings and they are not comfortable writing long-form texts - and it shows. Your expectations are unrealistic.
> Your expectations are unrealistic.
No they are not.
Claude isn’t the only option for such a person, as translation tools exist, and English-speaking colleagues exist to proof-read.
In any case, the article author writes perfectly well in English pre LLM era: https://www.kochan.io/nodejs/it-is-ok-to-keep-random-things-...
> Should OSS maintainers start hiring professional translators?
The world existed before 2022.
Great question. As open-source projects grow internationally, professional translators can help maintain accurate, consistent, and culturally appropriate documentation. This is especially valuable for technical content where small translation errors can create confusion for users and contributors. Services like MarsTranslation can support OSS teams with professional translation and localization when projects need to scale across languages. visit for more details: https://www.marstranslation.com/
Ditto. I've started to wonder if the real problem with many of these complaints about LLM writing is actually reading comprehension.
Good to see the maintainers don't care enough to take the time to write a release blogpost themselves. sigh
I was also bothered by this. I don't care if you use LLMs to write most or all of your code, but at least have the courtesy of actually writing your blog posts & readmes, to demonstrate that you at least understand what the LLM generated for you.
Hey Claude, write in the worst possible claudism way you possibly can, and make it sound like every other text on the internet that is published nowadays.
"This post covers what pnpm 12 adds that pnpm 11 never shipped."
just why pnpm? you are stable, you are loved by the community. Now you feel the need to throw it away to rewrite for what? Can anybody give me a good explaination
Check the benchmarks, hopefully even more JS slop is converted to Rust for the sake of humanity.