This PR removes `<noscript>` from `next/future/image` since it is no longer needed now that we use a svg blur placeholder (as opposed to css filter).
- Fixes #38621
- Closes#39736
This PR updates the `next/future/image` component so that CSS `filter` is never needed. Previously, we used SVG to blur for prod and CSS to blur for dev, but now we use SVG for both.
This required a shared function `getImageBlurSvg()` used between both client and server because `next dev` doesn't create Data URIs and instead defers blur generation until request time. So we also need to defer svg generation to request time (on the server) during next dev.
This is the first step to removing `<noscript>` completely (see #39736).
Typescript published 4.8.2 today and it fails CI, bump our typescript version to 4.8.2 and tweak some typings to make existing e2e typescript tests work properly
* Bump web-vitals from 3.0.0-beta to 3.0.0 stable for typing fix (there's an undefined type but it wasn't caught by ts 4.7), also force compiled it as CJS for pre-compiled
* Bump ncc to 3.34.0 for ts-loader compatibility for new typescript version, ncc 3.33.x cannot work with ts 4.8
* Update pre-compiled
Fixes#39993.
Before the PR:
- `next/script` component mount, `useEffect` for `onReady` executes
- The script's cacheKey is not added to `LoadCache`, skip `onReady`
- The second `useEffect` for `loadScript` executes
- The script's cacheKey is added to `LoadCache` even if it might not fully load yet
- Because of React's strict mode, `useEffect` for `onReady` executes again
- Since the script's cacheKey is in `LoadCache`, `onReady` is called (even when the script is not loaded yet)
- After the script is actually loaded, inside the `script.onload` event handler the `onReady` is called again
After the PR:
- `next/script` component mount, `useEffect` for `onReady` executes
- The script's cacheKey is not added to `LoadCache`, `useEffect` skips `onReady`
- The second `useEffect` for `loadScript` executes
- The script's cacheKey is added to `LoadCache` only if it is an inline script
- Because of React's strict mode, `useEffect` for `onReady` executes again
- The script is not yet loaded, its cacheKey is not in `LoadCache`, `useEffect` skips `onReady` again
- After the script is actually loaded, inside the `script.onload` event handler the `onReady` is finally called
In short, the PR resolves a race condition that only occurs under React strict mode (and makes the `next/script` component more concurrent rendering resilient).
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Removes extra log shown when checking `moduleResolution` in
`tsconfig.json` and adds regression test.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This fixes the prefetching handling when middleware is present as currently we are incorrectly triggering data requests for non-SSG pages to handle the case where a middleware rewrite is present and pointing to an SSG path. Since the majority use case won't be rewriting in middleware and this incurs a lot of potentially heavy requests to `getServerSideProps` paths this matches the prefetch handling when middleware isn't present and only prefetches the data route when we match an SSG path.
Fixes: [slack thread](https://vercel.slack.com/archives/C0289CGVAR2/p1661364670589519?thread_ts=1661199566.675759&cid=C0289CGVAR2)
Fixes: https://github.com/vercel/next.js/issues/38918
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This warning was incorrectly printed when `fill` and `placeholder="blur"` were used together:
> Image with src "/test.jpg" is smaller than 40x40. Consider removing the "placeholder='blur'" property to improve performance.
- Group edge ssr tests, merge `edge-vs.-non-edge-api-route-priority` and `react-18-streaming-ssr` into 1 e2e test suite
- Add rewrite case to edge ssr in switchable runtime
This PR is a follow up to PR #39190 so that we can dynamically set the `feComponentTransfer` when we know the image doesn't have transparency (at this time its just jpeg).
We also set the stdDeviation to 1 and the viewbox to the placeholder's width/height to avoid any rounding issues.
Finally, we also fix the conversion from `objectPosition` to `backgroundPosition` because they have different default values according to the spec.
Fixes#39807.
When statically importing an image, the `width` and `height` will always be provided alongside the `src` by the Webpack. `next/image` will ignore `width` and `height` come from Webpack when `layout === 'fill'`, while `next/future/image` will not, hence the issue. The PR fixes that. The corresponding integration test cases are also added.
cc @styfle
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Improve PR improves the error message on `next/future/image` when `objectFit` or `objectPosition` is provided and suggests using `style` instead. It also prints the stack trace so its clear where the error came from.
The PR fixes#39706 by adding `avif` mime type directly to `send`. The PR also removes the previous avif workaround for image optimizer.
Note: The PR is still a workaround for now. I will submit a PR to `pillarjs/send` to help them update `mime` to fix the issue once and for all. But now `send.mime.define` just works.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Currently, `next/dynamic` will opt-in to `React.lazy` if `{ suspense: true }` is used. And React 18 will always resolve the `Suspense` boundary on the server-side, effectively ignoring the `ssr` option.
The PR fixes#39609 by showing a warning message when `{ suspense: true, ssr: false }` is detected. The error documentation and the corresponding test case has also been updated.
In the future, Next.js could implement a custom version of `React.lazy` that could suspense without executing the lazy-loaded component on the server-side.
cc @huozhi
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
The PR fixes#39642, by supporting GitHub repo URLs with a trailing slash while without branch and path.
tsconfig behaves differently with `tsc` vs. Next.js. When `baseurl` is omitted, `paths` should be resolved against the tsconfig location. Consequentially, in this case the paths must start with `./`. This PR aligns Next.js behavior with `tsc` around `paths` without `baseurl`.
Related: https://github.com/microsoft/TypeScript/pull/40101
This PR adds default style properties to a fill-mode image using `next/future/image` of 0 for all positions. This should replicate the existing `layout="fill"` behavior better, and make it easier to migrate.
Tests are also added for fill styling.
This fixes the case where we were incorrectly ignoring the next-auth API endpoint since it matched the `.next` watch ignore and also adds a test case to ensure we match this route correctly.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/39495
## Bug
- [fixes#39035 ] 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This ensures we properly handle rewrites when the request is a WebSocket request. This also adds an integration test to ensure it is working as expected in dev and production mode.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/32634
Closes: https://github.com/vercel/next.js/pull/38455
* Use require hook and alias to resolve styled-jsx
* re-export styled-jsx types from compiled
* fix lint
* add test for styled-jsx css
* setup require hook in server
* compile import path to styled-jsx/style
* revert require hook
* add test for server styled-jsx resolving
* update test
* pre copy styled-jsx assets
* fix styled-jsx dts
* add npmrc for styled-jsx e2e test
* load require hook directly
* rm legacy test
* fix lint
* fix pnpm install error
* split require hook
* only alias styled-jsx
* make styled-jsx resolving statically analyzable
* update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Add support for `--output-file` on ESLint cli, based on this discussion https://github.com/vercel/next.js/discussions/26179, and this closed PR https://github.com/vercel/next.js/pull/35154. With this flag, it is possible to save the output in a file and use it for any purpose.
## 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 by running `yarn lint`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
In many browsers (other than Chrome), the `alt` text is visible while the image is loading. This causes a sense layout shift since you'll see a flash of text and then the image (although lighthouse measures 0 CLS, likely because Chrome doesn't have this problem). This PR updates `next/future/image` to hide the alt text, unless there is an error while loading the image in which case the `alt` text because relevant as the fallback.
Example:
<img width="115" alt="image" src="https://user-images.githubusercontent.com/229881/183128008-0660c50c-18aa-4e64-872e-ada9a652130f.png">
Unfortunately, Safari also shows a border while lazy loading images and it cannot be styled.
See upstream issue here: https://bugs.webkit.org/show_bug.cgi?id=243601
We were resizing animated images when importing them, but we don't optimize images when they come from an upstream provider. For consistency, we can skip resizing for local animated images as well.
Fixes#39317
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR removes the default styling of `object-fit:"contain"` for images using the future image component. This means images will get the default `object-fit` behavior of `"fill"`.
The main reason for this change is that an inline style will take precedence over external CSS, making this default behavior difficult to override with some styling strategies.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
This PR adds a `fill` attribute to the future image component, that behave similarly to the fill mode on the existing image component.
Functionally, it mainly adds `position: "absolute"` and `object-fit: "contain"` to the image element, along with `height: "100%"` and `width: "100%"` to preserve the image aspect ratio. All of these can be overwritten by the user, except for `position: "absolute"`, which will throw an error. This is because changing that property without height and width is likely to cause layout shift.
Because we no longer have the wrapper element, this new version of `fill` requires that the user set `overflow: "hidden"` on the parent element themself, if they want that behavior.
This PR also includes several runtime checks to catch instances where the fill mode may provide unexpected results. These runtime checks warn if:
* The image doesn't have the `sizes` attribute and loads much smaller than the viewport
* The containing element does not have `position: "relative"`
* The image height value is 0
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
When we detect if `reactRoot` rendering should be enabled we `require` the require to check the version. But at that time the `NODE_ENV` isn't set yet. Then the react dev build stays in the `require.cache` that any future require of react will get the wrong build. In that case, React dev bundle is picked in production mode.
Fun fact: if you're using hooks, that seem not to effect you, but context consumer works different then you couldn't get the proper context from provider.
Fixes#38176Fixes#38765Fixes#38332
## Bug
- [x] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Closes: #30962
This PR adds a new `onReady` prop to `next/script` to handle shortcomings of the current `onLoad` prop. Some third-party providers and widgets require initialization code to run after the script's `load` event and every time the component is mounted. The `onReady` should solve that use case.
For more details, refer to the discussion in #30962.
CC @janicklas-ralph
## Bug
- [X] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
* test: cleanup telemetry integration test
Instead of constantly parsing the console output, parse the output
once, convert the entries in JavaScript objects, then compare them
logically rather than textually.
* Collect telemetry for next/future/image
Track adoption of next/future/image and add relevant test.
This adds handling for prefetching `onTouchStart` as this gives a little more time to start parsing required scripts for a page transition if not already done that can help make the transition faster. This is based on research showing the touch start event firing on average `90ms` before click (x-ref: [source](https://instant.page/#:~:text=in%20the%20world.-,On%20mobile,-A%20user%20starts))
This also adds testing safari with playwright so we can run these in PRs instead of only after merge and adds initial mobile testing as well.
x-ref: [slack thread](https://vercel.slack.com/archives/C7PDM7X2M/p1658250170774989?thread_ts=1658249275.178349&cid=C7PDM7X2M)
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Lands #37431 again, but it only solves the re-render issue completely for the middleware case (closes#38267), not the `rewrites` case (#37139).
For `rewrites`, the blocker is `isReady` always being `false` initially and to match the markup on hydration we can't simply work around it without a re-render. Need to come up with another fix.
## Bug
- [x] 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This ensures we correctly detect query and hash values when there are `?` characters in the hash. A regression test to ensure this working properly has been added.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/38783
## What’s in there?
This PR brings more consistency in how errors and warnings are reported when running code in the Edge Runtime:
- Dynamic code evaluation (`eval()`, `new Function()`, `WebAssembly.instantiate()`, `WebAssembly.compile()`…)
- Usage of Node.js global APIs (`BroadcastChannel`, `Buffer`, `TextDecoderStream`, `setImmediate()`...)
- Usage of Node.js modules (`fs`, `path`, `child_process`…)
The new error messages should mention *Edge Runtime* instead of *Middleware*, so they are valid in both cases.
It also fixes a bug where the process polyfill would issue a warning for `process.cwd` (which is `undefined` but legit). Now, one has to invoke the function `process.cwd()` to trigger the error.
It finally fixes the react-dev-overlay, where links from middleware and Edge API route files could not be opened because of the `(middleware)/` prefix in their name.
About the later, please note that we can’t easily remove the prefix or change it for Edge API routes. It comes from the Webpack layer, which is the same for both. We may consider renaming it to *edge* instead in the future.
## How to test?
These changes are almost fully covered with tests:
```bash
pnpm testheadless --testPathPattern runtime-dynamic
pnpm testheadless --testPathPattern runtime-with-node
pnpm testheadless --testPathPattern runtime-module
pnpm testheadless --testPathPattern middleware-dev-errors
```
To try them out manually, you can write a middleware and Edge route files like these:
```jsx
// middleware.js
import { NextResponse } from 'next/server'
import { basename } from 'path'
export default async function middleware() {
eval('2+2')
setImmediate(() => {})
basename()
return NextResponse.next()
}
export const config = { matcher: '/' }
```
```jsx
// pages/api/route.js
import { basename } from 'path'
export default async function handle() {
eval('2+2')
setImmediate(() => {})
basename()
return Response.json({ ok: true })
}
export const config = { runtime: 'experimental-edge' }
```
The expected behaviours are:
- [x] dev, middleware/edge route is using a node.js module: error at runtime (logs + read-dev-overlay):
```bash
error - (middleware)/pages/api/route.js (1:0) @ Object.handle [as handler]
error - The edge runtime does not support Node.js 'path' module.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
> 1 | import { basename } from "path";
2 | export default async function handle() {
```
- [x] build, middleware/edge route is using a node.js module: warning but succeeds
```bash
warn - Compiled with warnings
./middleware.js
A Node.js module is loaded ('path' at line 4) which is not supported in the Edge Runtime.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
./pages/api/route.js
A Node.js module is loaded ('path' at line 1) which is not supported in the Edge Runtime.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
```
- [x] production, middleware/edge route is using a node.js module: error at runtime (logs + 500 error)
```bash
Error: The edge runtime does not support Node.js 'path' module.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
at <unknown> (file:///Users/damien/dev/next.js/packages/next/server/web/sandbox/context.ts:149)
```
- [x] dev, middleware/edge route is using a node.js global API: error at runtime (logs + read-dev-overlay):
```bash
error - (middleware)/pages/api/route.js (4:2) @ Object.handle [as handler]
error - A Node.js API is used (setImmediate) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime
2 |
3 | export default async function handle() {
> 4 | setImmediate(() => {})
| ^
```
- [x] build, middleware/edge route is using a node.js global API: warning but succeeds
```bash
warn - Compiled with warnings
./middleware.js
A Node.js API is used (setImmediate at line: 6) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime
./pages/api/route.js
A Node.js API is used (setImmediate at line: 3) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime
```
- [x] production, middleware/edge route is using a node.js module: error at runtime (logs + 500 error)
```bash
Error: A Node.js API is used (setImmediate) which is not supported in the Edge Runtime.
Learn more: https://nextjs.org/docs/api-reference/edge-runtime
at <unknown> (file:///Users/damien/dev/next.js/packages/next/server/web/sandbox/context.ts:330)
```
- [x] dev, middleware/edge route is loading dynamic code: warning at runtime (logs + read-dev-overlay) and request succeeds (we allow dynamic code in dev only):
```bash
warn - (middleware)/middleware.js (7:2) @ Object.middleware [as handler]
warn - Dynamic Code Evaluation (e. g. 'eval', 'new Function') not allowed in Edge Runtime
5 |
6 | export default async function middleware() {
> 7 | eval('2+2')
```
- [x] build, middleware/edge route is loading dynamic code: build fails with error:
```bash
Failed to compile.
./middleware.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile') not allowed in Edge Runtime
Used by default
./pages/api/route.js
Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile') not allowed in Edge Runtime
Used by default
```
## Notes to reviewers
Edge-related errors are either issued from `next/server/web/sandbox/context.ts` file (runtime errors) or from `next/build/webpack/plugins/middleware-plugin.ts` (webpack compilation).
The previous implementation (I’m pleading guilty here) was way too verbose: some errors (Node.js global APIs like using `process.cwd()`) could be reported several times, and the previous mechanism to dedupe them (in middleware-plugin) wasn’t really effective.
Changes in tests are due to renaming existing tests such as `test/integration/middleware-with-node.js-apis` into `test/integration/edge-runtime-with-node.js-apis`. I extended them to cover Edge API route.
@hanneslund I’ve pushed the improvement you did in https://github.com/vercel/next.js/pull/38289/ one step further to avoid duplication.
Currently, when a user forgets the `src` prop on an image, an error is thrown. However that error doesn't include any of the the user's code in the stack trace, so its nearly impossible to figure out which image is the culprit if there are multiple images on the page.
Since this error only throws on demand when a page is visited during `next dev`, we can instead delay the error so it no longer prints on the server but prints on mount instead. At that point, we'll have the `<img>` element via ref and can print it to the web console with the stack trace.
- Fixes#23742
Fixes#38533 by including `src/` as a default linting directory where all files within are linted
## Bug
- [X] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
* Add next.config.js validation with ajv
* update manifest
* update lib type
* remove old tests
* update to pre-build validation code
* ensure validate output is ncced
* Apply suggestions from code review
Co-authored-by: Steven <steven@ceriously.com>
* Add example of typing next.config.js
Co-authored-by: Steven <steven@ceriously.com>
## Client-side router for `app` directory
This PR implements the new router that leverages React 18 concurrent features like Suspense and startTransition.
It also integrates with React Server Components and builds on top of it to allow server-centric routing that only renders the part of the page that has to change.
It's one of the pieces of the implementation of https://nextjs.org/blog/layouts-rfc.
## Details
I'm going to document the differences with the current router here (will be reworked for the upgrade guide)
### Client-side cache
In the current router we have an in-memory cache for getStaticProps data so that if you prefetch and then navigate to a route that has been prefetched it'll be near-instant. For getServerSideProps the behavior is different, any navigation to a page with getServerSideProps fetches the data again.
In the new model the cache is a fundamental piece, it's more granular than at the page level and is set up to ensure consistency across concurrent renders. It can also be invalidated at any level.
#### Push/Replace (also applies to next/link)
The new router still has a `router.push` / `router.replace` method.
There are a few differences in how it works though:
- It only takes `href` as an argument, historically you had to provide `href` (the page path) and `as` (the actual url path) to do dynamic routing. In later versions of Next.js this is no longer required and in the majority of cases `as` was no longer needed. In the new router there's no way to reason about `href` vs `as` because there is no notion of "pages" in the browser.
- Both methods now use `startTransition`, you can wrap these in your own `startTransition` to get `isPending`
- The push/replace support concurrent rendering. When a render is bailed by clicking a different link to navigate to a completely different page that still works and doesn't cause race conditions.
- Support for optimistic loading states when navigating
##### Hard/Soft push/replace
Because of the client-side cache being reworked this now allows us to cover two cases: hard push and soft push.
The main difference between the two is if the cache is reused while navigating. The default for `next/link` is a `hard` push which means that the part of the cache affected by the navigation will be invalidated, e.g. if you already navigated to `/dashboard` and you `router.push('/dashboard')` again it'll get the latest version. This is similar to the existing `getServerSideProps` handling.
In case of a soft push (API to be defined but for testing added `router.softPush('/')`) it'll reuse the existing cache and not invalidate parts that are already filled in. In practice this means it's more like the `getStaticProps` client-side navigation because it does not fetch on navigation except if a part of the page is missing.
#### Back/Forward navigation
Back and Forward navigation ([popstate](https://developer.mozilla.org/en-US/docs/Web/API/Window/popstate_event)) are always handled as a soft navigation, meaning that the cache is reused, this ensures back/forward navigation is near-instant when it's in the client-side cache. This will also allow back/forward navigation to be a high priority update instead of a transition as it is based on user interaction. Note: in this PR it still uses `startTransition` as there's no way to handle the high priority update suspending which happens in case of missing data in the cache. We're working with the React team on a solution for this particular case.
### Layouts
Note: this section assumes you've read [The layouts RFC](https://nextjs.org/blog/layouts-rfc) and [React Server Components RFC](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)
React Server Components rendering leverages the Flight streaming mechanism in React 18, this allows sending a serializable representation of the rendered React tree on the server to the browser, the client-side React can use this serialized representation to render components client-side without the JavaScript being sent to the browser. This is one of the building blocks of Server Components. This allows a bunch of interesting features but for now I'll keep it to how it affects layouts.
When you have a `app/dashboard/layout.js` and `app/dashboard/page.js` the page will render as children of the layout, when you add another page like `app/dashboard/integrations/page.js` that page falls under the dashboard layout as well. When client-side navigating the new router automatically figures out if the page you're navigating to can be a smaller render than the whole page, in this case `app/dashboard/page.js` and `app/dashboard/integrations/page.js` share the `app/dashboard/layout.js` so instead of rendering the whole page we render below the layout component, this means the layout itself does not get re-rendered, the layout's `getServerSideProps` would not be called, and the Flight response would only hold the result of `app/dashboard/integrations/page.js`, effectively giving you the smallest patch for the UI.
---
Note: the commits in this PR were mostly work in progress to ensure it wasn't lost along the way. The implementation was reworked a bunch of times to where it is now.
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
## What's in there?
The Edge runtime [does not support Node.js modules](https://edge-runtime.vercel.app/features/available-apis#unsupported-apis).
When building Next.js application, we currently fail the build when detecting node.js module imported from middleware.
This is an blocker for using code that is conditionally loading node.js modules (based on platform/env detection), as @cramforce reported.
This PR implements a new strategy where:
- we can build such middleware/Edge API route code **with a warning**
- we fail at run time, with graceful errors in dev (console & react-dev-overlay error)
- we fail at run time, with console errors in production
## How to test?
All cases are covered with integration tests.
To try them live, create a simple app with a page, a `middleware.js` file and a `pages/api/route.js`file.
Here are iconic examples:
### node.js modules
```js
// middleware.js
import { NextResponse } from 'next/server'
// static
import { basename } from 'path'
export default async function middleware() {
// dynamic
const { basename } = await import('path')
basename()
return NextResponse.next()
}
export const config = { matcher: '/' }
```
```js
// pags/api/route.js
// static
import { isAbsolute } from 'path'
export default async function handle() {
// dynamic
const { isAbsolute } = await import('path')
return Response.json({ useNodeModule: isAbsolute('/test') })
}
export const config = { runtime: 'experimental-edge' }
```
Desired error (+ source code highlight in dev):
> The edge runtime does not support Node.js 'path' module
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
Desired warning at build time:
> A Node.js module is loaded ('path' at line 2) which is not supported in the Edge Runtime.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
- [x] in dev middleware, static, shows desired error on stderr
- [x] in dev route, static, shows desired error on stderr
- [x] in dev middleware, dynamic, shows desired error on stderr
- [x] in dev route, dynamic, shows desired error on stderr
- [x] in dev middleware, static, shows desired error on react error overlay
- [x] in dev route, static, shows desired error on react error overlay
- [x] in dev middleware, dynamic, shows desired error on react error overlay
- [x] in dev route, dynamic, shows desired error on react error overlay
- [x] builds middleware successfully, shows build warning, shows desired error on stderr on call
- [x] builds route successfully, shows build warning, shows desired error on stderr on call
### 3rd party modules not found
```js
// middleware.js
import { NextResponse } from 'next/server'
// static
import Unknown from 'unknown'
export default async function middleware() {
// dynamic
const Unknown = await import('unknown')
new Unknown()
return NextResponse.next()
}
```
export const config = { matcher: '/' }
```
```js
// pags/api/route.js
// static
import Unknown from 'unknown'
export default async function handle() {
// dynamic
const Unknown = await import('unknown')
return Response.json({ use3rdPartyModule: Unknown() })
}
export const config = { runtime: 'experimental-edge' }
```
Desired error (+ source code highlight in dev):
> Module not found: Can't resolve 'does-not-exist'
Learn More: https://nextjs.org/docs/messages/module-not-found
- [x] in dev middleware, static, shows desired error on stderr
- [x] in dev route, static, shows desired error on stderr
- [x] in dev middleware, dynamic, shows desired error on stderr
- [x] in dev route, dynamic, shows desired error on stderr
- [x] in dev middleware, static, shows desired error on react error overlay
- [x] in dev route, static, shows desired error on react error overlay
- [x] in dev middleware, dynamic, shows desired error on react error overlay
- [x] in dev route, dynamic, shows desired error on react error overlay
- [x] fails to build middleware, with desired error on stderr
- [x] fails to build route, with desired error on stderr
### unused node.js modules
```js
// middleware.js
import { NextResponse } from 'next/server'
export default async function middleware() {
if (process.exit) {
const { basename } = await import('path')
basename()
}
return NextResponse.next()
}
```
```js
// pags/api/route.js
export default async function handle() {
if (process.exit) {
const { basename } = await import('path')
basename()
}
return Response.json({ useNodeModule: false })
}
export const config = { runtime: 'experimental-edge' }
```
Desired warning at build time:
> A Node.js module is loaded ('path' at line 2) which is not supported in the Edge Runtime.
Learn More: https://nextjs.org/docs/messages/node-module-in-edge-runtime
- [x] invoke middleware in dev with no error
- [x] invoke route in dev with no error
- [x] builds successfully, shows build warning, invoke middleware with no error
- [x] builds successfully, shows build warning, invoke api-route with no error
## Notes to reviewers
The strategy to implement this feature is to leverages webpack [externals](https://webpack.js.org/configuration/externals/#externals) and run a global `__unsupported_module()` function when using a node.js module from edge function's code.
For the record, I tried using [webpack resolve.fallback](https://webpack.js.org/configuration/resolve/#resolvefallback) and [Webpack.IgnorePlugin](https://webpack.js.org/plugins/ignore-plugin/) but they do not allow throwing proper errors at runtime that would contain the loaded module name for reporting.
`__unsupported_module()` is defined in `EdgeRuntime`, and returns a proxy that's throw on use (whether it's property access, function call, new operator... synchronous & promise-based styles).
However there's an issue with error reporting: webpack does not includes the import lines in the generated sourcemaps, preventing from displaying useful errors.
I extended our middleware-plugin to supplement the sourcemaps (when analyzing edge function code, it saves which module is imported from which file, together with line/column/source)
The react-dev-overlay was adapted to look for this additional information when the caught error relates to modules, instead of looking at sourcemaps.
I removed the previous mechanism (built by @nkzawa ) which caught webpack errors at built time to change the displayed error message (files `next/build/index.js`, `next/build/utils.ts` and `wellknown-errors-plugin`)
Client components might result in a page chunk or a standalone splitted chunk marked in flight manifest, this PR filters out the page chunk for standalone chunk so that while loading a client chunk (like for `next/link`) it won't load the page chunk to break the hydration. `chunk.ids` is not enough for getting required chunks, so we get the chunks from chunk group then filter the required ones.
tests: Re-enable few previous rsc tests
chore: refactor few webpack api usage
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
trying to shorten the svg blur placeholder on `next/future/image`:
- is the `xlink` namespace needed?
- are self-closing tags allowed?
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR corrects a mistake where a negative number could pass, as a number greater than 0.
This is due to negative numbers being a truthy value in JS.
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Previously we use custom webpack alias for specific react versions for non server side node runtime aliases. This PR alias the entire folders of `react/` and `react-dom/` so that no more alias in next.config is required but only the nodejs require hook.
* Alias `react` and `react-dom` by default
* Use `react@experimental` to run server components integration test
* Drop with-react-17 test util, add `__NEXT_REACT_CHANNEL` as an env var for testing and development to specify the react channel is 17 or new experimental version
* Requires prerequisite PR https://github.com/vercel/next-telemetry/pull/84
This PR adds telemetry to send list of the experimental swc plugins from next.config.js. Implementation largely mimics existing plugins telemetry for next_package (https://github.com/vercel/next.js/blob/canary/packages/next/telemetry/events/plugins.ts), with small modification to read swc plugin package instead.
One notable difference is swc plugin telemetry can be sent without version. This is due to swc plugins can be specified with absolute path without any npm pkg resolutions.
## 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.
- [ ] 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR amends behavior of swc's cache by setting it explicitly under `distDir` from next.js config.
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR fixes the case when `next/future/image` is missing the width or height props.
It also fixes a case when `100%` or `100vh` were incorrectly parsed as `100` pixels.
We don't need to include `<noscript>` for `next/future/image` since it uses native lazy loading instead of the `IntersectionObserver` (https://github.com/vercel/next.js/pull/37927).
The only case when we still need `<noscript>` is for `placeholder="blur"` because it requires client-side JS to switch the from blur image to final image on load.
Fixes https://github.com/vercel/next.js/issues/37741. Allows `next/script` to be placed inside of `_document` body in addition to `Head`.
## Bug
- [X] Related issues linked using `fixes #number`
- [X] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes#37981.
When handling the legacy link behavior on the current version of Next.js, it only wraps single string child in `<a>` tag. The PR fixes the issue by also wrap single number child in `<a>` tag, too.
This PR fixes flaky `onLoad()` test for `next/image/future`.
The test must modify the `src` after hydration to make sure it always works as expected.
This is because `next/image/future` uses native lazy loading and sometimes the event fires before hydration (docs were updated to mention this)
* Refactor `runDependingOnPageType`
* Throw specific error when the compiled middleware cannot be found
* Do not render `MiddlewareNotFoundError` on dev
* Allow to invalidate compilers by type
* Show compile errors when middleware fails to build
* Add tests
This PR introduces a new experimental component, `next/future/image`, which is inspired by the existing experimental `layout="raw"`.
The difference is that much of the code has been deleted in order to reduce client-side code as well as reduce complexity:
- No `layout` prop
- No `loader` config (although `loader` prop works)
- No `IntersectionObserver`, use native `loading="lazy"`
- No `lazyBoundary`
- No `lazyRoot`
- No `fill` (yet) so width & height are required
- No `objectFit` (use `style` instead)
- No `objectPosition` (use `style` instead)
This improves performance because native `loading="lazy"` doesn't need to wait for React Hydration and client-side JS.
In a future PR, we will modify `next/image` to remove `layout="raw"` since this new component supersedes it.
## Feature
- [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`
Previously our CLI assumed that when using an `--example` flag, the example contains a `package.json` file. There are examples though, like `with-docker-compose` which does not have one. In that case, we can simply clone the directory and show a success message.
<details>
<summary>
Full list of examples without <code>package.json</code>:
</summary>
<ul>
<li>custom-server</li>
<li>page-transitions</li>
<li>parameterized-routing</li>
<li>reproduction-template</li>
<li>with-chakra-ui-typescript</li>
<li>with-cookie-auth</li>
<li>with-docker-compose</li>
<li>with-dotenv</li>
<li>with-facebook-chat-plugin</li>
<li>with-firebase-authentication</li>
<li>with-firebase-authentication-serverless</li>
<li>with-glamorous</li>
<li>with-global-stylesheet</li>
<li>with-global-stylesheet-simple</li>
<li>with-graphql-faunadb</li>
<li>with-markdown</li>
<li>with-material-ui</li>
<li>with-next-auth</li>
<li>with-next-i18next</li>
<li>with-next-multilingual</li>
<li>with-next-routes</li>
<li>with-now-env</li>
<li>with-pretty-url-routing</li>
<li>with-prisma</li>
<li>with-redux-toolkit</li>
<li>with-redux-toolkit-typescript</li>
<li>with-sentry-simple</li>
<li>with-strict-csp-hash</li>
<li>with-styled-jsx-postcss</li>
<li>with-sw-precache</li>
<li>with-typescript-styled-components</li>
<li>with-universal-configuration-build-time</li>
<li>with-universal-configuration-runtime</li>
</ul>
</details>
Fixes#37884
In a follow-up PR, we can try to detect if an example contains a README.md file only, and if the example was moved, we could either try getting it from the new location or at least show a better message. (Eg.: using a magic comment that we can parse)
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
- Always perform a full reload when needed without blocking with the overlay.
- Old client warnings re-added.
- Post client warning to dev server and print it in the CLI.
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
x-ref: #31506
This PR migrates existing SSR on edge from middleware to edge functions implmentation. So that we can get rid of limitation of middleware and resolve the conflicts between middleware and edge SSR routes.
* Adding edge functions matching route in middleware catch all route,keep the order as `middleware catch all` -> redirects/rewrites -> `edge catch all` -> others
* Dropping middleware related code for edge SSR: removing client info and preflight request handling
As noticed in https://github.com/vercel/next.js/pull/37596 it seems we aren't locking the `next-server` tracing to the tracing root which can allow files outside of the folder to be included unexpectedly.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This ensures we properly detect `pnpm` when installing missing dependencies. This also adds test coverage to ensure we properly detect the correct package manager.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
x-ref: [slack thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1655568091661719)
If you end up in a state where an error happened and you also should be warned about a full refresh - you get stuck. The full refresh is blocked by the warning but the error is shown instead.
Tests didn't catch this because the refresh warning never showed in `__NEXT_TEST_MODE`.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
<!--
Thanks for opening a PR! Your contribution is much appreciated.
In order to make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below.
Choose the right checklist for the change that you're making:
-->
```js
// next.config.js
module.exports = {
experimental: {
legacyBrowsers: false,
sharedPool: true,
newNextLinkBehavior: false
}
}
```
With the current implementation, using the config above will warn the usage of experimental features. However, those are the preset values that are defined in `defaultConfig` which means actually no experimental feature has been enabled at all.
The PR changes to only check if experimental features are actually enabled (have different values than the ones defined in `defaultConfig`).
This PR switches to using an SVG filter for blurring placeholder images, rather than a CSS filter. It's based on the technique described in @cramforce's [blog post](https://www.industrialempathy.com/posts/image-optimizations/#blurry-placeholder).
One change I made to @cramforce's version was to increase the stdDeviation property of the SVG (which controls the gaussian blur strength) from .5 to 50. Smaller values than this tended to look bad, as our technique for generating the blurry placeholder image tends to produce images with sharp contrast between the pixels, which looks bad when blown up unless it's blurred by a substantial amount.
This PR currently only affects the experimental `layout="raw"` but I expect to eventually apply it to all images. CC: @styfle @kara
This PR fixes an issue where we have a middleware that rewrites every single request to the same origin while having `i18n` configured. It would be something like:
```typescript
import { NextResponse } from 'next/server'
export function middleware(req) {
return NextResponse.rewrite(req.nextUrl)
}
```
In this case we are going to be adding always the `locale` at the beginning of the destination since it is a rewrite. This causes static assets to not match and the whole application to break. I believe this is a potential footgun so in this PR we are addressing the issue by removing the locale from pathname for those cases where we check against the filesystem (e.g. public folder).
To achieve this change, this PR introduces some preparation changes and then a refactor of the logic in the server router. After this refactor we are going to be relying on properties that can be defined in the `Route` to decide wether or not we should remove the `basePath`, `locale`, etc instead of checking which _type_ of route it is that we are matching.
Overall this simplifies quite a lot the server router. The way we are testing the mentioned issue is by adding a default rewrite in the rewrite tests middleware.
In a previous PR (#19032), we added a hard error during `next export` if the default Image Optimization API is being used because it requires a server to optimized on demand. The error message offers several different solutions but it didn't consider that by the time someone runs `next export`, they are probably done writing their app.
So if `next export` is a hard requirement, the quickest path forward is to disable Image Optimization API. So this PR adds a new configuration option to `next.config.js`:
```js
module.exports = {
images: {
unoptimized: true
}
}
```
### Update
Upon further discussion, we might want to avoid doing this just for images and instead introduce a top-level config to indicate export is coming and then handle errors or warn for [unsupported features](https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features).
```
module.exports = {
nextExport: true
}
```
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This improves the warning thats printed when you have experimental features enable so its clear which ones are enabled (in parenthesis) and where they are enabled (in next.config.js or next.config.mjs)
## Before
```
warn - You have enabled experimental feature(s).
```
## After
```
warn - You have enabled experimental features (reactRoot, serverComponents, scrollRestoration) in next.config.js.
```
In Middlewares, dynamic code execution is not allowed. Currently, we warn if eval / new Function are invoked in dev but don't warn another dynamic code execution in WebAssembly.
This PR adds warnings for `WebAssembly.compile` and `WebAssembly.instantiate` with a buffer parameter (note that `WebAssembly.instantiate` with a **module** parameter is legit) invocations. Note that other methods that compile WASM dynamically such as `WebAssembly.compileStreaming` are not exposed to users so we don't need to cover them.
## 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`
- [x] Integration tests added
- [x] 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
* Improve stack traces in dev mode
* Refactor `react-dev-overlay` to support the Edge Compiler
* Serialize errors including the compiler `source`
* Adopt the new `react-dev-overlay` displaying it for middleware errors
* Improve tests
* fix rsc cases
* update test
* use check for dev test
* handle different error from node version
Co-authored-by: feugy <damien@vercel.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
* Ensure custom middleware matcher is used correctly in client manifest
* lint-fix
* patch e2e case
* fix rsc case
* update test
* add missing normalize
In a previous PR (#34075), the ISR behavior was introduced to the Image Optimization API, however it changed the cache-control header to always set maxage=0. While this is probably the right behavior (the client shouldn't cache the image), it introduced a regression for users who have CDNs in front of a single Next.js instance (as opposed to [multiple Next.js instances](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration#self-hosting-isr)).
Furthermore, the pros of client-side caching outweight the cons because its easy to change the image url (add querystring param for example) to invalidate the cache.
This PR reverts the cache-control behavior until we can come up with a better long-term solution.
- Fixes#35987
- Related to #19914
- Related to #22319
- Closes#35596
* Re-introduce Edge API Endpoints
This reverts commit 210fa39961, and
re-introduces Edge API endpoints as a possible runtime selection in API
endpoints.
This is done by exporting a `config` object:
```ts
export config = { runtime: 'edge' }
```
Note: `'edge'` will probably change into `'experimental-edge'` to show
that this is experimental and the API might change in the future.
* Support `experimental-edge`, but allow `edge` too
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This ensures we use the correct dynamic route params favoring params from the URL/matched-path over route-matches. This also ensures we properly cache `_next/data` requests client side when the page is not a `getServerSideProps` page.
x-ref: https://github.com/vercel/next.js/pull/37574
## 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 `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
This PR builds on the work from @hattakdev (PR went stale: https://github.com/vercel/next.js/pull/14499) and adds a new `integration` test for the new warning.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
## To run locally
1. `pnpm build`
2. `pnpm testonly test/integration/export-getInitialProps-warn/test/index.test.js`
Fixes#13946
## Notes
<details>
<summary>Click to toggle see</summary>
I know the `contributing.md` doc said to avoid adding new tests to `integration`. It also said new tests should be written in TypeScript.
I wasn't sure where to put the tests for this so I went with `integration`. I also didn't see many other tests written in TS in this part of the codebase so I stuck with `.js`.
</details>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Strip next internal queries in inline flight response
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
* Update to process redirects/rewrites for _next/data
* correct matched-path resolving with middleware
* Add next-data header
* migrate middleware tests
* lint-fix
* update error case
* update test case
* Handle additional resolving cases and add more tests
* update test from merge
* fix test
* rm .only
* apply changes from review
* ensure _next/data resolving does not apply without middleware
This commit enables the following patterns in Middleware:
```ts
// with a dot notation
const { ENV_VAR, "ENV-VAR": myEnvVar } = process.env;
// or with an object access
const { ENV_VAR2, "ENV-VAR2": myEnvVar2 } = process["env"];
```
### Related
- @cramforce asked this fixed here: https://github.com/vercel/next.js/pull/37514#discussion_r892437257
## 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`
* 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>
## Bug
fixes#37106
Please note that, as for `pages/` the `src/middleware` file is ignored when `/middleware` is present.
## How to test
1. Rebuild next.js `pnpm build`
2. Run dedicated tests: `pnpm testheadless --testPathPattern middleware-src/`
* rewrite head side effects component in hooks
* remove mapping from element to children in head manager since they're already the children of `<Head>`
When move `SideEffect` to hooks, the effects scheduling is earlier than life cycle. We're leverage layout effects and effects at the same time, always cache the latest head updating function in head manager in layout effects, and flush them in the effects. This could help get rid of the promises delaying approach in head manager.
Co-authored-by: Shu Ding <3676859+shuding@users.noreply.github.com>
This commit lets users measure their Interaction to Next Paint [INP](https://web.dev/inp/) web vital.
Note that the `web-vitals` package is beta to denote that INP is an experimental metric, the code is stable and v3 is backwards compatible.
`web-vitals` CHANGELOG for v3:
- [BREAKING] Report TTFB after a bfcache restore
- [BREAKING] Only include last LCP entry in metric entries
- Add support for the new INP metric
- Rename getXXX() functions to onXXX()
- Add a navigationType property to the Metric object
See https://github.com/GoogleChrome/web-vitals/blob/next/CHANGELOG.md
Upgraded `playwright-chromium` from `1.14.1` to `1.17.2` because the Events Timing API used to measure INP is only available in Chromium >= v98.
## 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`
## Bug
- [X] Related issues linked using `fixes #37483`
- [ ] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Duplicate locales will lead to an obscure error message at build time, here I caught them earlier.
Using a Set sounded the terser and fastest approach, but it won't tell which locale is duplicated.
Also I've noticed that the "Array.isArray" check happens twice on i18n.locales? Maybe it's on purpose?
Fixes#37483
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
* test: upgrade playwright-chromium from 1.14.1 to 1.22.2
This is a prereq for #36490 because the Events Timing API
used to measure Interaction to Next Paint (INP, experiemental web vital)
is only available in Chromium >= v98.
* update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## 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
This PR introduces [Edge Runtime](https://edge-runtime.vercel.app/) for emulating [Edge Functions](https://vercel.com/features/edge-functions) locally.
Every time you run a [middleware](https://nextjs.org/docs/advanced-features/middleware) locally via `next dev`, an isolated edge runtime context will be created.
These contexts have the same constraints as production servers, plus they don't pollute the global scope; Instead, all the code run in a vm on top of a Node.js process.
Additionally, `@edge-runtime/jest-environment` has been added to make easier testing Edge Functions in a programmatic way.
It dropped the following polyfills from Next.js codebase, since they are now part of Edge Runtime:
- abort-controller
- formdata
- uuid
- web-crypto
- web-streams
Co-authored-by: Gal Schlezinger <2054772+Schniz@users.noreply.github.com>
When using `next/dynamic` with `suspense: true`, the API will opt into `React.lazy` with react 18. But previously it doesn't preload the dynamic chunks. This pr will include the chunks into initial html for faster hydration instead of loading the chunk until the script is executed. This makes `next/dynamic` has a significant difference from `React.lazy` api
x-ref: https://github.com/vercel/next.js/issues/37197#issuecomment-1138496911
x-ref: https://github.com/vercel/next.js/pull/37244
* Do not exclude internal _next request in middleware
* Allow for `NextURL` to parse prefetch requests
* Add test for middleware data prefetch
* Refactor `hasBasePath` and `replaceBasePath`
* Refactor `removeTrailingSlash`
* Refactor parsed next url to use `getNextPathnameInfo`
* Allow to configure `NextURL`
* Ensure middleware rewrites with always with a locale
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
The PR fixes#37122, an issue introduced by #37105.
`next.config.js` might/will include functions (custom `webpack`, `generateBuildId`, `exportPathsMap`, etc.) that are not able to pass from the main thread to a worker. The PR fixes the issue by only passing primitive args to the worker.
* Merge multiple log statements
It is inefficient to use multiple console.log satements, and if something is logged to the console in the middle of execution, it will be in the center of the text, making it hard to read.
This pull request merges multiple console.logs into one.
In addition, it reduces the bundle size.
* ensure formatting matches
* update test
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes#36823Closes#33084
The issue is caused by the `isLocalURL` function only checks if a URL starts with `/`, `#` or `?`. So a URL that starts with `.` will not be considered a "local URL". The PR fixes that by introducing a new util function `isAbsoluteUrl` that is fully compliant with [RFC3986](https://tools.ietf.org/html/rfc3986#section-4.3).
This PR removes the not-very-helpful stack trace when sass is being used but the npm package is not installed. Fixes#13975
- Fix behavior to show the modified error message if either node-sass OR sass is missing
- dispose of stack trace if the condition above passes
- update the error link to [err.sh](https://err.sh/next.js/install-sass) equivalent
- update the relevant test to verify the stack trace is omitted and to account for the new link
## Bug
- [x] Related issues linked using `fixes #13975`
- [ ] 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: JJ Kasper <22380829+ijjk@users.noreply.github.com>
fixes#11109
## Bug
- [x] 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`
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
_Hello Next.js team! First PR here, I hope I've followed the right practices._
### What's in there?
It has been decided to only support the following uses cases in Next.js' middleware:
- rewrite the URL (`x-middleware-rewrite` response header)
- redirect to another URL (`Location` response header)
- pass on to the next piece in the request pipeline (`x-middleware-next` response header)
1. during development, a warning on console tells developers when they are returning a response (either with `Response` or `NextResponse`).
2. at build time, this warning becomes an error.
3. at run time, returning a response body will trigger a 500 HTTP error with a JSON payload containing the detailed error.
All returned/thrown errors contain a link to the documentation.
This is a breaking feature compared to the _beta_ middleware implementation, and also removes `NextResponse.json()` which makes no sense any more.
### How to try it?
- runtime behavior: `HEADLESS=true yarn jest test/integration/middleware/core`
- build behavior : `yarn jest test/integration/middleware/build-errors`
- development behavior: `HEADLESS=true yarn jest test/development/middleware-warnings`
### Notes to reviewers
The limitation happens in next's web adapter. ~The initial implementation was to check `response.body` existence, but it turns out [`Response.redirect()`](https://github.com/vercel/next.js/blob/canary/packages/next/server/web/spec-compliant/response.ts#L42-L53) may set the response body (https://github.com/vercel/next.js/pull/31886). Hence why the proposed implementation specifically looks at response headers.~
`Response.redirect()` and `NextResponse.redirect()` do not need to include the final location in their body: it is handled by next server https://github.com/vercel/next.js/blob/canary/packages/next/server/next-server.ts#L1142
Because this is a breaking change, I had to adjust several tests cases, previously returning JSON/stream/text bodies. When relevant, these middlewares are returning data using response headers.
About DevEx: relying on AST analysis to detect forbidden use cases is not as good as running the code.
Such cases are easy to detect:
```js
new Response('a text value')
new Response(JSON.stringify({ /* whatever */ })
```
But these are false-positive cases:
```js
function returnNull() { return null }
new Response(returnNull())
function doesNothing() {}
new Response(doesNothing())
```
However, I see no good reasons to let users ship middleware such as the one above, hence why the build will fail, even if _technically speaking_, they are not setting the response body.
## 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
- [x] 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
- [x] Make sure the linting passes by running `yarn lint`
This fixes the test when a publish is done, seems it's been passing for a while by using the wasm fallback instead but this fails on a publish since the current version being published isn't available until after the test runs
x-ref: https://github.com/vercel/next.js/runs/6512721965?check_suite_focus=true
BeforeInteractive inline script in v12.1.7-canary.8 don't run. Beacause the script has unknow src.
Fixes https://github.com/vercel/next.js/issues/31275
## 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 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.
This PR changes the experimental `layout=raw` images to use the native lazy loading behavior (as opposed to the IntersectionObserver).
This will (eventually) lead to smaller client bundles and faster image loading since there is no JS needed to load the image.
However, we'll lose the `lazyRoot` and `lazyBoundary` behavior since those are specific to the IntersectionObserver implementation.
Applies additional escaping to flight data written to script tags during RSC. A test was added. I'm not aware of any issues reported for this and there are no new errors
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
* remove the experimental web vital hook api
* remove the exported flush effects api and only error on development, keep only usage to styled-jsx
for web vital hook API: The usage is not widly adopted since the existing exported vital api could do the same work. In the future we'll deprecate the `_app.server` in favor of `_app` in server component pages. so that this api won't be required.
for flush effects api: other css-in-js libs are not using the same approach like styled-jsx which holding a style registry and could flush it during streaming. emotion-js and styled-components are still relying on `Document.getInitialProps` atm and we have supported it in latest canary
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
The PR fixes#30300 and #36855.
The corresponding integration test case has been added.
Clean up integration tests
* app-document: Merge multi fetch reuqests into 1, add checking for `__NEXT_DATA__`
* rsc/streaming: Merge duplicated tests, move the head tests to client-navigation since they're running under react 18 now
* remove runtime subtest suite under rsc tests since it's covered in switchable runtime test suite
Follow up for #35888 to re-enable more test, and re-enable post processors after #36792 has better support for document.gIP with react 18. Apply post-pocessing when the the shell chunk is fully buffered.
re-enabled integration tests for react 18:
- amphtml
- amphtml-custom-optimizer
- app-document
- font-optimization
Fixes#35835
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
The PR fixes#30300.
The previous integration test case only checks if `/out/404.html` exists. However, the test passes since `/out/404.html/index.html` is being exported instead.
The PR changes that by checking if a given path exists and is a file.
Stack trace disappears when error is converted to string.
I changed the types in `log.ts` to match `console.log`/`console.error`/`console.warn`.
fixes#31591
When getInitialProps is customized with react 18, since gIP requires to return `html` as doc property which could be used by user-land customization, we do blocking-rendering there and passdown the `html` to document
Fixes#36675Closes#36419
This PR introduces a more predictable API to manipulate cookies in an Edge Function context.
```js
const response = new NextResponse()
// set a cookie
response.cookies.set('foo, 'bar') // => set-cookie: 'foo=bar; Path=/'`
// set another cookie
response.cookies.set('fooz, 'barz') // => set-cookie: 'foo=bar; Path=/, fooz=barz; Path=/'`
// delete a cookie means mark it as expired
response.cookies.delete('foo') // => set-cookie: 'foo=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT, fooz=barz; Path=/'`
// clear all cookies means mark all of them as expired
response.cookies.clear() // => set-cookie: 'fooz=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT, foo=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT'`
```
This new cookies API uses [Map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map) interface, and it's available for `NextRequest` and `NextResponse`.
Additionally, you can pass a specific cookies option as a third argument in `set` method:
```js
response.cookies.set('foo', 'bar', {
path: '/',
maxAge: 60 * 60 * 24 * 7,
httpOnly: true,
sameSite: 'strict',
domain: 'example.com'
}
```
**Note**: `maxAge` it's in seconds rather than milliseconds.
Any cookie manipulation will be reflected over the `set-cookie` header, transparently.
closes#31719
Fixes#36659
`App` is alreay included in `ServerComponentWrapper`
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## 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
Fixes#36643
## Bug
* hoist react dom choosing in client
* also assign __NEXT_REACT_ROOT env in custom server
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
* Use flushed effects to generate styled-jsx styles insted of gIP by default
* ensure styles are flushed inside the default getInitialProps
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Shu Ding <g@shud.in>
- 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`
This updates to show a 400 (bad request) when an invalid path is sent to Next.js similar to our decode failure handling.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Closes: https://github.com/vercel/next.js/issues/36555
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
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 PR makes the following changes:
* Always add the `height` and `width` prop to image with `raw` layout (previously only added to images without `sizes`)
* Add a warning if a raw layout image is getting stretched (which can be caused by interaction of height and width prop with styles)
* Remove automatic aspect-ratio style from `raw` images. This is no longer necessary if all `raw` images have height and width props.
* Update tests and docs accordingly
