See https://github.com/w3c/csswg-drafts/issues/6501 to see how I found this.
This line doesn't recompute layout in browsers, because `"height"` is given as a pseudo-element name rather than a property.
The right way to do what it wants is `getComputedStyle(document.body).height`, but given nobody noticed this (and this is generally never needed, manually triggering layout should never be needed to avoid FOUC) it seems better to keep current behavior and just remove the call.
This PR proposes a fix for https://github.com/vercel/next.js/issues/11107 (JS modules are loaded twice). A more detailed explanation of the investigation that led to this PR can be found in the issue's comments (https://github.com/vercel/next.js/issues/11107#issuecomment-791780168).
## Replicability
To identify that the issue replicates on any given project, you need to
1. look at the network tab (first/clean load of site, so preferably ⌘+⇧+R on an incognito tab),
2. sort by "name", and filter requests by `mime-type:application/javascript` (selecting "JS" in the devtools filters will actually show all "script" types, but ignore all "javascript" types)
3. look for pairs of identical calls with one originating from initial HTML (`preload` of priority "high" originating from "(index)" or "([page name])") and another one from a script (`prefetch` of priority "lowest" originating from a .js file), where neither of the files is served from the cache.
Here's a screenshot of an example of what to look for:
<img width="601" alt="Screen Shot 2021-03-07 at 09 59 18" src="https://user-images.githubusercontent.com/1325721/110234627-cf1c6d00-7f2b-11eb-9cd7-749bf881ba56.png">
The issue was reproduced easily on the following projects:
- On [nextjs.org](https://nextjs.org/) where duplicates add up to ~70kB of transferred javascript out of 470kB (14.9%).
- On [vercel.com](https://vercel.com/) where duplicates add up to ~105kB of transferred javascript out of 557kB (18.8%).
- On [tiktok.com](https://tiktok.com/en) where duplicates add up to ~514kB of transferred javascript out of 1556kB (33%).
- In my own project using `"next": "^10.0.1"` (private repo) where duplicates add up to about 5% of total transferred javascript.
- In the issue's comments, a developer reported a replication using `"^10.0.7"` on a [public repo](https://github.com/SidOfc/sidneyliebrand.io).
## Some information about the fix
- Both `preload` and `prefetch` values for `<link rel="x">` behave similarly, with the difference being in network priority level (preload is high priority, prefetch is lowest priority).
- Next.js uses `<link rel="preload">` in its initial HTML but then *only* uses `<link rel="prefetch">` for the rest of the lifetime of the page.
- However, when Next.js detects that a script should be requested in advance, it only checks for matching `<link rel="prefetch">` and not `<link rel="preload">` (which have higher priority and are present earlier in the DOM, thus have a greater likelihood of being already loaded).
This PR aims to fix that oversight.
## Potential issues (none AFAIK)
As far as I can tell by looking through the codebase, **there is no downside** not to add a `prefetch` when a `preload` is already in the DOM. No other script looks for a `<link>` based on its `rel` attribute.
* Fix bug where returning `{ notFound: true }` from GSP broke `next export`
We could just as easily omit the notFoundRoutes check, but I didn't want
to mask other potential bugs that would result in missing files
* update check
* move check
Co-authored-by: jj@jjsweb.site <jj@jjsweb.site>
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
* 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`
