### What?
This PR adds an hourly workflow that will update the test manifest used when testing with Turbopack.
### Why?
To ensure we don't regress any test suites.
### How?
I use the existing `scripts/update-fonts-data-workflow.js` workflow script which will execute a script, then create a PR with the current working tree. If any pending automated PRs exist, they will be closed when a new one is opened.
This PR removes the wasm target for the next-swc build for the next major version. The main motivation is that Turbopack does not support targeting wasm yet, and it would be a significant amount of work to add. We plan to make Turbopack the default zero-config experience in a minor version, possibly before we are able to support a wasm target, so we need to make this breaking change now. We also plan to make more improvements to the webpack experience with shared Rust code, which we have so far been blocked from implementing because of the current wasm restrictions. We would like to support a wasm target again in the future, but cannot say at this time when that would be.
Closes WEB-1865
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
Added a condition to skip the update-fonts workflow for forked
repositories.
### Why?
To optimize CI resources and prevent extra runs on forks.
### How?
By checking the repository name and comparing it with the main
repository before executing the workflow.
This PR adds the optional `limit` parameter on String.prototype.split uses.
> If provided, splits the string at each occurrence of the specified separator, but stops when limit entries have been placed in the array. Any leftover text is not included in the array at all.
[MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split#syntax)
While the performance gain may not be significant for small texts, it can be huge for large ones.
I made a benchmark on the following repository : https://github.com/Yovach/benchmark-nodejs
On my machine, I get the following results:
`node index.js`
> normal 1: 570.092ms
> normal 50: 2.284s
> normal 100: 3.543s
`node index-optimized.js`
> optmized 1: 644.301ms
> optmized 50: 929.39ms
> optmized 100: 1.020s
The "benchmarks" numbers are :
- "lorem-1" file contains 1 paragraph of "lorem ipsum"
- "lorem-50" file contains 50 paragraphes of "lorem ipsum"
- "lorem-100" file contains 100 paragraphes of "lorem ipsum"
### What?
BREAKING CHANGE: Bump the minimum required Node.js version.
### Why?
Node.js 16 has reached end-of-life in September.
Bumped to `18.18.2` since it contained some security-related patches: https://nodejs.org/en/blog/vulnerability/october-2023-security-releases
### How?
Bumped `engines` where needed, upgraded the workflows.
This will allow us to remove quite a few polyfills, I'll open separate PRs for those.
As discussed with @feedthejim this breaks our E2E deploy tests workflow into it's own so it can be triggered on cron/manually easier.
One thing we'll need to consider with the cron/manual workflow is if a canary isn't published yet and Next.js relies on swc changes it will fail since this doesn't pack/publish a fresh built swc binary currently.
This replaces the `(global as any)._nextDevHandlers` invocation with references to a specific service instance while also removing the module scoped `devInstances`. This ensures that correct types are used.
This was done while changing the `match` parameter in `ensurePage` to `definition` which didn't cause a typescript error (it should have).
### What?
Updates `run-test.js` to allow running individual test cases inside a test file.
### Why?
So that we can dramatically increase Turbopack's test coverage. Turbopack has implemented most (but not all) necessary features from the webpack bundles. But a single failing test case would prevent us from running any case inside a test file. With case filtering, we're able to run the cases we know will pass and prevent regressions on those.
### How?
Case filtering is only exposed via the `NEXT_EXTERNAL_TESTS_FILTERS` ENV, which points to a JSON file containing a map of test files with the test cases inside those files that are known to pass.
The known-passing test cases can be updated after Turbopack's daily integration test run by running `test/build-turbopack-tests-manifest.js`, which will update the `test/turbopack-tests-manifest.json` manifest.
Closes WEB-1640
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
### What?
This introduces a weighting measurement when determining comments as unhelpful.
### Why?
Too many "same issue" comments in general, but it's hard to do an exact match with only regex.
### How?
Exact code can be found here:
b3363e7948/index.js (L203-L213)
In short, by default if a comment is less than 30% different from unhelpful words, the whole comment will be considered unhelpful.
[Slack thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1695287105298299)
### What?
Closes WEB-1615
I thought I couldn't grab the correct count of test suite in the datadog
as I was seeing huge count mismatches. Actually, it was because we were
not running all of the tests.
PR amends
- run all the tests under manifests
- ensure all the test list in the manifest actually exists
lastly and sadly
- disable few tests too flaky
This runs unit tests separate from the `test-dev` task to make it a bit more obvious these are running, and allow for an easy way to add any unit-test specific behavior in the future
[slack x-ref](https://vercel.slack.com/archives/C04DUD7EB1B/p1695150908857269)
### What?
Moving maintenance to a separate repository.
### Why?
I want to make these actions reusable in other projects as they seem to work well in the Next.js repository.
### How?
The code is moved to https://github.com/balazsorban44/nissuer
I tested it on my fork, and all the following functionality is preserved: https://github.com/balazsorban44/next.js/issues/56
- [x] Close/lock/comment without a valid reproduction link
- [x] Minimize "+1"
- [x] Add labels based on user selection
- [x] Add comment based on the maintainer's label (eg.: "please add a complete reproduction")
### What?
update pnpm in trigger-release
### Why?
It generates a slightly different lockfile than developer's tooling
does, causing unnecessary changes to the precompiled files
Closes WEB-1579
### What?
Webpack wrapped the external import in a new module, making `require.cache` invalidation impossible.
This also adds a basic fallback manifest for turbopack.
Closes WEB-1522
### What?
Switch the default for `--turbo` to the new `--experimental-turbo`, remove the old code in next.js
### Why?
The new approach will be used in future
Closes WEB-1506
### What?
Follow-up of #54824
### Why?
Correctly detect the section to look for while autolabeling. The text currently being searched is not present in the issue body, just the template. Example: #54911 where "App Router" is present but was not detected.
This fixes our caching for the docker builds as they were missing inputs
the other jobs had also enables caching the rust target cache which
improves build times when only changing our package and the lockfile
isn't invalidated.
Tested here https://github.com/vercel/next.js/actions/runs/5987764387
This ensures env variables are passed through as expected when building
the next-swc binaries, also removes an extra GH actions that isn't
really needed as it's just a wrapper around `docker run`.
Validated changes against run here
https://github.com/vercel/next.js/actions/runs/5851719808/job/15862899331
### What?
Follow-up of #53453
### Why?
Forgot to update the link in a few places
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
* fixes problems in Next.rs API introduced by #52846
* adds test infrastructure for experimental turbo testing
* adds two test cases to verify the infrastructure
* add grouping of output logs in run-tests
* simplify template loading
### Why?
### How?
This relocates the regex patterns that were being used for `test-dev`, `test-prod`, and `test-integration` actions to be part of `run-tests`. Also fixes e2e tests since they were expected to be found in `e2e` rather than `test/e2e`, and updated it exit with a failure code in case of no tests being found
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Colocated unit tests (such as ones in `packages/next` and `packages/font`) weren't running in CI since `run-tests` marks the glob cwd as `<root>/tests`. This modifies the working directory to be the root so the new expanded test pattern will pick up files outside of `test/`.
Several of these tests were failing so there are updates in here to fix them. Specifically:
- Source Sans Pro font was renamed to Source Sans 3
- `fillCacheWithDataProperty` test was hitting the `bailOptimistic` code path
- `resolve-metadata` had an invalid assertion (`rel: icon` gets added as part of `IconsMetadata`)
- `resolve-opengraph` wasn't handling undefined images
- `server-patch-reducer` now use inline snapshots as one was failing since it now has a prefetchCache
This creates a monorepo for each github action and ensures they all use pnpm.
You can install and build all with the following:
```
cd .github
pnpm i
pnpm -r build
```
As we're using nodejs with latest version of 18.x on CI, there's a new behavior change of `url.fileURLToPath` that didn't join the paths as expected
locally with node 16.x or 18.16
```
/private/var/folders/mh/y8kwzkls6v3_w3_k6q384cw80000gn/T/next-install-b033b516612809c6fb0a0de77c6e50f7d7f8af34dfd3d01812b99345352dc992/node_modules/.pnpm/file+..+next-repo-7e52b07043e986127273a2d951e5c412b0dd45fb24eb34001bd372e2afff79db+packages+n_vyqu6i4c4i3efp5pqsaeaoe5s4/node_modules/next/dist/compiled/@vercel/og/noto-sans-v27-latin-regular.ttf
```
in the actions runner with node 18.17 it's
```
/tmp/next-install-8efaa47c1546bed07990d8f130decceb6536e1a36146e7885cb68e3c3dea21f7/node_modules/.pnpm/file+..+next-repo-9679355e05341947e7aa0b42c994e3ac_krcuriy4thl7zawouf7sswlrgy/node_modules/next/dist/compiled/@vercel/og/index.node.js/../noto-sans-v27-latin-regular.ttf
```
You can see that `index.node.js` is still present in the path as a folder which is unexpected
```
index.node.js/../
```
x-ref: https://github.com/vercel/next.js/actions/runs/5600417148/jobs/10242827739?pr=52790
### What?
Scale up concurrency on integration tests to be ~10min each
### Why?
This should bring down the total runtime of the CI
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Steven <steven@ceriously.com>
### What?
Adding a new label comment for "please simplify reproduction".
### Why?
During triaging, a lot of time is gone into trying to isolate the actual bug being reported. Reproductions sometimes contain unrelated code - that sometimes can be the actual cause of an issue, reported as a bug in Next.js, or require third-party services, secrets, setting up databases, and other tasks that take up much of the resources before the issue can even be verified.
### How?
Similar to the `please add a complete reproduction` and `please verify canary` labels, if a maintainer adds the `please simplify reproduction` label, an automatic comment will appear on the issue, asking for a minimal reproduction
[Slack thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1685527818400339)
### What?
Closes WEB-1157. PR enables turbopack to support native webp encode / decode. There is one platform we can't support this (aarch64-linux-gnu) which disables those.
`yarn pack` does not pack the same way that `npm pack` does. There is at least one bug with how files are treated where node_modules are ignored even inside folders defined by the files config. While this is not currently used in next.js an upcoming change will rely on it. The reason this change makes sense otherwise is we use npm to publish next and during a publish the pack from npm is used. For consistency we should use the same pack for our actions and other code that does repo setup such as `create-next-install` which is used for tests
The implementation is slightly more complicated than just replacing the pack command however. `npm pack` respects gitignore files whereas `yarn pack` does not (or at least not nested ones). For some packages the `"files"` property in package.json is set which overrides any gitignore rules however the `@next/swc` package uses a gitignore to prevent the committing of native binaries but does not use files and thus npm pack does not includes native binaries when yarn pack does. To address this the PR adds a temporary rename of the `next-swc/native/.gitignore` file which allows npm pack to mimic the yarn pack behavior. The reason I did not just add `"files"` is that this package actually publishes to many different package names on npm for each architecture and I was unsure about making changes to the package.json that would potentially affect this codepath.
In addition to those changes there are 2 `.gitignore` files that appear to be outdated and unnecessary. I removed them.
### What?
Add all passing tests
### Why?
We enforced that they all run turbopack and these are passing.
If any of these tests would become red, that indicated a problem.
- Add some basic error handling to the link validator action.
- Avoid unnecessarily creating a new bot comment when the validation is successful.
- Only scan .mdx files modified in the current PR for broken links.
### What?
this forces all tests to use turbopack independent of the way they invoke next dev
### Why?
some tests were not running turbopack
fixes WEB-1187
This PR migrates and adapts the [validate docs links script from `next-site`](https://github.com/vercel/front/pull/23185). This script is triggered by a GitHub action whenever a file in the `/docs` folder is updated. If broken links are found in the docs, the check fails and we post a comment on the PR with a list of broken links.
Co-authored-by: Michael Novotny <446260+manovotny@users.noreply.github.com>
Reverts vercel/next.js#51406
This pnpm bump seems to be causing lockfile issues with the react
versions which causes context issues since we need to share the same
react version in the monorepo.
This contains the original POC for `next build --turbo`. The implementation is _just enough_ to get pages building, and doesn't support the app router yet.
I'll write more details here on the implementation and what the next steps are next week.
Necessary changes on the Turbo side: https://github.com/vercel/turbo/pull/4998
### What?
Fixespnpm/pnpm#6424
### Why?
So users of Node 20 can contribute to Next.js
### How?
Upgrades pnpm with back compatibility to patch `ERR_INVALID_THIS` error.
If Node 14 support isn't necessary, I'd recommend upgrading to pnpm 8
for continued feature support and committing the lockfile.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Tweak code owners after some testing and feedback.
- Move the Next.js team up to be optional global code owners (so that everyone can review but are not tagged for review). Global individuals should still be tagged if there are no specific `.vercel.approvers` files in subdirectories.
- Adds @vercel/devex to image files so there's coverage on those files for the docs
- Target specific folder and files for Styfle to get notified
- Deletes some rules in the old GitHub codeowners
### What?
WEB-1150.
This PR is an attempt to upload next.js's test results into datadog test trace to track its status.
Originally it tried to use automatic trace injection (dd-trace/ci/init). However, due to some of custom environments / setup we use it was not compatible out of the box. Instead, this PR injects a new test reportert to generate junit report, then upload it at once at the end of the testing pipeline.
The reporter is configured to run when necessary variables set, local run should not be affected.
One thing to note is this report will not count retry results, as it'll create duplicated test entry with multiple results since we runts jest per individual test. This'll allow to detect flaky test easier, but also it means we'll get bit of skewed test results compare to the real world as first failure will be accounted as test fail immediately.
### What?
* enable turbopack tests in new CI
* split pre-build step into native and JS builds to allow to start
native tests faster
* update swc_core to sync with turbo
* update turbopack
### Why?
Running our test suite is still important as long we don't have the full
integration test suite enabled.
### Turbopack updates
* https://github.com/vercel/turbo/pull/5215 <!-- OJ Kwon - ci(workflow):
upload benchmark results to datadog -->
* https://github.com/vercel/turbo/pull/5239 <!-- OJ Kwon -
fix(swc_plugin): use shared runtime -->
* https://github.com/vercel/turbo/pull/3090 <!-- CHEN Yuan - Docs: prior
to run testcases, add guides to install dependencies for testcases. -->
* https://github.com/vercel/turbo/pull/5264 <!-- Tobias Koppers - update
test runner -->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
context: https://github.com/vercel/next.js/actions/runs/5231928600/jobs/9446394605#step:16:33
For some reason, installing datadog cli on some action runner (Windows) is unexpectedly slow: while other platform takes ~30s, windows only takes more than > 7m.
PR updates workflow logic to consolidate artifacts, and then send metrics at once on a separate ubuntu workflow.
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.
Currently this is uploading every time the job is run even if it's a
cache hit and this step can take over 3 minutes un-necessarily so this
skips it if a cache hit occurred.
### What?
Another attempt to https://github.com/vercel/next.js/pull/50619 and WEB-1150, trying to apply setup guard more throughly.
I still do not know why original PR passed CI but fails to subsequent PRs after merge, but hope this could be a right guard to prevent unexpected failures.
Move as much of codeowners as possible to use Vercel Spaces.
1. Makes `@timneutkens @ijjk @shuding @huozhi @feedthejim` global owners
2. Make the `@vercel/next-js` team _optional_ owners of **/docs**,
**/errors**, and **/contributing**, makes team owners of a few packages
as per old config.
3. Make `@vercel/devex` (docs and devrel) owners of **/docs**,
**/errors**, and **/contributing**
4. Make `@vercel/devrel` (devrel only) owners of **/examples**
5. Make `@vercel/web-tooling` owners of specific files and folders (as
per old config)
Leaves @styfle as owner of **image** files on the old config since this
pattern `/**/*image*/** ` can't be used with Vercel Spaces.
Note: We cannot add * or / at the end of files.
[Docs](https://spaces-docs.vercel.sh/docs/code-owners#:~:text=Code%20Owners%20files%20are%20meant%20to%20encourage%20distributed%20ownership%20definitions%20across%20a%20codebase.)
Update our git workflow in preparation for open-sourcing the content of
the docs ([linear
task](https://linear.app/vercel/issue/DX-1579/set-up-github-workflow)).
**Templates:**
- [x] Update docs issue template to encourage contributions
- [x] Update PR template to include link to new contribution guide
**Code Owners / Reviewers:**
- https://github.com/vercel/next.js/pull/50841
**Labels:**
- [x] Add DevEx team to labeler.json so PRs get the "created by: DevEx
team"
**Other:**
- [x] Remove docs manifest from CI checks as we no longer have one (keep
the manifest for errors as they live under `/pages`)
- [x] Add `unifiedjs.vscode-mdx` to the vscode extension list
### Description
Set some environment variables that reduce size on disk and make the
build a little faster.
Also, read the toolchain from the `rust-toolchain` file, so it's not
duplicated in every workflow.
Ported over from the `turbo` repo.
Updates to re-use our build workflow so turbo remote cache is leveraged
and updates re-usable workflow reference to be the same branch instead
of main.
This adds uploading the turbo run summaries for our publish builds so we
can debug cache misses there easier the same as the new build_reusable
workflow.
### What?
This PR updates existing CI worfklow for building Turbopack (`@next/swc`), and report its bytesize per target triple as additional metrics. It will be included in datadog's pipeline execution traces.
It would be better to track this per-PR, or per-commits but building all native binaries per each commit is too expensive. For now, tracking it when we deploy and actually build new release binaries.
### What?
This PR attempts to enable datadog trace integrations to the next.js integration tests if env is configured. With this, datadog can observe each test suite's results and detect some meaningful information (i.e flaky) for us.
However, I wasn't able to verify this works with next.js repo since for some reason CI worker does not pick up the api key in the env (https://vercel.slack.com/archives/C04KC8A53T7/p1685597124894539). Still this won't affect existing workflow, and once enabled I can test it over vercel/turbo repo instead.
Partially resolved WEB-1150.
### What?
This PR allows to trigger subset of build-and-deploy workflow manually via gh actions UI.
### Why?
Turbopack time to time requires to validate its changes against all of the platforms we build. Adding manual workflow allows to test it easier.
It tries to guard release check `isRelease` only if it comes from normal event (non manual dispatch) to avoid accidental publish workflow.
Ensures we continue pre-building binaries on merge to canary and ensures
we are testing against the maintenance Node.js version also adds turbo
summarize for all swc builds.
This breaks up some of our longest running tests which allows more
parallelizing of the tests. This also moves turbopack tests filtering
back to an allow list as it is running a lot of unrelated tests
currently which isn't ideal. We should only be running against tests
that are explicitly testing turbopack e.g. build tests should not be
duplicated in the turbopack group.
```sh
test/integration/css/test/group-1.test.js: 762.655
test/integration/edge-runtime-module-errors/test/index.test.js: 695.309
test/integration/css/test/group-2.test.js: 671.848
test/integration/i18n-support/test/index.test.js: 518.173
test/integration/scss-modules/test/index.test.js: 451.704
test/integration/css-features/test/index.test.js: 417.318
test/integration/css-modules/test/index.test.js: 403.405
test/integration/eslint/test/index.test.js: 381.563
test/integration/500-page/test/index.test.js: 371.134
test/integration/telemetry/test/index.test.js: 367.691
test/development/acceptance-app/ReactRefreshLogBox.test.ts: 335.878
test/integration/create-next-app/templates.test.ts: 334.01
test/integration/scss/test/group-2.test.js: 327.255
test/integration/scss/test/group-1.test.js: 318.574
test/integration/edge-runtime-configurable-guards/test/index.test.js: 313.834
test/e2e/instrumentation-hook/instrumentation-hook.test.ts: 294.618
test/development/acceptance-app/error-recovery.test.ts: 283.355
test/e2e/app-dir/app/vercel-speed-insights.test.ts: 278.242
test/integration/create-next-app/index.test.ts: 272.442
```
This adds new `build and test` and `build and deploy` workflows in favor
of the existing massive `build, test, and deploy` workflow. Since the
new workflows will use `pull_request_target` this waits to remove the
existing workflow until the new one is tested.
While testing this new workflow flakey behavior in tests have also been
addressed. Along with the new workflow we will also be leveraging new
runners which allow us to run tests against the production binary of
`next-swc` so this avoids slight differences in tests we've seen due to
running against the dev binary.
Furthermore we will have a new flow for allowing workflow runs on PRs
from external forks which will either require a comment be checking a
box approving the run after each change or a label added by the team.
The new flow also no longer relies on `actions/cache` or similar which
have proven to be pretty unreliable.
Tests runs with the new workflow can be seen here
https://github.com/vercel/next.js/actions/runs/5100673508/jobs/9169416949
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation or adding/fixing Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
WEB-1086.
This PR flips the way running next.js integration test with Turbopack,
instead of using allowlist to run selectively enabled test now uses
denylists. The immediate effect is now any new test being added (as a
new file) will be executed with Turbopack by default, and should be
manually excluded if it fails.
Still, the number of tests we run remains same.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation or adding/fixing Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
This PR adjusts manifests for the next.js test with Turbopack, as I
found upstream test keep changing and need to sync its latests state
into the manifest.
Manifest is now .js file contains 2 arrays, one for the enabled, and
others for the disabled. Disabled doesn't mean it's always failing
though.
### What?
Disable `tracing/release_max_level_info` for non-published release
builds. I modified CI script to strip out logging for published
binaries.
### Why?
x-ref: https://vercel.slack.com/archives/C03EWR7LGEN/p1683621374204959
It's required to print logging for turbopack.
### How?
Closes WEB-1032
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
