Before we all conclude that supply chain attacks only happen on NPM, last time I used VS Code I discovered that it auto-installed, with no apparent opt-out, Python typing stubs for any package (e.g., Django in my case) from whatever third-party, unofficial PyPI accounts it saw fit. (Yes, this is why it was the last time I used VS Code.)

The obscurity of languages other than JavaScript will only work as a security measure for so long.

It's already solved by pnpm, which refuses to execute any postinstall scripts except those you whitelist manually. In most projects I don't enable any and everything works fine, in the worst case I had to enable two scripts (out of two dozen or so) that download prebuilt native components, although even those aren't really necessary and it could have been solved through other means (proven by typescript-go, swc, and other projects led by competent maintainers).

None of it will help you when you're executing the binaries you built, regardless of which language they were written in.

I am now using the type remover in Node to run TupeScript natively. It’s great and so fast. Even still I continue to include the TypeScript compiler in my projects so that I can run TSC with the no compile option just for the type auditing.

You are lying to yourself. In this attack, nothing was executed by npm; it "just" replaced some global functions. A Go package can't do that, but you can definitely execute malware at runtime anyway. It can also expose new imports that will be imported by mistake when using an IDE.

Fucking this.

I have seen so many takes lamenting how this kind of supply chain attack is such a difficult problem to fix.

No it really isn't. It's an ecosystem and cultural problem that npm encourages huge dependency trees that make it impractical to review dependency updates so developers just don't.

Honestly, the same is true in a lot of other areas of computing.

Whenever you download an open-source program and you don't have to compile it first, you're at risk of running code that is not necessarily what's in the publicly-available source code.

This can even apply to source code itself when distributed through two different channels, as we saw in the xz backdoor attempt. (The release tarball contained different code to the repository.)

I checked has-ansi. What's the reason that this library would exist and be popular? Most of the work is done by the library it imports, ansi-regex and then it just return ansi-regex.test(string), yet it has 5% of the weekly downloads of ansi-regex. ansi-regex also has fewer than 10 lines of code.

I don't know anything about the npm ecosystem, what's the benefit of importing these libraries compared to including these code in the project?

All docs are local too, like we used to do with man pages and paper reference books or do you use another system for them? A second computer, a tablet, a phone?