## Feature
This PR introduces the ability to provide `runtime: "edge"` in API endpoints, the same as the experimental RSC runtime configurations.
- [ ] 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 `yarn lint`
Router context should be treated as rsc shared dep otherwise client component won't receive the instance in edge runtime
## Bug
- [x] Integration tests added
Another strategy to do achieve the goal of #36995. With this PR the module IDs will be:
- (1) RSC: named (_this one doesn't matter_)
- (2) SSR: named
- (3) Client: deterministic
And we include the client module IDs in the flight manifest, as well as an extra mapping of 3) → 2) so during SSR it can require the correct module still.
## 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 `yarn lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Follow-up PR for #37134, this PR adds back the hash in each chunk's filename. This `chunks` in the flight manifest will now be `chunkId:chunkFilename` with this PR, and `globalThis.__next_chunk_load__` then handles the chunk registration (uses chunkId) and chunk loading (uses chunkFilename). (Q: how can we port this to React?)
We can't use `[contenthash]` but only `[chunkhash]` because at the stage of generating the flight manifest, the content isn't finalized and the hash changes after that.
## 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 `yarn lint`
This PR makes sure that chunks of client components can be loaded via `__webpack_chunk_load__`, and hydrated correctly inside `viewsDir`.
Side note: we have to get rid of `[contenthash]` from the chunk filename because of a conflict currently which can be resolved later.
## 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 `yarn lint`
Linked to issue #32209.
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] 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
The purpose of this PR is to enable Trusted Types compatibility in Webpack. When the app is run in development mode, Webpack is currently set to use an [eval-source-map](5a16b1a26f/packages/next/build/webpack/config/blocks/base.ts (L33)). This source map involves passing raw strings to `eval()` calls, which raise Trusted Types violations. The solution to this problem is to set `webpack5Config.output.trustedTypes` in the Webpack config. As shown in the documentation [here](https://webpack.js.org/configuration/output/#outputtrustedtypes), setting this value to a string will create a Trusted Types policy with the specified name. By creating a policy within Webpack, the raw strings passed to the `eval()` calls will be promoted to be of type `TrustedScript`. The issue where this was addressed in Webpack can be found [here](https://github.com/webpack/webpack/issues/14075).
### Note:
The policy name that is set in the Webpack config is currently `nextjs#bundler`. Once it is released to the public and application developers begin using it, it may be harder to change the value since any application developers with a custom policy name allowlist would now need to update their next.config.js headers to allow this new name. Thus, a good name should ideally be determined before this pull request is merged. The reason that `nextjs#bundler` is preferred over `nextjs#webpack` is in case Next.js moves to a different bundler in the future. Having a generic name would allow for application developers to keep their next.config.js file the same after the bundler switch has occurred. If a different name is preferred, feel free to comment what that would be.
The code was tested in a sample application to ensure it behaved as expected.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
We added custom _app as server component support in #33149, but we found it's pretty confusing on usage like support it both server component pages and regular pages at the same time for having similar layout purpose.
When using the _app.server and _app at the same time, applying them into proper places become more confusing.
In that case, we decide to make _app.js can't be a server component, and you can still keep all the existing thing there. And also you don't need to think of the corresponding APIs of custom _app in RSC
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Docs updated
The Edge SSR server and the client bundle should share the same Styled JSX instance to ensure the context can be passed correctly, same with the way we handle `next/head`.
## 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 `yarn lint`
This PR deprecates declaring a middleware under `pages` in favour of the project root naming it after `middleware` instead of `_middleware`. This is in the context of having a simpler execution model for middleware and also ships some refactor work. There is a ton of a code to be simplified after this deprecation but I think it is best to do it progressively.
With this PR, when in development, we will **fail** whenever we find a nested middleware but we do **not** include it in the compiler so if the project is using it, it will no longer work. For production we will **fail** too so it will not be possible to build and deploy a deprecated middleware. The error points to a page that should also be reviewed as part of **documentation**.
Aside from the deprecation, this migrates all middleware tests to work with a single middleware. It also splits tests into multiple folders to make them easier to isolate and work with. Finally it ships some small code refactor and simplifications.
Implements the first part of #33227
- Applies browserslist to JS transforms when `experimental.browsersListForSwc` is enabled.
- You don't have to use browserslist, there's also `legacyBrowsers: false` which will be the new default in Next.js 13. See #33227 for which browsers and why. `legacyBrowsers` requires `browsersListForSwc: true` to function until it is the default.
```js
module.exports = {
experimental: {
legacyBrowsers: false,
browsersListForSwc: true,
}
}
```
I only implemented the JS part of the RFC, the CSS part should be handled in a follow-up PR.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## 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 `yarn lint`
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
This adds an experimental config for testing `basePath` handling on the client.
x-ref: [slack thread](https://vercel.slack.com/archives/CLDDX2Y0G/p1652221605742559)
## 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 `yarn lint`
Follow-up to https://github.com/vercel/next.js/pull/36612 this updates to eagerly load the swc bindings unless babel is being used so that we don't wait for the transform calls to initialize swc. Eagerly loading in jest also allows us to fallback to the wasm bindings when previously we couldn't since they needed to wait for the import.
* move FlightManifestPlugin to server compilers
* revert loader condition
* fix module id
* fix test and refactor
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
fixes#36763fixes#36590
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- It hasn't been accepted for implementation, although that process isn't clear, and this is a pretty trivial fix.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- This is somewhat inherent in the error log
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `yarn lint`
## Description
This PR implements a new configuration object in `next.config.js` called `experimental.images.remotePatterns`.
This will eventually deprecate `images.domains` because it covers the same use cases and more by allowing wildcard pattern matching on `hostname` and `pathname` and also allows restricting `protocol` and `port`.
## Feature
- [x] Implements an existing feature request.
- [x] Related issues linked
- [x] Unit tests added
- [x] Integration tests added
- [x] Documentation added
- [x] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
## Related
- Fixes#27925
- Closes#18429
- Closes#18632
- Closes#18730
- Closes#27345
- improve the message for importing node builtin module on edge runtime
- fix to show the message on overlay of error browser with `next dev`
- fix https://github.com/vercel/next.js/issues/36237
The message is NOT shown when using edge runtime (not middleware) since I cannot find a way to detect a webpack compilation is for edge runtime.
## 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 `yarn lint`
* hoist `react-dom/server` imports to reduce module load time in nodejs
* simplify `reactRoot` detection condition by checking the streaming rendering API we're using. (if it doesn't existed, like react 17, then we won't enable `reactRoot`)
* Merge `__NEXT_CONCURRENT_FEATURES` into `__NEXT_REACT_ROOT` env var since they're identical now
Fixes https://github.com/vercel/next.js/discussions/32233⚠️ If you're looking at this PR please read the complete description including the part about incremental adoption.
## TLDR:
Official support for `<Link href="/about">About</Link>` / `<Link href="/about"><CustomComponent /></Link>` / `<Link href="/about"><strong>About</strong></Link>` where `<Link>` always renders `<a>` without edge cases where it doesn’t render `<a>`. You'll no longer have to put an empty `<a>` in `<Link>` with this enabled.
## Full context
### Changes to `<Link>`
- Added an `legacyBehavior` prop that defaults to `true` to preserve the defaults we have today, this will allow to run a codemod on existing codebases to move them to the version where `legacyBehavior` becomes `false` by default
- When using the new behavior `<Link>` always renders an `<a>` instead of having `React.cloneElement` and passing props onto a child element
- When using the new behavior props that can be passed to `<a>` can be passed to `<Link>`. Previously you could do something like `<Link href="/somewhere"><a target="_blank">Download</a></Link>` but with `<Link>` rendering `<a>` it now allows these props to be set on link. E.g. `<Link href="/somewhere" target="_blank"></Link>` / `<Link href="/somewhere" className="link"></Link>`
### Incremental Adoption / Codemod
The main reason we haven't made these changes before is that it breaks pretty much all Next.js apps, which is why I've been hesitant to make this change in the past. I've spent a bunch of time figuring out what the right approach is to rolling this out and ended up with an approach that requires existing apps to run a codemod that automatically opts their `<Link>` usage into the old behavior in order to keep the app functioning.
This codemod will auto-fix the usage where possible. For example:
- When you have `<Link href="/about"><a>About</a></Link>` it'll auto-fix to `<Link href="/about">About</Link>`
- When you have `<Link href="/about"><a onClick={() => console.log('clicked')}>About</a></Link>` it'll auto-fix to `<Link href="/about" onClick={() => console.log('clicked')}>About</Link>`
- For cases where auto-fixing can't be applied the `legacyBehavior` prop is added. When you have `<Link href="/about"><Component /></Link>` it'll transform to `<Link href="/about" legacyBehavior><Component /></Link>` so that your app keeps functioning using the old behavior for that particular link. It's then up to the dev to move that case out of the `legacyBehavior` prop.
**This default will be changed in Next.js 13, it does not affect existing apps in Next.js 12 unless opted in via `experimental.newLinkBehavior` and running the codemod.**
Some code samples of what changed:
```jsx
const CustomComponent = () => <strong>Hello</strong>
// Legacy behavior: `<a>` has to be nested otherwise it's excluded
// Renders: <a href="/about">About</a>. `<a>` has to be nested.
<Link href="/about">
<a>About</a>
</Link>
// Renders: <strong onClick={nextLinkClickHandler}>Hello</strong>. No `<a>` is included.
<Link href="/about">
<strong>Hello</strong>
</Link>
// Renders: <strong onClick={nextLinkClickHandler}>Hello</strong>. No `<a>` is included.
<Link href="/about">
<CustomComponent />
</Link>
// --------------------------------------------------
// New behavior: `<Link>` always renders `<a>`
// Renders: <a href="/about">About</a>. `<a>` no longer has to be nested.
<Link href="/about">
About
</Link>
// Renders: <a href="/about"><strong>Hello</strong></a>. `<a>` is included.
<Link href="/about">
<strong>Hello</strong>
</Link>
// Renders: <a href="/about"><strong>Hello</strong></a>. `<a>` is included.
<Link href="/about">
<CustomComponent />
</Link>
```
---
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
As the title. This is intended to be applied on both middleware and edge functions.
## 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 `yarn lint`
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Fixes#35449
Include the shared components (from source code) is in client bundles, previously we lost them so that the client components imported by them are lost in module graph
* let flight server loader apply to all pages and imported modules (except node_modules at the moment)
* if it's a shared component from source code, include it in client bundle
* ignore handling node_modules at the moment (due to the limitation support of esm imports with RSC)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
x-ref: #33149
RFCs:
- #30996
- #31506
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
* Add warning when importing "next" directly
* Apply suggestions from code review
Co-authored-by: Balázs Orbán <info@balazsorban.com>
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* add example
Co-authored-by: Balázs Orbán <info@balazsorban.com>
Co-authored-by: Steven <steven@ceriously.com>
Related to #31678
For streaming pages,
Nodejs runtime: setting global runtime to `"nodejs"` will work with default module resolution.
Edge runtime: previously next.js will pick up browser field since it's the "similar" asset (unlike nodejs) to edge runtime but browser specific things like DOM api could breaks cause edge runtime is more like worker without dom runtime.
This PR is to revert the main field resolution behavior. And if you have a library targeting multiple runtime with different fields, ideally is to make it more isomorphic and will be easy to use in edge runtime
This PR depends on #35242 and #35243. It allows the global runtime to be unset, as well as enables static optimization for Fizz and RSC pages in the Node.js runtime. Currently for the Edge runtime pages are still always SSR'd.
Closes#31317.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] 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 `yarn lint`
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
