Bumping `@edge-runtime/*` <picture data-single-emoji=":edge-runtime:" title=":edge-runtime:"><img class="emoji" width="20" height="auto" src="https://emoji.slack-edge.com/T0CAQ00TU/edge-runtime/b940e917443aa49f.png" alt=":edge-runtime:" align="absmiddle"></picture> packages to their latest beta, as we had some huge improvements and big changes on how it works internally.
* Using the latest `undici` which provides a WebSocket implementation
* Less polyfill usage as we load modules in the Node.js realm, and can reuse modules from Node.js as time goes on <picture data-single-emoji=":just-right2:" title=":just-right2:"><img class="emoji" width="20" height="auto" src="https://emoji.slack-edge.com/T0CAQ00TU/just-right2/588cf34d02f4b3bd.png" alt=":just-right2:" align="absmiddle"></picture>
* `instanceof` checks now work within the realm <picture data-single-emoji=":mind_blown:" title=":mind_blown:"><img class="emoji" width="20" height="auto" src="https://emoji.slack-edge.com/T0CAQ00TU/mind_blown/0186b6f181040126.gif" alt=":mind_blown:" align="absmiddle"></picture>
This PR fixes a couple of categories of CSS issues in App Router, that
come from the same root cause.
### 1. Duplicated styles being loaded in different layers
This issue has been described in
https://github.com/vanilla-extract-css/vanilla-extract/issues/1088#issuecomment-1563931144.
If a CSS module (or a global CSS) is referenced in multiple layers (e.g.
a layout and a page), it will be bundled into multiple CSS assets
because each layer is considered as a separate entry.
<img width="1141" alt="CleanShot-2023-05-26-GoB9Rhcs@2x"
src="https://github.com/vercel/next.js/assets/3676859/8e0f5346-ee64-4553-950a-7fb44f769efc">
As explained in that issue, we have to bundle all CSS modules into one
chunk to avoid a big number of requests.
### 2. CSS ordering issues (conflicts)
This is likely causing https://github.com/vercel/next.js/issues/48120.
When the layer-based bundling and ordering logic applies to CSS, it can
potentially cause non-deterministic order. In this example, button A in
the layout should be in blue. However when button B is imported by the
page, button A becomes red. This is an inconsistent experience and can
be hard to debug and fix.
<img width="1090" alt="CleanShot-2023-05-26-Ar4MN5rP@2x"
src="https://github.com/vercel/next.js/assets/3676859/4328d5d7-23af-4c42-bedf-30f8f062d96a">
### What?
This test case was never passing and accidentally enabled for Turbopack.
We could disable the whole test suite, but since only one test case is
affected we can also disable only that one.
## What?
Currently we use the initial compile to add entrypoints that we know are
going to be used in the application. For example the Next.js runtime,
`react`, `react-dom`, and such. While this was the right default when
Next.js only had `pages`, it's no longer true when both `pages` and
`app` exist. E.g. when you're working on a page using App Router we'd
still compile `pages/_app`, `pages/_document`, and `pages/_error` even
though those would not be used. In case of larger applications (e.g.
Vercel's application) this would mean thousands of extra modules being
compiled even though you don't need them for the page you're looking at.
Similarly we'd compile the Next.js runtime for App Router even when
you're only using `pages`.
This PR changes the handling to only compile the entries that are needed
for the current set of visited pages (on-demand-entries). If that set
only includes `app` entrypoints then the `pages` related files will be
excluded. If the set contains both `app` and `pages` both will be
included. Similarly for `amp`, if you don't use `amp: true` / `amp:
hybrid` the development runtime will not be compiled.
📔 Note: This is specifically for webpack, Turbopack already compiles
everything needed lazily so it didn't have this limitation.
#### Before
```
- event compiled client and server successfully in 1079 ms (306 modules)
- event compiled client and server successfully in 155 ms (306 modules)
```
With opening `/`:
```
- event compiled client and server successfully in 1118 ms (306 modules)
- event compiled client and server successfully in 157 ms (306 modules)
- event compiled client and server successfully in 599 ms (486 modules)
```
Total: 1.874ms (Note: This number is much higher when `pages/_app`
imports many modules).
#### After
```
- event compiled client and server successfully in 118 ms (20 modules)
- event compiled client and server successfully in 65 ms (20 modules)
```
📔 Note: opening the page then causes the Next.js / React runtime to be
compiled ofcourse
```
- event compiled client and server successfully in 115 ms (20 modules)
- event compiled client and server successfully in 57 ms (20 modules)
- event compiled client and server successfully in 1137 ms (361 modules)
```
Total: 1.309ms (Note: This number is not affected by`pages/_app`
importing many modules).
## How?
We can only apply this optimization after we've looped over the list of
on-demand entries, as that has the required metadata. Hence why I went
with deleting the keys for each respective type of entrypoint (`pages`,
`app`, `amp`).
<!-- 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 #
-->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
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
```
## Problem
Relative hash/query handling in `next/link` (e.g. `<Link
href="#hello">`) is broken in App Router, especially if you're on a
nested route.
This wasn't a problem in `/pages` because the href always get fully
resolved in `<NextLink>`; i.e. if you have `<Link href="#hash" />` on
`/hello`, it'll resolve the href to `/hello#hash` and use that
everywhere.
However, in App Router, `<Link>` no longer uses the current location to
resolve the href:
5451564f36/packages/next/src/client/link.tsx (L450-L457)
Therefore navigating with `new URL(href, location.origin)` will skip the
current path and always apply the relative hash/query to the _root_
route:
5451564f36/packages/next/src/client/components/app-router.tsx (L208-L215)
## Solution
Not 100% sure if this is the best solution, but since `app-router` is
already reading `window.location`, I'm using `location.href` as the base
URL to resolve the href.
I grep'd for `location.origin` and checked other callsites; seems like
only `app-router` deals with user specified hrefs.
Fixes https://github.com/vercel/next.js/issues/42157 &
https://github.com/vercel/next.js/issues/44139, and potentially
https://github.com/vercel/next.js/issues/48554 and
https://github.com/vercel/next.js/issues/22838
## Test Plan
```
pnpm testheadless test/e2e/app-dir/navigation
```
---------
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
### What?
create internal modules via `context.process` with
`ReferenceType::Internal`
### Why?
We need this for future refactoring where we want to the internal
modules with transitions.
### Turbopack Changes
* https://github.com/vercel/turbo/pull/5095 <!-- Tobias Koppers - allow
to create internal modules via AssetContext -->
* https://github.com/vercel/turbo/pull/5104 <!-- Alex Kirszenberg -
Stable chunk list ident -->
* https://github.com/vercel/turbo/pull/5106 <!-- Tobias Koppers -
followup fix -->
---------
Co-authored-by: Alex Kirszenberg <alex.kirszenberg@vercel.com>
To prevent confusion with`IncomingHttpHeaders`, this renames the functions used to convert back and forth between `OutgoingHttpHeaders` and `Headers`:
- Rename `fromNodeHeaders` to `fromNodeOutgoingHttpHeaders`
- Rename `toNodeHeaders` to `toNodeOutgoingHttpHeaders`
This exports the named exports from the user's page route file and
exports a new `routeModule` stub. This stub will be the new rendering
mechanism used for pages within `pages/` and will serve to allow us to
deprecate large chunks of the server code to instead live within the
pages entrypoints.
TLDR;
- Route Modules now accept a `definition` so that they have their full
route definition
- Exports are now hoisted from the userland module by name to prevent
name collisions
- A new `PagesRouteModule` stub was added that will in the future
contain all the pages rendering logic
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
## Why?
```
src/app/layout.tsx
```
**eslint[@next/next/no-before-interactive-script-outside-document](https://nextjs.org/docs/messages/no-before-interactive-script-outside-document)**
> `next/script`'s `beforeInteractive` strategy should not be used outside of `pages/_document.js`.
## How?
- Possibility of pathname starts with "/" on OS X and Linux, so added condition to check file path starting with "/"
- e.g. "/src/app" or "/app"
- Added test code
Passed
- `pnpm build && pnpm lint`
- `pnpm jest test/unit/eslint-plugin-next/no-before-interactive-script-outside-document.test.ts`
Extends #46609Fixes#50096
Fixes NEXT-1230
This PR is extracted from https://github.com/vercel/next.js/pull/49942
and mostly contains changes necessary after the Turbopack PR adding the
Node.js production runtime https://github.com/vercel/turbo/pull/4998,
without any of the actual Next Build stuff, in order to be able to merge
both quickly.
* ChunkData moved from tp-dev to tp-core, the ES-serializable part moved
to tp-ecmascript;
* all runtime types moved to tp-ecmascript-runtime
This also upgrades Turbopack to turbopack-230526.2:
* https://github.com/vercel/turbo/pull/5102 <!-- Donny/강동윤 - refactor:
Fix binary bloat caused by `ValueDebugFormat` impl -->
* https://github.com/vercel/turbo/pull/4998 <!-- Alex Kirszenberg -
Node.js production runtime POC -->
## What?
Ensures the name of the chunk is not the same between two modules in different layers.
E.g. if you import 'button-library' in App Router and Pages Router we don't want these to be bundled in the same chunk as they're never used on the same page.
## How?
Added the layer to the chunk name hash generation in splitChunks. Ensures the two modules don't have the same chunk name generated, as discussed with @sokra.
Follow-up to #50324
Since the static metadata routes should always be static that can be
optimized, they should be marked as default runtime (or basically no
runtime). This PR change the runtime detection, if it's a static
metadata route file, its runtime will be erased.
So that it won't be picked up by `edge-app-route-loader` and then by
`next-image-loader` which emits the unexpected static file
Fixes NEXT-1238
If using Server Actions on the client layer without enabling the
`serverActions` feature, the build should error. Add a test case to
ensure #50199 works.
