PR https://github.com/vercel/next.js/pull/79596 introduced setting
`stable` dist tag for backports, but due to
https://github.com/vercel/next.js/pull/79538#pullrequestreview-2866854431,
> This sounds like something users would use. However, it might point to
14.x when 15.x exists and we would certainly want people to use 14.x.
It's also weird that 14.x would have a `stable` tag but not 15.x.
>
> That's why `backport` makes more sense since it's less specific and
not common vernacular when talking about release characteristics (e.g.
"experimental", "nightly", "stable", "unstable" etc.).
>
> The tag could actually just be "internal-backport" and ideally we'd
remove it right after publish. The goal here isn't to come up with a
useful tag for backports. We just want to work around NPM requiring a
tag during publish.
better to use another dist tag: i.e.,`backport`.
### Why?
If the current version is less than the latest, it means this is a
backport release. Since NPM sets the `latest` tag by default during
publishing, when users install `next@latest`, they might get the
backported version instead of the actual "latest" version. Therefore, we
explicitly set the tag as `stable` for backports.
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
We publish multiple packages in parallel which can cause issues with the
prepublish only script running as turbo clearing/restoring dist caches
can causing files to be missing if a publish is in progress. We also
don't need to run these as all packages are already built prior to
publishing. This also includes fixes for release stats.
JJ Kasper