That's a good point. I guess if I were doing the equivalent in TypeScript (which I would never do, because I'd rather write Bash for that... but this is a sepa

That's a good point. I guess if I were doing the equivalent in TypeScript (which I would never do, because I'd rather write Bash for that... but this is a separate mental issue of mine), I would `npm install -g` to install packages globally. That's roughly equivalent to using the system python environment. And actually this specific use case you mention is one that doesn't have a great story with node. Currently the best solution IMO is to use Zx [0] which you could reasonably install globally, and which pre-packages some common scripting dependencies. I think the major difference between Python and JS "environments" is that with Python virtualenvs, the `python` binary itself is (usually?) part of the environment. But with JS, you generally have one `node` installed on your system, and then multiple "environments" aka projects each with their own yarn.lock and package.json. Of course you can have multiple `node` versions using something like `nvm`, but it's definitely less coupled to the per-project environments than `python` is to whatever virtualenv dependencies you have. [0] https://github.com/google/zx https://github.com/google/zx