The git merge driver does not expect debugging messages to output on
stdout, and instead requires them to output on stderr. This changes the
`console.log` to a `console.error` to account for this requirement.
- Follow the naming conventions of other environment variables and prefix `TEST_WASM` with `NEXT_TEST_WASM` so that there's less chance of conflicts with user code
- Remove the logic in `setup-wasm.mjs` that modifies the repository (not great for running tests locally) and instead try to match the environment-variable-override behavior used for native (non-wasm) bindings via `NEXT_TEST_WASM_DIR`.
- Hard-fail if `NEXT_TEST_WASM` is set and we fail to load wasm bindings instead of silently using fallback logic that loads native bindings instead.
- We don't need to install `wasm-pack` with `curl | sh` for tests: `pnpm` already installs it (and pins a specific version).
- The whole dance of renaming the directory from `pkg` to `pkg-nextjs` is a hack we use when publishing the package, as we're building both "web" and "nextjs" targets. We don't need to do that for tests.
- Fix handling of `undefined` values in SWC options objects.
- Remove hacks for Next v12.2
Adds a merge driver that can automatically re-number messages added to
`errors.json` if a merge conflict occurs. Now, it would be easier to
just run `pnpm update-error-codes`, but that's slow and requires
installing deps + building everything, so i'm just manually merging +
renumbering instead.
To avoid disrupting people's workflows (in case this is buggy, or
something), it's currently *not enabled by default*. To enable the merge
driver, run:
```shell
scripts/merge-errors-json/install
```
which will add it to your `.git/config`. Once it's been confirmed to
work well, we can make this command run by default in `postinstall`.
### Testing
Other than the test i added (which doesn't run git), i've tested this
manually with this script that rebases some stacked branches:
<details>
<summary>merge-driver-test.sh</summary>
```bash
#!/usr/bin/env bash
set -eu -o pipefail
cd "$1"
current_branch="$(git branch --show-current)"
(
set -eu -o pipefail
git switch lubieowoce/errors-json-merge-driver
git switch --force-create 'test/errors-json/base'
echo '{
"1": "base message"
}
' > packages/next/errors.json
git commit -am 'base commit'
git switch --force-create 'test/errors-json/one';
echo '{
"1": "base message",
"2": "message from branch one"
}
' > packages/next/errors.json
git commit -am 'commit 1'
git switch 'test/errors-json/base'
git switch --force-create 'test/errors-json/stacked-1'
echo '{
"1": "base message",
"2": "message from stacked 1"
}
' > packages/next/errors.json
git commit -am 'stacked 1'
git switch --force-create 'test/errors-json/stacked-2'
echo '{
"1": "base message",
"2": "message from stacked 1",
"3": "message from stacked 2"
}
' > packages/next/errors.json
git commit -am 'stacked 2'
git rebase 'test/errors-json/one' --update-refs || true
bat packages/next/errors.json
git rebase --abort || true
)
git switch "$current_branch"
```
</details>
The script does a bunch of git operations, so it's easiest to put it
outside of your next.js repo and call `bash merge-driver-test.sh
path/to/next.js`.
When the "Version Packages" PR is merged, the created commit is the
format of "Version Packages (#number)". Therefore, the
check-is-release.js script won't match the current regex. Also, I
modified the workflows that use the `check-is-release.js` to consider
the new release as a release workflow as well.
### Why?
When backport releases are published, they are marked as `latest` dist
tag, which makes `next@latest` not the "latest."
x-ref: [slack
thread](https://vercel.slack.com/archives/C04LGE5SYEB/p1747984846615469)
### How?
Use `stable` dist tag for backports.
### Why?
The `process.env.RELEASE_TYPE` handling was set incorrectly. It
should've been set to the "trigger" workflow, but instead, it was set to
the "publish" workflow. Therefore, the "publish" workflow needs to know
which dist tag to set for publish.
---------
Co-authored-by: Sebastian Sebbie Silbermann <[email protected]>
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.
This PR adds a step to send Slack notifications of the status of the
release.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
Best to be reviewed with "Hide whitespace".
This PR added release candidate handling and used a switch case to
ensure the correct release type was given.
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
Co-authored-by: Zack Tanner <[email protected]>
### Why?
When there are no changesets for `next`, the canary release won't be
published even if there are new commits. If this is the case, add an
empty changeset for `next` to let the canary release proceed.
Note that this will result in an empty Changelog and GitHub Release, but
this PR does not cover handling that part.
### Testing Plan
Set env `RELEASE_TYPE=canary` and run `ci:version` locally to see the
result.
---------
Co-authored-by: JJ Kasper <[email protected]>
Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
This PR uses `changesets/action` to handle the canary release. Since the
action creates a Version Packages PR by default, I added a GH Action
that checks if the PR is released from the correct release workflow. It
triple-verifies via the user login (`vercel-release-bot`), PR title
(`Version Packages (canary)`), and a label (`created-by: CI`) to ensure
the opened PR is not trying to spoof.
After the validation, the PR bypasses required checks, is merged into
the canary branch, and proceeds with the rest of the release process.
### Testing Plan
Try running `ci:version` and `ci:publish` locally, and handle the
release type via env `RELEASE_TYPE`.
Confirmed the CI force merge on
https://github.com/devjiwonchoi/lab-releases/pull/13
---------
Co-authored-by: Sebastian "Sebbie" Silbermann <[email protected]>
These crates could be updated to the 2024 edition of Rust with ~no code
changes~ only formatting changes through `cargo fmt`.
Future PRs will address crates individually with code changes.
This updates our workflow for testing new tests against deploy mode to
allow running against forks as we don't want to introduce flakey tests
in this mode even if opened from forks.
As of #77894, there's a new way to indicate Turbopack should run, which breaks flaky tests detection with Turbopack. This swaps out the flag to unblock my downstack PR.
This section will be for developers who want to understand how things
work. It's not essential knowledge, but good to know.
A place for conceptual information and colorful diagrams that explain
the magic behind things ✨🌈
## Convert unpack-next.cjs to TypeScript
### What?
Converted `scripts/unpack-next.cjs` to TypeScript, renaming it to
`scripts/unpack-next.ts` and updating the imports and type definitions.
### Why?
This change continues the ongoing TypeScript migration efforts in the
codebase, providing better type safety and developer experience.
### How?
- Renamed file from `.cjs` to `.ts`
- Converted CommonJS `require()` statements to ES module `import`
statements
- Added type annotation for the `path` parameter in the `realPathIfAny`
function
Fixes #
Yargs automatically creates `--no-` variations of options. Using
`--no-js-build` as an option directly confuses it.
`--no-js-build` remains a valid cli argument.
Test Plan: Verify `pnpm pack-next` builds JS by default and `pnpm
pack-next --no-js-build` doesn’t.
Help now looks like this:
```
pack-next.ts
Options:
--help Show help [boolean]
--version Show version number [boolean]
--js-build Build JavaScript code (default). Use `--no-js-build` to skip
building JavaScript [boolean] [default: true]
-p, --project [string]
--tar Create tarballs instead of direct reflinks [boolean]
--compress How compress the binary, useful on platforms where tarballs
can exceed 2 GiB, which causes ERR_FS_FILE_TOO_LARGE with
pnpm. Defaults to "strip" on Linux, otherwise defaults to
"none". Requires `--tar` to be set.
[string] [choices: "none", "strip"]
```
Written with @bgw.
- Transitions to using `tsx` for script execution
- Replaces `patch-package` with TypeScript implementation
- Implements argument parsing and help message with `yargs`
- Uses `execa` for some command execution
Test Plan: Run `pnpm pack-next`, `pnpm swc-build-wasm`, `pnpm unpack-next`, and `pnpm sweep` without errors.
Previously, we marked the server startup whenever a local url was shown
in stdio. Next.js shows this url as soon as it can to make it actionable
sooner, before the server is truly ready.
This changes makes the event record the time until the “Ready in Nms”
message is shown instead.
Test Plan: `./node_modules/.bin/devlow-bench ./scripts/devlow-bench.mjs`
and validate server startup is recorded.
On Linux we must either compress or strip debuginfo, otherwise the debug tarball will be >2GiB, and pnpm (it's actually a node/libuv bug) has issues with files larger than 2GiB.
As far as I can tell Rust can generate line numbers for backtraces with zlib-compressed debuginfo, but not with newer zstd-compressed debuginfo.
## Summary
Follow up #73548 and #73633.
#73548 changed the `with-next-sass` to `with-sass` directory.
However, some tests still use old `with-next-sass` name.
This PR updates them.
Co-authored-by: Sam Ko <[email protected]>
