I think the `EEXIST` error may be because next already copies some files here
e91cbcc03d/packages/next/build/index.ts (L2442)
partially fixes#36386 when using pnpm linker
## Bug
- [x] Related issues linked using
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes#40133
Fixes a small regression introduced in #39872. We should be able to detect if a non-empty `package.json#eslintConfig` property is present.
## 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)
The PR fixes#40066.
Next.js' `serveStatic` method is powered by the [send](https://github.com/pillarjs/send) module, which could throw errors under specific circumstances.
Currently, Next.js only preserves the 412 Error from send, hence issue #40066 (where 416 Error is not preserved).
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This PR updates a few features from experimental to stable status:
- `next/future/image` component
- `remotePatterns` configuration
- `unoptimized` configuration
This addresses a bug where invoking `next dev` or `next start` with `--port 0` would fall back to the default port of 3000 instead of binding to port 0 (which typically results in the operating system assigning a free port).
I couldn't find a straightforward way of adding a test for next-start. It looks like we could add a similar test as for dev, but would need to generate a built project to serve.
Manual test plan for `next start`:
```
$ ./packages/next/dist/bin/next start --port 0
ready - started server on 0.0.0.0:53508, url: http://localhost:53508
```
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] 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 <steven@ceriously.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Wyatt Johnson <accounts+github@wyattjoh.ca>
This `alt` attribute is required by `<img>` according to the HTML spec, so we should also make it required for `next/future/image`. In the cases where it is not needed, it can be set to the empty string.
https://html.spec.whatwg.org/multipage/images.html#alt
## Feature
As the title, support `has` match, `local` that works the same with the `rewrites` and `redirects` of next.config.js on middleware config. With this PR, you can write the config like the following:
```js
export const config = {
matcher: [
"/foo",
{ source: "/bar" },
{
source: "/baz",
has: [
{
type: 'header',
key: 'x-my-header',
value: 'my-value',
}
]
},
{
source: "/en/asdf",
locale: false,
},
]
}
```
Also, fixes https://github.com/vercel/next.js/issues/39428
related https://github.com/vercel/edge-functions/issues/178, https://github.com/vercel/edge-functions/issues/179
- [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`
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Follow up for #39953
Detect invalid gSSP/gSP exports in page or layout client components in build time instead of checking them in runtime, in this way we can:
* Error to user eariler with traced file path, help user find the incorrect usage easier
* Make the flight client loader simpler, headless, aligned with react
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Follow-up to https://github.com/vercel/next.js/pull/40076 this ensures we handle rendering correctly when the URL doesn't match the edge function exactly e.g. when rewriting since it looks like we don't currently have access to the `x-matched-path` header like we do for serverless functions.
## Bug
- [ ] 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/runs/8102187444?check_suite_focus=true
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This updates to handle detecting `getStaticProps`/`getServerSideProps` correctly during build when `experimental-edge` is being used. This also fixes not parsing dynamic route params correctly with the edge runtime and sets up the handling needed for the static generation for app opened in the below mentioned PR.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Fixes: [slack thread](https://vercel.slack.com/archives/C0289CGVAR2/p1661554455121189)
x-ref: https://github.com/vercel/next.js/pull/39884
<!--
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:
-->
This is intended to refactor the router code to reduce the overhead of executing routes. This is related to #32314 that may help reduce the memory overhead as this also replaced the `Set` with a `WeakMap`.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Currently when the resolved path is `undefined` it generates `filePath: 'undefined'` in the tree object, but should be `filePath: undefined` instead.
## 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 `<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
### Problem
esm modules imports from client components will be compiled to `m = import('module-name')` when webpack bundles them for server components flight rendering. In this case, they will all become async modules since dyanmic imports will return a promise which react flight cannot handle it then results into module resolving error on server flight rendering.
### Solution
* React flight renderer supports handling async modules in https://github.com/facebook/react/pull/25138
* On next.js side leverage the module proxy change for each client reference, to make sure it always resolve the correct client module
The idea is wrapping each module with a module proxy, and if the module is async and accessed as thenable, it will return a new module reference with `async` label to tell react to handle it as async modules:
exported client reference `*` --> not async module (non thenable) --> original module reference `''`
exported client reference `*` --> it's async module (thenable) --> wrapped module reference `'*'` with `async` label
### Note
Since we need to check if user having incorrect gSSP/gSP specifying in layout client componet, so we still need to parse it and assign those info to the proxy (Does client module containing `ssr`, `ssg` exports). Otherwise the proxy will return the cached module reference
We only use `if (child.type === Script)` on the server side to check the
element type, that's unnecessary because we can add a special flag for
that (`__nextScript` in this PR).
This reduces the server bundle by ~13kb if `next/script` is not imported
by the user.
## 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)
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`
For historical reasons, Next.js has been falling back to polyfill certain Node.js APIs in the browser. `webpack` itself stopped doing it, and so should Next.js. This might unexpectedly break some packages in the ecosystem though, so it is being introduced as an experimental flag. These imports will now throw a `Module not found` error and the package maintainer should make sure that the library isn't relying on these Node.js APIs when the package is meant for browser usage.
Let's take a look at a common example, the `crypto` API, which can be imported as `import crypto from "crypto"` but [should already be available in browsers](https://caniuse.com/cryptography). Until now, Next.js has fallen back to use a polyfilled version for the import, which resulted in a bundle-size increase.
```js
import crypto from 'crypto'
import { useEffect } from 'react'
export default function Page() {
useEffect(() => {
console.log(crypto)
}, [])
}
```
it imports `crypto`, which currently resolves to [`crypto-browserify`](https://www.npmjs.com/package/crypto-browserify).
So the bundle will include `crypto-browserify` as well:
```sh
Page Size First Load JS
┌ ○ / 131 kB 213 kB # <--
└ ○ /404 194 B 82.2 kB
+ First Load JS shared by all 82 kB
├ chunks/framework-bcc2dc0ea27ab0c6.js 45.1 kB
├ chunks/main-dc2421aef72299b4.js 35.4 kB
├ chunks/pages/_app-a85935458980c5c2.js 708 B
└ chunks/webpack-9b312e20a4e32339.js 836 B
```
Here, we can just remove the import, as we are [safely accessing](https://nextjs.org/docs/migrating/from-create-react-app#safely-accessing-web-apis) the [Crypto Web API](https://caniuse.com/cryptography):
```diff
- import crypto from 'crypto'
import { useEffect } from 'react'
export default function Page() {
useEffect(() => {
console.log(crypto)
}, [])
}
```
Which will reduce the bundle size:
```sh
Page Size First Load JS
┌ ○ / 269 B 82.2 kB # <--
└ ○ /404 194 B 82.1 kB
+ First Load JS shared by all 81.9 kB
├ chunks/framework-bcc2dc0ea27ab0c6.js 45.1 kB
├ chunks/main-dc2421aef72299b4.js 35.4 kB
├ chunks/pages/_app-a85935458980c5c2.js 708 B
└ chunks/webpack-fd82975a6094609f.js 727 B
```
This is harder to detect if the `crypto` import is in a third-party package though. By setting `experimental: { fallbackNodePolyfills: false }`, Next.js will now fail at build-time and should show where the unnecessary import comes from, so the developer can reach out to the package maintainer to fix this issue.
Note: There might be differences between the living standard and some of these older polyfills, so you have to make sure your code works well without the polyfilled version.
Related feedback: https://twitter.com/lfredolo/status/1539608666026000384
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.
Hello, this PR simply configures the `next/mdx` package to use `{ providerImportSource: '@mdx-js/react' }` by default. This is now [required in version 2](https://mdxjs.com/packages/mdx/#optionsproviderimportsource) and causes a lot of confusion personally because `MDXProvider` seems to not work when all is needed is to set this option.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## Bug
Adding a components folder inside a catch-all page triggers the error: "Catch-all must be the last part of the URL", having the component outside works, for example `app/[...slug]/components/*.tsx` fails but `app/components/*.tsx` works as expected.
### Fix
The reason it errors because they're treated as route and inserted into the url node tree where they shouldn't be treated in this way. Adding a helper to skip collecting and normailizing every file as route for app dir, but only do it for page files
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Follow-up to #39758, this PR makes sure that CSS imports (both global and CSS modules) from client components are not handled by mini-css-extract's HMR logic. Instead, we trigger a server component update and let the client to refetch the RSC payload.
However, we are still leveraging the mini-css-extract plugin to emit CSS assets. So in this PR we add a new pitch loader to calculate the original file hash, but replace the final content to eliminate HMR logic but only keep the hash (so hot reloader can keep tracking that).
## 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)
Continuation of https://github.com/vercel/next.js/pull/38817 this adds handling to allow leveraging the `experimental-edge` runtime for `app`.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This ensures we strip the un-necessary `jest-worker` error shown from an error with verifying TypeScript during build as this error just clutters the output and doesn't provide any additional helpful context.
x-ref: [slack thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1661300070830909)
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
Follow-up to https://github.com/vercel/next.js/pull/39872 this fixes a check in `runLintCheck` causing setup to start during build and adds a regression test.
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
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.
<!--
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:
-->
This PR enables a path to loading wasm binding first for the few platforms we'll attempt to remove native binaries. As a first step, this change does not actually removes native bindings, but will try to load wasm binding first and use it if loading success.
It may take some time to actually remove native bindings, I expect we may need to fix few regressions from wasm bindings for some places like loading / installing itself for the platforms not being used widely, meanwhile native bindings can be used as a fallback.
## 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)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
We shouldn't be warning when no eslint config file is present as it's valid not to use eslint. The warning is still shown if an empty eslint config file is added as this gives intent to using eslint.
x-ref: [slack thread](https://vercel.slack.com/archives/CGU8HUTUH/p1661268593890619?thread_ts=1661266342.496699&cid=CGU8HUTUH)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
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`
As noticed in https://github.com/markdoc/markdoc/issues/131 it seems we are incorrectly disposing active entries causing HMR to fail after the configured `maxInactiveAge`. To fix this instead of only updating lastActiveTime for one compiler type's entry we update all active compiler types for the active entry.
This also updates an existing test to catch this by waiting the `maxInactiveAge` before attempting a change that should trigger HMR.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/markdoc/markdoc/issues/131
This removes the usage of `Node12` from the `parsedValues` for `moduleResolution` as this caused false detection of `undefined` being a valid value when it was removed in TypeScript. This also copies over the test from https://github.com/vercel/next.js/pull/37302 to ensure we don't regress on this.
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have helpful link attached, see `contributing.md`
Fixes: https://github.com/vercel/next.js/issues/37296
Closes: https://github.com/vercel/next.js/pull/37302
