Fix atomic createWriteStream

[mischnic]

Closes #7813

I think this is also the cause of at least some CI flakiness (for tests that use the NodeFS as the output FS).

Problem

(copied from the linked issue)

The problem is that when writing the bundles

parcel/packages/core/core/src/requests/WriteBundleRequest.js

Lines 253 to 256 in 80c728c

	await new Promise((resolve, reject) =>
	pipeline(
	res.stream,
	outputFS.createWriteStream(

this rename here

parcel/packages/utils/fs-write-stream-atomic/index.js

Line 103 in 80c728c

fs.rename(

isn't awaited but happens sometime afterwards asynchronously. (The whole handleClose callback is called late, it's not just the missing fs.rename callback)
But it doesn't happen at all if Parcel stops the process forcefully:

parcel/packages/core/parcel/src/cli.js

Line 259 in 80c728c

process.exit(exitCode);

Probable cause

Node 13.14.0 is working correctly, the next version 14.0.0 has this behaviour. Something regarding the timing of the close event on the createWriteStream() stream has changed.

Potentially nodejs/node@e13a37e49d

Solution

So with my limited understanding of Node streams, I don't know if implementing an atomic write stream is even possible (anymore). So the easy (but brute force) solution is to let the callee do call the move at the right time (which worked out for all usages we have). E.g.

It looks like the problem was that fs-write-stream-atomic added a wrapper Writeable "proxy" over the actual fs write stream. Overriding the fs.close used by Node's createWriteStream to additionally move the files afterwards works

[parcel-benchmark]

Benchmark Results

Kitchen Sink ✅

Timings

Description	Time	Difference
Cold	1.37s	+1.37s ⚠️
Cached	310.00ms	+311.00ms ⚠️

Cold Bundles

No bundles found, this is probably a failed build...

Cached Bundles

No bundles found, this is probably a failed build...

React HackerNews ✅

Timings

Description	Time	Difference
Cold	8.54s	-67.00ms
Cached	416.00ms	+19.00ms

Cold Bundles

No bundle changes detected.

Cached Bundles

No bundle changes detected.

AtlasKit Editor ✅

Timings

Description	Time	Difference
Cold	1.40m	-899.00ms
Cached	2.24s	-35.00ms

Cold Bundles

Bundle	Size	Difference	Time	Difference
dist/16.069344b7.js	905.00b	+0.00b	30.95s	-3.60s 🚀
dist/simpleHasher.46d6f2e5.js	742.00b	+0.00b	34.29s	-28.64s 🚀
dist/index.html	240.00b	+0.00b	27.27s	-2.83s 🚀

Cached Bundles

Bundle	Size	Difference	Time	Difference
dist/esm.c7dc1640.js	61.96kb	+0.00b	1.05m	+28.36s ⚠️
dist/workerHasher.e50d242f.js	1.72kb	+0.00b	1.05m	+28.36s ⚠️
dist/16.1969624f.js	1.08kb	+0.00b	34.29s	+2.94s ⚠️
dist/16.069344b7.js	905.00b	+0.00b	34.29s	+2.94s ⚠️
dist/simpleHasher.46d6f2e5.js	742.00b	+0.00b	1.05m	+28.36s ⚠️
dist/index.html	240.00b	+0.00b	1.05m	+35.55s ⚠️

Three.js ✅

Timings

Description	Time	Difference
Cold	6.15s	-88.00ms
Cached	256.00ms	-2.00ms

Cold Bundles

No bundle changes detected.

Cached Bundles

No bundle changes detected.

Click here to view a detailed benchmark overview.

[101arrowz]

To avoid introducing a move function, why not intercept the 'finish' event (maybe via EventEmitter internals) and do what is currently in move before re-emitting 'finish'?

[mischnic]

This intercepting of the finish event was exactly what the previous broken implementation did.

I've now instead overridden the fs.close function used by fs.createWriteStream to move the file after closing the fd (and doing async operations is fine in this callback). So no await move() anymore.