https://github.com/vercel/next.js/pull/98330 revealed theat
`@next/third-parties` never worked with prereleases after 16.0. Now we
[update `peerDependencies` similar to what we do for preview builds
already](https://github.com/vercel/next.js/blob/27f679224e2660971377f855ced51093462734d8/scripts/create-preview-tarballs.js#L130-L132)
(we should unify both eventually to go through the same flow).
Fixes
```
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: undefined@undefined
npm error Found: next@16.4.0-canary.22
npm error node_modules/next
npm error next@"16.4.0-canary.22" from the root project
npm error
npm error Could not resolve dependency:
npm error peer next@"^13.0.0 || ^14.0.0 || ^15.0.0 || ^16.0.0-beta.0" from @next/third-parties@16.4.0-canary.22
npm error node_modules/@next/third-parties
npm error @next/third-parties@"16.4.0-canary.22" from the root project
```
-- https://github.com/vercel/next.js/actions/runs/34291905918/attempts/2
https://github.com/vercel/next.js/pull/94622 tried to be more strict
with when a release is considered healthy. However, `@next/swc-wasm-web`
is not enrolled in Trusted Publishing and blocks the release train.
This PR restores the behavior for `@next/swc-wasm-*` packages prior to
https://github.com/vercel/next.js/pull/94622 i.e. we continue the
release train even if any `@next/swc-wasm-*` fails. Other NAPI bindings
will continue to block the release train if they fail to publish.
The bail vs no-bail behavior is controlled with a repository variable so
that we can mor easily test if `@next/swc-wasm-web` is enrolled in
Trusted Publishing.
Moves all release workflows off of a GH PAT and uses an app with a
short-lived token instead.
Test Plan:
Dry run
[here](https://github.com/vercel/next.js/actions/runs/24934593874).
However, this workflow is blocked until we figure out commit signing for
the bot app. Some options:
- The bot account generates a signing key and we use it in CI (not
great, bypasses the app)
- The org bypasses signature verification for the bot user (also not
great, requires an exemption rule)
- We need to rework the commit step so Lerna does not do the push, and
instead trigger it via the app + GH API. This seems like the best
option, will be added in a follow-up PR.
Note: `create-release-branch` workflow is broken in its current form, as
we will not be restoring administrator privileges to adjust environment
settings. This will become a manual step in the future.
Switches from a long-lived token to trusted publishing OIDC flow. This requires a bump to Node (for feature support). Otherwise just dropping unnecessary envs.
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.
Sebastian "Sebbie" Silbermann