This replaces the server-sent events HMR connection with a WebSocket connection to prevent hitting browser connection limits, allow sending events back from the browser, and overall better performance.
This approach sets up the the `upgrade` event listener on the server immediately when created via `next dev` and on the first request using `req.socket.server` when created via a custom server. In a follow-up PR we can push the files changed via the WebSocket as well.
x-ref: https://github.com/vercel/next.js/issues/10061
x-ref: https://github.com/vercel/next.js/issues/8064
x-ref: https://github.com/vercel/next.js/issues/4495
## 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
This refactor is the first of a few changes to support "classic" (two-part)
streaming. This one should be a noop that doesn't actually change the behavior.
It re-organizes the way that functions are wrapped in Document Head/NextScript
so anything that will be part of the second flush can be separated out from the
first flush. It also adds the structure for a useMaybeDeferContent hook, but
currently always assumes that nothing should be deferred.
The next PRs will actually implement streaming.
## 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
## Bug
Fixes a TypeError when accessing url with no path params `_next/data/<BUILD_ID>`
```
TypeError: Cannot read property 'endsWith' of undefined
at Object.fn (/app/node_modules/next/server/next-server.ts:644:52)
at Router.execute (/app/node_modules/next/server/router.ts:346:40)
at Server.run (/app/node_modules/next/server/next-server.ts:1229:41)
at Server.handleRequest (/app/node_modules/next/server/next-server.ts:489:25)
at /app/node_modules/next/server/next.ts:47:14
```
- [ ] 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
- [x] Make sure the linting passes
With persistent caching and other disposing fixes we can safely reduce the time before pages are disposed.
The last 2 client pages are still never disposed.
* fix: Prevent image redirection when trailingSlash is set
* test: Trailing slash test for next/image
* lint-fix
Co-authored-by: Gustavo Edinger <gbe@nect.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Steven <steven@ceriously.com>
Bump `squoosh` to the latest version, currently commit [cad09160](cad09160b6).
Ideally, we would use the version published to npm but it hasn't been published in [two months](https://www.npmjs.com/package/@squoosh/lib?activeTab=versions) and we have a patch (#23565) that isn't available upstream.
This also is a precursor to getting support for AVIF.
- Fixes#27092
- Fixes#26527
- Reapplies the patch from #23565
* Add page mapping for Server Components
* Transform client components too
* Refactor and add to on-demand-entry-handler too
* Simplify implementation via pageExtensions
* Fix up errors
allow to dispose server while client is making changes
allow to dispose other entries while making changes
avoid recompiling when disposing entries
## 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
This ensures we prefix the `src` for static images with the `basePath` correctly, this also copies over the static image tests to the basePath image-component suite.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/29289
Ability to provide a custom tsconfig file.
**Example Usage:**
```js
// next.config.js
module.exports = {
typescript: {
tsconfigPath: "myconfig.json"
}
}
```
## 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.
- [x] Related issues linked using [`fixes #23972 (discussion)`](https://github.com/vercel/next.js/discussions/23972)
- [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`
## Documentation / Examples
- [x] Make sure the linting passes
Currently `new URL()` for server assets is completely broken because of the `publicPath` that is used for them too. `new URL()` for SSR is broken on windows as it's using absolute urls on the windows filesystem. And `new URL()` is using an incorrect filename
* Place all `asset`s correctly in `/_next/static/media` with `[name].[hash:8][ext]`
* Added a separate runtime chunk for api entries, without `publicPath`
* Introduce separate layer for api entries, which uses server-side URLs.
* Otherwise new URL() will return a faked relative URL, that is identical in SSR and CSR
* Disables react-refresh for api entries
Fixes#27413
## 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`
- [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
* Throw error if res is accessed after gSSP returns
Currently it's possible to access the `ServerResponse` through `context.res`
in `getServerSideProps()`. If one was to store that response and mutate
its headers or status code after gSSP returns (e.g. during rendering), it
would currently happen to work because of when headers are sent. However,
this is an anti-pattern that relies an implementation detail of the framework
and shouldn't be allowed. This will be particularly important once Next.js
starts to support basic streaming (two-part flush: routing then data) because
then the headers will be sent as soon as gSSP returns, which explicitly breaks
this pattern.
With this commit, the framework now throws an error in development mode if
the ServerResponse is accessed after gSSP returns.
* fixup! Throw error if res is accessed after gSSP returns
Use `Writable` instead of `Observable` and remove the `zen-observable` dependencies. I initially opted to use `Observable` for simplicity and fast iteration, but we should really just use `Writable` directly (or some other stream in the future).
React's streaming SSR has some [specific requirements](https://github.com/reactwg/react-18/discussions/66#discussioncomment-944266) on the stream API. Rather than trying to also squeeze a `Readable` in here, which might be more standard for node apps, I've just followed React's lead. By limiting ourselves to just `Writable`, it ought to be easier to adopt a different stream type in the future if desired.
The React `pipeToNodeWritable` API requires us to pass a stream immediately, but we don't actually have a `ServerResponse` to give it until `RenderResult.pipe(...)` is called later. For that reason, we pass React a `Writable` that we will simply forward to `res` later. This mechanism of deferring is `NodeWritablePiper`, which is just a function that can be called with `ServerResponse` (or another `Writable`, as we now do to render to string for static results) to have content written to it. `NodeWritablePiper` takes a `next` argument so that we can chain both synchronous and asynchronous pipers together.
Also does some clean up and adds another streaming test for backpressure.
This ensures we have the correct `cache-control` header when `revalidate` is used with `notFound: true` on `getStaticProps` or `getServerSideProps` pages.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://app.clubhouse.io/vercel/story/23445
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`
Updates the React 18 concurrent tests to support streaming, by using webdriver (instead of cheerio) to support dynamic updates, and being more explicit about SSR vs. hydrated content.
Also enables streaming support by setting `supportsDynamicHTML: true` in `pipe(...)` for non-bot user agents.
Previous to this change, getServerSideProps could only return plain objects
for props, e.g.:
```javascript
export async function getServerSideProps() {
return {
props: {
text: 'some value',
}
}
}
```
With this commit, the props object can also be a Promise, e.g.
```javascript
export async function getServerSideProps() {
return {
props: (async function () {
return {
text: 'promise value',
}
})(),
}
}
```
For now, the framework simply waits for the results of the props Promise to resolve,
but this small change sets the groundwork for later allowing props to be streamed (cc @devknoll).
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. -- *This is part of @devknoll's ongoing work to support streaming.*
- [ ] 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. *not sure if this applies here*
- [ ] Errors have helpful link attached, see `contributing.md`
