This is building off of the work already completed in #5430.

All this is doing is installing spawk correctly so that all of the hard work that @winterqt has done can be shipped.

Doesn't initializing spawk in the test like that cause child_process.spawn to not be overridden in pack, since it's imported before overriding it?

Nope, child_process is a singleton, it's the exact same object wherever it's included. So as long as things aren't de-referencing the spawn function itself off child_process, it will get the mocked version whenever it runs child_process.spawn.

Oh, well I see what you mean here https://github.com/npm/promise-spawn/blob/main/lib/index.js#L1

The prepack.called is being asserted in the tests so it is working ... Lemme see if I can be sure as to why.

Oh I mixed tspawk and tnock up when reading the code. There's no mystery here. const tspawk = require('./fixtures/tspawk.js') happens right off the bat. It loads itself in sync as it is required. Everything after that that asks for child_process.spawn gets spawk. The only "quirk" here would be if somehow the code were to be called again after tap ran teardown, it would still be spawk that it was getting, not the real child_process.spawn.

TLDR when using spawk make sure it's required before anything else that will require child_process.spawn

Ah, right, you loaded it before everything else but only initialized it further in the tests.

Was the change from npm.prefix to testDir in makeSpawnArgs the change that fixed the rmdir failure on Windows? Or was it just a race condition or something? Seems weird.

The rmdir error was because of npm being used at all. The workspace tests don't instantiate npm, they test the library themselves. When npm was being initialized in tests, but nothing about it was awaited, there were logs happening asynchronously that were being written to after the test had finished, and the windows cleanup methods threw an exception in that case.