### 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>
<!-- 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.
### 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?
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>
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
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>
- 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
