The Rust package manager
Rust's Cargo seems to suffer from the same. And the tooling to avoid the wild "grab things from the Internet" route is quite lacking (shameless plug for attention: https://github.com/rust-lang/cargo/issues/10045).
I don't have a problem with making the convenient route possible, but it's very troubling that the tooling actively fights you if you want to take a saner approach.
Instant Terminal Sharing
Some of this is solved with locked dependencies and an understanding of how "npm install" actually works, but I find this point really takes away any credibility for this article:
> This is just one of the reasons why I think by 2023 working with ephemeral cloud-based dev environments will be the standard. Just like CI/CD is today.
Over my dead body will I ever use a cloud environment to write code. tmate might be the closest I ever get.
I get some developers don't care about what they throw aimlessly onto a cloud, but I don't know what's being logged, what's being stored, how long it's being stored, who has access to it, what third-parties have access to it, and so on. The business I own or the one I write code for might care if those files were exposed like that.
Use a local VM. Or a development proxy. The cloud isn't a solution for everything.
OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.
tools for sandboxing your dependency graph
Small plug for LavaMoat (https://github.com/LavaMoat/LavaMoat) which includes tools to more granularly disable dependency lifecycle scripts via @lavamoat/allow-scripts.
Move files and folders to the trash (by sindresorhus)
I believe Apple forked rm to provide protection for this case?
Also, if you're willing to lean into npm a bit, there's tools that give a layer of protection over rm such as https://github.com/sindresorhus/trash-cli
OUTDATED!!!!! - Replaced by "The Bumblebee Project" and "Ironhide"
Bumblebee (related to NVIDIA hybrid graphics offload):
There so many comments on that commit that Microsoft Github's backend apparently cannot load the page -- I just get the "unicorn".
Anyway, this issue also points it out: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...
Alter Ego: run Linux desktop applications under a different local user (by intgr)
I haven't tried it yet, but Ego  feels like an imperfect but good enough solution to run your dev environment.
Public change requests/proposals & ideation (by npm)
Re https://github.com/npm/rfcs/pull/488. Thank you for your service! I had this on my TODO for months. Actually I just use yarn now where ever possible and set `enableScripts: false` both globally and per package. Doesn't solve all of the npm ecosystem's sec issues (like allowing downloading binary blobs and other assets from arbitrary URLs, no cleaning on permission bits on archives, not blacklisting certain typo-esque package names, ...) but it's clear low hanging fruit and the push-back from maintainers is really crazy ...
Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.
📚 Collaborative cheatsheets for console commands
They're really quite different in my experience, but the difference is not one of availability so much as it is Python developers following traditional software engineering best practices. I write almost all my hobby projects in Python. Very rarely do I incur a dependency tree involving more than 5 or 6 projects while doing so.
The rm -rf vulnerability is essentially a problem with a chain only being as strong as its weakest link. If any of the maintainers in the hundreds of node dependencies your project uses is malevolent, you're screwed. Hence, the security of the chain depends much more on the number of links it has rather than its innate strength.
Even large and complex dependencies tend to be well engineered in Python. BeautifulSoup is a widely used library for loosely parsing HTML. It requires only Python and an internal library. lxml is another HTML parser (which BS can optionally use), and it requires only Python and a couple of C libraries. Even an entire web framework (Flask) uses only 4 Python dependencies directly and only one of these (the Jinja template engine) has recursive dependencies on other Python packages. All told it's about 10 Python packages needed in total.
Or consider this, if you want an example of a trivial command line tool. The Python tldr client uses only 3 libraries as recursive dependencies. The Rust client, tealdeer, has 119. The official nodejs client has, if I'm counting correctly, 603.
Disable SSH password logins with System Integrity Protection (SIP) in effect
1 project | reddit.com/r/applehelp | 6 Mar 2021
NPM ci succeeds when package-lock.json doesn't match package.json
1 project | news.ycombinator.com | 18 Jan 2022
NPM ci is currently broken
1 project | news.ycombinator.com | 18 Jan 2022
Run Svelte app on AWS Cloud9
1 project | dev.to | 16 Jan 2022
How to override your dependency's dependencies
1 project | dev.to | 14 Jan 2022