### 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>
### What?
disable optimistic_updates
So it no longer does that:
> If Kodiak is merging an out-of-date pull request that has running
status checks, update the pull request's branch without waiting for the
running status checks to finish.
The problem with that is that it cancels running checks and restarts
them.
Instead it waits for all running status checks before updating the PR.
### Why?
This should avoid the case where a PR is updated again and again without
yielding a result.
It also saves some CI cost
And it allows CI to finish and fill up the turborepo cache, which can
potentially used for the next run.
<!-- 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
### How?
Closes NEXT-
Fixes #
-->
### What?
This PR changes to the `root` of the cargo workspace to the root of repo
itself, allows next-swc and other rust codebase can use repo root as
workspace root.
### Why?
Currently cargo manifest for the next-swc is not placed under the root
of the repo, which makes invocation to the tool requires to change cwd /
or set cwd. Similarly needs to open editor to the root of the cargo
manifest separately to able to utilize language server kicks in. Moving
manifest to the root consolidates those, so can invoke either cli / or
editor to the same root of the repo.
We decided in https://github.com/vercel/next.js/pull/48308 that we won't
use `turbo` when packing packages for tests.
This PR removes all code associated with that effort. The whole thing
fas behind a flag, so it shouldn't affect anything.
fix NEXT-1025
### What?
* move some shared runtime logic to turbopack
* use relative imports from internal code when possible
* move react-refresh logic to turbopack
* move benchmark code logic to turobpack
see https://github.com/vercel/turbo/pull/4553
### Why?
We want to have benchmarking again for turbopack PRs
We want to have a standalone turbopack cli (eventually)
We want to avoid duplicating the runtime code
### How?
refactoring, moving code
### What?
enables the benchmark tests from turbopack again
### Why?
It tests common scenarios like HMR
fixes WEB-792
---------
Co-authored-by: Alex Kirszenberg <alex.kirszenberg@vercel.com>
### What?
Syncing https://github.com/vercel/next.js/labels with the bug report template.
### Why?
We've got some OS-related reports so it would be nice to be able to filter on that.
### How?
The label description is added as a select option to the template, which then matches one of the labels https://github.com/vercel/next.js/labels
<!-- 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 #
-->
- closes WEB-766.
This PR enables a new job for running tests, against turbopack. Since we
have observed some flakiness across turbopack test execution, it starts
from absolute minimum set of tests to not block any CI due to unexpected
failure.
Ran manual workflow roughly ~50 times and looks like these set of tests
are fine to make it as blocking check for the PR. In the future, depends
on the stability we'll increase number of test gradually.
### What?
Turbopack tests need to run on any change
### Why?
Next.js changes might break turbopack and we want to avoid that.
### How?
Change CI job
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This re-enables running the CNA tests for all non-docs changes as it's now ensuring we don't regress on turbopack or our default templates.
Also fixes the main repo's package.json files from being modified during tests.
This ensures we only honor cache entries from the in memory cache for up
to 2 seconds so that revalidates can correctly propagate and also
increases max fetch cache entry size to 2 MB. The `fetchCache` export is
also being detected in this PR but not yet honored which will be done in
a follow-up.
As discussed this adds a publish workflow that can be triggered for
canary or stable releases which ensures we are publishing from a
consistent environment and local config doesn't affect a release.
This ensures the build spinner is correctly stopped in a TTY environment
and also adds regression tests for `app` and `pages` to ensure this
behaves as expected.
This updates our docker image to use the `jammy` tag instead of `focal`
to match the Ubuntu version to our CI.
- Move span wrapping rendering closer to the user code and don't add
span when we have cache-hit
- Add `getStaticProps` span
- Add spans around API handlers (pages and app)
- Add `generateMetadata` span
- Clarify naming that we use `page` for entrypoints like
`/path/[param]/page` or `/path/[param]/layout`. And `route` for
`/path/[param]`
fix NEXT-857 ([link](https://linear.app/vercel/issue/NEXT-857))
### What?
A fork of https://github.com/github/issue-labeler that we pull in and
maintain.
### Why?
The official issue labeler had some issues which I tried to fix in PRs
and eventually got merged upstream, but the release cycle was a bit
slow, and that GitHub action had many parts we did not really need
anyway. So it makes sense to maintain it ourselves.
### How?
This PR removes the
https://github.com/vercel/next.js/blob/canary/.github/issue-labeler.yml
config file, which in our case is just a sublist of
https://github.com/vercel/next.js/labels anyway. Instead, we can pull in
the labels from GitHub directly and filter out those that we want to
apply to issues. This will keep things more in sync.
fix NEXT-750 ([link](https://linear.app/vercel/issue/NEXT-750))
---------
### What?
update prettier in the PR stats action
### Why?
It's outdated and can't parse syntax of the latest swc version (static
blocks)
### How?
update package.json
### What?
enables the next-dev-tests crate integration tests from trubopack
### Why?
to unblock the move PR we temporarily disabled the tests
### How?
Fix the new location and fix the expect dependency
Fixes WEB-708
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
Hi everyone! Thank you for your work on this awesome framework 🙌
This short PR will add a short description on how to install the `canary` version of `next` to the `bug issue template`. It's only affecting this issue template and nothing else.
Closes#47080
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Update workspace cargo deps
Update cargo deps to point to local workspace
Ignore too-many-arguments warnings
Fix clippy errors
Update pnpm workspaces
exclude integration tests from unit tests CI
rust-analyzer settings
add rust flags and env vars
## What?
This PR has its main goal to improve the experience of opening/reviewing
a PR.
It improves the PR template, as well as extends PR auto-labeling.
## Why?
There are 2 parts to the PR template:
- Individual contributors: The current template accommodates for the
most common cases individual contributors use to contribute. (I.e.
fixing bugs, updating/adding examples, addressing documentation issues).
The new template keeps this at the top.
- Next.js team: As maintainers, we should try to explain PRs as if
someone with less context would review them. This should also help with
backreferencing PRs in issues and follow-up PRs and make it easier to
follow changes, understand trade-offs better at the time, and help new
team members catch up over time, etc.
## How?
The template is written in a comment instead of Markdown, so when the PR
is opened, most of the template is hidden to make it less verbose.
The checkboxes we've had before are not shown, but we already auto-label
PRs based on the path of the files that have been touched, so the
checkboxes showed redundant information.
[Slack
thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1677677802109289),
Closes NEXT-741
## What?
- Rendering `next info` output as code in the bug template
- Removed the "Feature Request" issue template, in favor of a more
granular discussion template
- Added a minimal template for Help discussions
## Why?
The main part of this PR is the new Feature Request template.
Anyone can propose a change to Next.js. However adding new features
often requires community discussions - whether to align expectations,
understand the consequences (eg.: backward compatibility/lifetime of a
feature), to look at and understand historical reasons for the current
behavior or lack of the feature -, which [GitHub
discussions](https://github.com/vercel/next.js/discussions) is more
suited for than issues.
## How?
- Utilizing the new discussion templates
https://docs.github.com/en/discussions/managing-discussions-for-your-community/creating-discussion-category-forms
- Adding a link to the [new
issue](https://github.com/vercel/next.js/issues/new/choose) view to make
it easier to discover
[Slack
thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1670874727319809)
Closes NEXT-742
---------
We want to make sure that our examples are not breaking.
We don't want to be slowed down by broken 3rd party packages, but we
need to ensure that examples covering next.js features are always green.
Added as a standalone workflow that doesn't parallelize. It will just
run on a cron schedule, so we can check for current status. We can add
Slack ping later if we need to.
The workflow tests just that our examples can build, so mostly TS
issues. We could definitely follow up with actual tests, but that is not
as low-hanging.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
<!--
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:
-->
This PR updates the Edge Runtime docs on the next.js docs site with
simplified tables for each API section
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This updates our CI testing flow to only run against LTS Node.js version
on PRs and then run against the maintenance Node.js version when cutting
a release. This will allow speeding up PR test runs to get feedback
faster and remove un-necessary duplicate testing as it's very rare a
change breaks the maintenance Node.js version but not the LTS version.
This PR ensures the tests for codemods will automatically run in CI when the source code changes.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Not all systems have `/bin/bash` (for example NixOS).
`/usr/bin/env bash` reads the location of bash from `PATH`
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
- reverted to github version because that works now
<!--
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
- [x] Depends on https://github.com/vercel/next.js/pull/45776
Turbotrace occupies too many memories while running; this PR makes it
run after the webpack build is finished, it can reduce the memory
hogging by webpack and turbotrace, thus avoiding OOM
The `maxFiles` option in turbotrace is removed because there is
`memoryLimit` option takes over its role.
Close WEB-556
Noticed while testing across CI environments that the `test-pack` handling is not-concurrent or cache safe so this removes it from being used by default and moves it behind a flag to allow further investigating later.
In CI if `test-pack` is called at the same time due to multiple concurrency it can cause the resulted archive to be corrupted so may require a form of lock to resolve in CI although locally re-using the same archive name/path isn't safe with pnpm as it won't bust the store cache and continue to leverage previous cache.
Creates a new workflow and action that auto labels with `linear` whenever we apply `kind: bug`.
It's using JS action instead of docker, so it should be quite fast.
I tested this on my fork and it works.
Also created the action with TS so we can use it as a starting point for next actions so they can all be typed.
This reverts commit fd9ec646ac.
It seems that there is an issue with caching of inputs which uses stale
files.
We also had to disable caching of `pnpm-lock.yaml` because it requires
stable package locations chich we removed.
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
## Bug
Test(Production) CI fails with error
```
Package libicu66 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'ttf-unifont' has no installation candidate
E: Package 'ttf-ubuntu-font-family' has no installation candidate
E: Unable to locate package libenchant1c2a
E: Package 'libicu66' has no installation candidate
E: Unable to locate package libvpx6
E: Unable to locate package libwebp6
Failed to install browser dependencies
```
This is due to new release for the runner image (https://github.com/actions/runner-images/issues/6399) now sets ubuntu 22.04 as latest, but playwright have release to support it (https://github.com/microsoft/playwright/issues/13738) but @replayio/playwright seems not picked it up yet (https://github.com/replayio/replay-cli/blob/main/packages/playwright/package.json#L23)
PR tries to pin to known working image (20.04) until dependencies can support new image gracefully.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Updates our test config to take advantage of more concurrency and also
updates to leverage the playwright docker image to reduce flakes from
actions/setup-node stalling or playwright dependencies stalling on `apt
install`.
This reduces our test times from upwards of 30 minutes down to back
around 15 minutes.
This is a follow-up to leveraging the turbo remote cache and this now
eagerly updates the cache on merge to canary when swc files changed so
that it doesn't have to wait for a publish to update.
Continuation of https://github.com/vercel/next.js/pull/42711 fixing
latest turbo usage in musl environment
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Ensures we have latest patches in turbo CLI.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Issues being reported without a reproduction take longer to
triage/resolve. To make the process faster, we should encourage people
always to add one.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
x-ref:
https://github.com/vercel/next.js/actions/runs/3382765061/jobs/5618315815
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Running "pnpm lint" on a documentation change won't work unless "pnpm
build" has previously been run, e.g. on a fresh checkout of a fork after
clicking the published docs "edit this on GitHub" button.
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [x] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Steven <steven@ceriously.com>
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: Steven <steven@ceriously.com>
Next.js 13 will require React 18.
In this PR I've only updated the peerDependency and removed the test runs in GH actions. Further cleanup will follow later, this allows us to remove the code supporting it later.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
@ijjk WIP here.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!--
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 that you're making:
-->
This PR utilizes cargo's new feature from latest release (1.64.0),
inheriting dependency from a workspace.
In short, top-level workspace cargo manifest can specify a version of
dependency to use, then actual packages uses it without re-declaring
version per each via workspace = true. This will help to dedupe
different versions of packages, also potentially avoid conflicts if
forgot to bump up specific versions.
In this pr only touches swc_core, which is a base dependency we use in
several place. One another benefit for this is bump up PR can be lot
more simplified, only need to update single Cargo.toml when we bump up.
Note rust-toolchain has updated to use nightly version after 1.64.0 to
enable this.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
<!--
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 that you're making:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
@ijjk moving this here.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
For app edge SSR, we don't need any internal pages for it since it's
handled by app-renderer. This results around reducing 20KB from app edge
SSR
# Changes
* Strip those internal pages modules when it's in app edge SSR
* Minimize edge SSR chunk to see the tree-shake result
* Add bundle analyzer with switcher in stats-app for testing. Using
`TEST_ANAYLYSE=1` to build stats-app for testing
Continues #39778Closes#40499
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
The issue validator GitHub action has been running in the background for a while, and the output looks good: https://github.com/vercel/next.js/actions/workflows/validate_issue.yml
This PR switches off debug mode and will start commenting on improper bug reports to make triaging more effective.
This PR implements the logic to make next-app-loader able to match multiple routes.
The app loader is refactored to construct the tree recursively instead of within a loop, as there could be multiple branches. Similarly, when entering a new layout level or branch, we resolve both the slot name (defaults to `"children"`) and the segment.
In order to make that work, the loader has to know all matched app paths. This is passed in as the `appPaths` loader option, which is gathered when creating the entrypoint.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Currently we use one dev swc build for running release/PR stats although the latest swc build could be incompatible with previous tags/commits being compared against so this updates to use the specific version related to that tag. This also updates to omit the swc size from `node_modules` size since it's a dev build and not helpful to track.
Fixes: https://github.com/vercel/next.js/runs/8189857273?check_suite_focus=true
I did some experimenting to see if we can grab the latest version from npm instead of GitHub releases since that's the version the user can actually use.
The npm registry sends the package metadata in a gigantic (~8mb for `next`) JSON response and parsing it with `res.json()` takes several seconds, but using `ReadableStream`, we only care about the first chunk. This way we can grab the relevant version information in a few ms. ~I added `undici` which implements `res.body.getReader()`.~ Using Node 18/native `fetch`.
- Group edge ssr tests, merge `edge-vs.-non-edge-api-route-priority` and `react-18-streaming-ssr` into 1 e2e test suite
- Add rewrite case to edge ssr in switchable runtime
This adds handling for prefetching `onTouchStart` as this gives a little more time to start parsing required scripts for a page transition if not already done that can help make the transition faster. This is based on research showing the touch start event firing on average `90ms` before click (x-ref: [source](https://instant.page/#:~:text=in%20the%20world.-,On%20mobile,-A%20user%20starts))
This also adds testing safari with playwright so we can run these in PRs instead of only after merge and adds initial mobile testing as well.
x-ref: [slack thread](https://vercel.slack.com/archives/C7PDM7X2M/p1658250170774989?thread_ts=1658249275.178349&cid=C7PDM7X2M)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Updates to latest turbo which includes patches for cached files.
x-ref: [slack thread](https://vercel.slack.com/archives/C02CDC2ALJH/p1657767763630359?thread_ts=1657757803.039099&cid=C02CDC2ALJH)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
- Do not comment/label if `next info` wasn't used, as we might not be able to detect the versions reliably.
- Ignore all issues that do not have the `template: bug` label or weren't labeled manually. (This might slip through a few issues that did not follow our template like [Reference in new issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue#creating-an-issue-from-a-comment) but that's minimal overhead already)
- Added note when the reproduction URL is unreachable to invite me to the private repository.
- Turned on DEBUG mode (no comments/labels, only logs) for now, so we can verify the behavior and find issues.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This is second attempt to https://github.com/vercel/next.js/pull/38076 . Most of changes are identical to previous PR. Main difference is introducing features `native-tls` and `rustls` for the sentry's downstream feature. Few platform targets we build (mostly where we cross compiles) fails to find native openssl for the specified target. For those, we falls back to rustls instead. The only exception is aarch64_windows, neither openssl nor rustls can be compiled straightforwardly, For those platform we bail out and do not init sentry at all. There are nearly 0 users on aarch64_windows anyway. We could try to located target's openssl binary, but the effort required seems not worth enough.
Also PR changed `server_name` property to not to include real device hostname to avoid possible PII concerns.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
https://github.com/vercel/next.js/runs/7130177863?check_suite_focus=true
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
See: https://github.com/vercel/next.js/runs/7024234103?check_suite_focus=true#step:2:1
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
When triaging bug reports, we would like to make sure that our main focus is on unresolved issues. Next.js is a highly active project, and we cut new releases fairly often, under the `next@canary` tag. Some of the issues being reported might have already been fixed there, so we would like to encourage people to check them out. Once a fix is in `canary`, it will be included in the next `latest` release automatically.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
* test: upgrade playwright-chromium from 1.14.1 to 1.22.2
This is a prereq for #36490 because the Events Timing API
used to measure Interaction to Next Paint (INP, experiemental web vital)
is only available in Chromium >= v98.
* update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
