* Refactor data fetching to support getting headers
* Relax `getNextPathnameInfo` type
* Add test for middleware internal redirects
* Export `ParsedRelativeUrl` type
* Refactor `getMiddlewareEffects`
* Move rewrite i18n test to middleware rewrite tests
* Fix bug parsing pathname info
* Normalize data requests to page requests for middleware
* Ensure there is a header `x-nextjs-matched-path` for middleware rewrites on data requests
* Extract `getDataHref` to a function
* Stop using `getDataHref` for flight
* Always set the query in `dataHref` independently of if it is SSG
* Add test for recursive rewrites
* Refactor dynamicPath validation to `matchHrefAndAsPath`
* Add `dataHref` to `FetchDataOutput`
* Extract `matchesMiddleware` function
* Add `hasMiddleware` option to `fetchNextData`
* Move preflight test
* Remove preflight test
* Add middleware prefetch tests
* Remove preflight
* Attempt to reduce bundle size
Include `withMiddlewareEffects` and `matchHrefAndAsPath` into `router`
Bring `getDataHref` back to `page-loader`
Bring `resolveDynamicRoute` back to `router`
* Reduce arg duplication for `withMiddlewareEffects`
* Remove some async/await and spreads to reduce bundle size
* Upgrade `edge-runtime` & clone `Request` on redirects to mutate headers
* Add some rewrite tests
Co-authored-by: Kiko Beats <josefrancisco.verdu@gmail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
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
This PR brings some significant refactoring in preparation for upcoming middleware changes. Each commit can be reviewed independently, here is a summary of what each one does and the reasoning behind it:
- [Move pagesDir to next-dev-server](f2fe154c00) simply moves the `pagesDir` property to the dev server which is the only place where it is needed. Having it for every server is misleading.
- [Move (de)normalize page path utils to a file page-path-utils.ts](27cedf0871) Moves the functions to normalize and denormalize page paths to a single file that is intended to hold every utility function that transforms page paths. Since those are complementary it makes sense to have them together. I also added explanatory comments on why they are not idempotent and examples for input -> output that I find very useful.
- [Extract removePagePathTail](6b121332aa) This extracts a function to remove the tail on a page path (absolute or relative). I'm sure there will be other contexts where we can use it.
- [Extract getPagePaths and refactor findPageFile](cf2c7b842e) This extracts a function `getPagePaths` that is used to generate an array of paths to inspect when looking for a page file from `findPageFile`. Then it refactors such function to use it parallelizing lookups. This will allow us to print every path we look at when looking for a file which can be useful for debugging. It also adds a `flatten` helper.
- [Refactor onDemandEntryHandler](4be685c37e) I've found this one quite difficult to understand so it is refactored to use some of the previously mentioned functions and make it easier to read.
- [Extract absolutePagePath util](3bc0783474) Extracts yet another util from the `next-dev-server` that transforms an absolute path into a page name. Of course it adds comments, parameters and examples.
- [Refactor MiddlewarePlugin](c595a2cc62) This is the most significant change. The logic here was very hard to understand so it is totally redistributed with comments. This also removes a global variable `ssrEntries` that was deprecated in favour of module metadata added to Webpack from loaders keeping less dependencies. It also adds types and makes a clear distinction between phases where we statically analyze the code, find metadata and generate the manifest file cc @shuding @huozhi
EDIT:
- [Split page path utils](158fb002d0) After seeing one of the utils was being used by the client while it was defined originally in the server, with this PR we are splitting the util into multiple files and moving it to `shared/lib` in order to make explicit that those can be also imported from client.
This continues off of https://github.com/vercel/next.js/pull/36285 fixing some of the failing test cases noticed when running the E2E tests against deployments. After these are resolved the tests will be added to our CI flow after each canary release.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
x-ref: https://github.com/vercel/next.js/pull/36285
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`
## Summary
This PR adds a new `worker` strategy to the `<Script />` component that automatically relocates and executes the script in a web worker.
```jsx
<Script
strategy="worker"
...
/>
```
[Partytown](https://partytown.builder.io/) is used under the hood to provide this functionality.
## Behavior
- This will land as an experimental feature and will only work behind an opt-in flag in `next.config.js`:
```js
experimental: {
nextScriptWorkers: true
}
```
- This setup use a similar approach to how ESLint and Typescript is used in Next.js by showing an error to the user to install the dependency locally themselves if they've enabled the experimental `nextScriptWorkers` flag.
<img width="1068" alt="Screen Shot 2022-03-03 at 2 33 13 PM" src="https://user-images.githubusercontent.com/12476932/156639227-42af5353-a2a6-4126-936e-269112809651.png">
- For Partytown to work, a number of static files must be served directly from the site (see [docs](https://partytown.builder.io/copy-library-files)). In this PR, these files are automatically copied to a `~partytown` directory in `.next/static` during `next build` and `next dev` if the `nextScriptWorkers` flag is set to true.
## Checklist
- [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.
This PR fixes#31517.
This PR removes the experimental `optimizeImages` flag. This feature was designed to automatically add preload tags for images, but I was never able to get it to do a very good job of selecting the images that actually need preloading.
This feature never graduated from experimental and in fact we never even publicized it as an experimental feature for people to try.
Additionally, even if someone was using this feature, it wouldn't have a functional effect, only a performance effect (removal of some preloads).
For those reasons, I believe it is safe to remove this functionality and that it is not a breaking change.
Related to #34185, this PR reduces the size of chunk that contains web-server.ts from 1.14mb to 210.8kb, by splitting base-http and api-utils into different environments.
Only affected thing is we can't have SSG preview mode for the web runtime via `getStaticProps`.
## 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`
# Description
The redirect responses do not contain a message body. This is in conflict with the RFCs (below) and causes Traefik (a reverse proxy) to invalidate the responses. In this pull request, I add a response body to the redirect responses.
This PR is similar to https://github.com/vercel/next.js/pull/25257, it appears that there are some other locations where redirection is handled incorrectly in next.js.
# References
- https://datatracker.ietf.org/doc/html/rfc7230#section-3.3
> All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses must not include a message-body. All other responses do include a message-body, although the body may be of zero length.
- https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.3
> The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Since #31939 is going to move the `Document` components, we can't rely on `DefinePlugin` to provide environment variables. This PR passes them as render opts instead. We can't just force this to be bundled like e.g. `next/dynamic`, because we use it internally.
We're no longer currently planning on supporting caching for dynamic responses, so we can do some cleaning & simplification:
* Multiplexing can be removed since we only ever subscribe once (via `RenderResult.pipe`, described below)
* `RenderResult.toUnchunkedString` can become synchronous since static responses are never chunked
* `RenderResult.forEach` can become `RenderResult.pipe` which helps encapsulate some of the details of `RenderResult`
Our `Observable` use has gotten sufficiently complex that it makes sense to just use a 3rd party implementation and not worry about maintaining it ourselves. As a bonus, it doesn't rely on Node APIs.
Adds `RenderResult`, replacing the `string` that `renderToHTML` used to return, with an `Observable`-like API that callers can use to subscribe and get a callback when chunks are available to flush, etc.
This is the last architectural change needed for streaming. There are, however, other things currently standing in the way of streaming. For example, it is common to mutate `res` in `getServerSideProps` to do routing work, or write headers, before fetching page data. This pattern effectively nullifies any advantages of streaming. I may do a follow-up PR that adds an experimental alternative for applications not using React 18, but the main purpose for this support is for Suspense and Server Components.
For that reason, there's no actual streaming here yet: instead we just flush a single chunk. A follow-up PR will add support for streaming suspense boundaries in React 18.
Currently there is a lot of mutation in the Next.js Server and the checks for Locale are directly coded in the general request handler. Ideally, we should have a function where we just pass the request input (url + headers + config) and generate a bunch of metadata that analyzes it generating all metadata we might require for both the URL and i18n + basePath information.
This PR brings:
- A new parsing function `parseUrl` that joins parsing an absolute/relative URL into a data structure compatible with the Node parsing output but missing redundant properties.
- A wrapper `parseNextURL` that extends `parseUrl` analyzing `i18n` and `basePath` based on the provided configuration, url and headers. This function is pure and stateless so it can be used outside of the Next.js context.
- Types improvements and reuse.
- Refactors `next-server.ts` request handling using the above mentioned functions so that the code there just apply effects to the `req` object and the `parsedUrl.query` leaving the code much more straightforward.
- Refactors `getRouteRegex` decomposing in two different functions where `getParametrizedRoute` can be used to retrieve the serializable data that is used to generate the Regex.
This ensures we don't attempt prepending the `basePath` for external (http://) `getStaticProps`/`getServerSideProps` redirects. Additional tests to cover this case have been added in the `gssp-redirect` test suites to prevent regression.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
Fixes: https://github.com/vercel/next.js/issues/23623
This adds support for a `has` field to `rewrites`, `redirects`, and `headers` to allow matching against `header`, `cookie`, and `query` values. Documentation and additional tests for the feature is also added in this PR.
Closes: https://github.com/vercel/next.js/issues/22345
This ensures we detect domain specific locales and redirect them client-side. Tests have been added in the `i18n` suite to ensure the domain redirect is applied correctly during a client-side navigation
Fixes: https://github.com/vercel/next.js/issues/19174
There's currently two bugs with the font optimization, but we'd really like to ship a stable version.
To unblock the stable release, we're **temporarily** reflagging this. It'll be unflagged on canary again!
