Fortunately there is an option (--ignore-scripts) that prevents all code from running at install time, and there are solutions if specific scripts do need to be run. Such examples are so rare, though, that there is an active proposal to make this option the default.
If you don't trust the scripts, you don't trust the code. Although this limits one attack vector, the issue is just kicked down the road to `import`/`require` time.
It does reduce the attack surface a little, though. For example, if you install a package A which depends on B for some obscure feature, and B gets compromised, but you never use A in a way that imports/requires the code in B, then you can potentially dodge that landmine.
Similarly, if you are downloading npm packages that provide frontend-only code, that is only run in the context of the browser's sandbox, then you don't have to worry about arbitrary code execution (although a malicious frontend package could still exfiltrate user passwords, among other things).
Yeah it's definitely an improvement, but there needs to be something more.
The way dependencies move depending on when you run a yarn/npm install has never been useful. Both for projects initialising a lock, and projects upgrading from a previous locked position.
https://github.com/npm/rfcs/pull/488