chore: reduce fs-extra usage in scripts/

[SukkaW]

The PR follows #56536 and #56491, replacing fs-extra usages inside the scripts/ folder.

Note that the copy and move haven't been replaced yet. Currently, there is no better recursive copy (lightweight, promise-based, Node.js built-in copyFile API-based, support the filter option) library alternative available on npm, and Node.js built-in fs.rename doesn't support overwrite.

The PR also replaces many async fs API usage with their sync versions.

cc @wbinnssmith

[ijjk]

Tests Passed

[ijjk]

Stats from current PR

Default Build

General

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
buildDuration	10.8s	10.7s	N/A
buildDurationCached	6.3s	6.3s	N/A
nodeModulesSize	174 MB	174 MB	✓
nextStartRea..uration (ms)	516ms	517ms	N/A

Client Bundles (main, webpack)

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
199-HASH.js gzip	27.5 kB	27.5 kB	✓
3f784ff6-HASH.js gzip	53.1 kB	53.1 kB	✓
99.HASH.js gzip	182 B	182 B	✓
framework-HASH.js gzip	45.3 kB	45.3 kB	✓
main-app-HASH.js gzip	254 B	252 B	N/A
main-HASH.js gzip	32.9 kB	32.9 kB	N/A
webpack-HASH.js gzip	1.75 kB	1.75 kB	N/A
Overall change	126 kB	126 kB	✓

Legacy Client Bundles (polyfills)

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
polyfills-HASH.js gzip	31 kB	31 kB	✓
Overall change	31 kB	31 kB	✓

Client Pages

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
_app-HASH.js gzip	206 B	205 B	N/A
_error-HASH.js gzip	182 B	180 B	N/A
amp-HASH.js gzip	506 B	505 B	N/A
css-HASH.js gzip	322 B	323 B	N/A
dynamic-HASH.js gzip	2.57 kB	2.57 kB	N/A
edge-ssr-HASH.js gzip	260 B	259 B	N/A
head-HASH.js gzip	350 B	350 B	✓
hooks-HASH.js gzip	369 B	369 B	✓
image-HASH.js gzip	4.35 kB	4.35 kB	N/A
index-HASH.js gzip	256 B	256 B	✓
link-HASH.js gzip	2.64 kB	2.63 kB	N/A
routerDirect..HASH.js gzip	312 B	311 B	N/A
script-HASH.js gzip	385 B	384 B	N/A
withRouter-HASH.js gzip	307 B	308 B	N/A
1afbb74e6ecf..834.css gzip	106 B	106 B	✓
Overall change	1.08 kB	1.08 kB	✓

Client Build Manifests

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
_buildManifest.js gzip	485 B	482 B	N/A
Overall change	0 B	0 B	✓

Rendered Page Sizes

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
index.html gzip	528 B	530 B	N/A
link.html gzip	541 B	542 B	N/A
withRouter.html gzip	523 B	524 B	N/A
Overall change	0 B	0 B	✓

Edge SSR bundle Size

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
edge-ssr.js gzip	93.6 kB	93.6 kB	N/A
page.js gzip	154 kB	154 kB	N/A
Overall change	0 B	0 B	✓

Middleware size

	vercel/next.js canary	SukkaW/next.js scripts-fs-extra	Change
middleware-b..fest.js gzip	626 B	621 B	N/A
middleware-r..fest.js gzip	150 B	151 B	N/A
middleware.js gzip	22.5 kB	22.5 kB	N/A
edge-runtime..pack.js gzip	1.92 kB	1.92 kB	✓
Overall change	1.92 kB	1.92 kB	✓

Commit: 04dde74

[styfle]

Can we use promises here instead of sync funcs?

[SukkaW]

Even with promises-based fs APIs, the main thread is still blocked by await in the single-threaded script, effectively idling (install-native.mjs is a single-thread script, invoked by pnpm run).

fs async APIs are favored when the main thread should not be blocked, such as a web server managing several incoming requests, or using Promise.all to parallelize tasks sent in the Node.js's libuv worker pool. But we are not doing those in install-native.mjs.

Generally, fs sync APIs are faster (up to 40%) than async APIs (They don't require creating Promise objects, which alleviates GC pressure and avoids extra ticks).