* Remove inert font tag in font optimization
* Fix lint
* Remove inert font tag during font optimization
* Fix lint
* Fix lint
* Fix lint
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Includes a fix for when a tree is rendered without the styled-jsx registry being provided. It'll noop in this new version.
## 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 fixes segments inside of the host of the destination failing to parse with url.parse due to the unexpected colon by escaping the colon for segments and then unescaping them after we have parsed the URL.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
x-ref: https://github.com/vercel/vercel/pull/6713
* 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
This should fix this: https://github.com/vercel/next.js/pull/28883/checks?check_run_id=3560578176#step:4:353
## 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
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.
In a previous PR, `getServerSideProps` was altered to support returning
`props` as a promise. This change updates the TS types to permit promises
as well, so you can write type `GetServerSideProps<Props>` instead of
`GetServerSideProps<Promise<Props>>`. e.g.:
```typescript
type Props = {
data: string
}
export const getServerSideProps: GetServerSideProps<Props> = async (
context
) => {
return {
props: (async function () {
return { data: 'some data' }
})(),
}
}
```
## Feature
- [x] 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`
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
## Bug
- [x] 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
I updated rust dependencies and node dependencies.
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`
This applies the fix from the awesome investigation done in https://github.com/vercel/next.js/issues/28797 by @jayphelps and adds a test to ensure this is working as expected. It seems that the `route-loader` has a race condition while prefetching and if a script is executed before we have created a current "future" entry to resolve the entry stays in a pending state causing routes to hang so this handles the condition by ensuring pending/errored entries do not stay around.
## 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/28797
Fixes: https://github.com/vercel/next.js/issues/27783
* Expose minify in next-swc
* Expose minify in js binding
* Use new minify function in terser plugin
* Only upload changed binary artifact
* Build next-swc binaries
* Add swc license info to copied file
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.
