add `experimental.esmExternals: boolean | 'loose'` config option
remove `output.environment` configuration in favor of `target`
| | `esmExternals: false` (default) | `esmExternals: 'loose'` | `esmExternals: true` |
| ------------------------ | ------------------------------- | ----------------------- | -------------------- |
| import cjs package | `require()` | `require()` | `require()` |
| require cjs package | `require()` | `require()` | `require()` |
| import mixed package | `require()` *** | `import()` | `import()` |
| require mixed package | `require()` | `require()` | `require()` |
| import pure esm package | `import()` | `import()` | `import()` |
| require pure esm package | Error ** | `import()` * | Error ** |
| import pure cjs package | `require()` | `require()` | Resolving error |
| require pure cjs package | `require()` | `require()` | `require()` |
cjs package: Offers only CJS implementation (may not even have an `exports` field)
mixed package: Offers CJS and ESM implementation via `exports` field
pure esm package: Only offers an ESM implementation (may not even have an `exports` field)
pure cjs package: CommonJs package that prevents importing via `exports` field when `import` is used.
`*` This case will behave a bit unexpected for now, since `require` will return a Promise. So that need to be awaited. This will be fixed once the whole next.js bundle is ESM. It didn't work at all before this PR.
`**` This is a new Error when trying to require an esm package.
`***` For mixed packages we prefer the CommonJS variant to avoid a breaking change.
## Feature
- [ ] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [x] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes
### Description
The redirect responses from the redirect function do not contain a message body. This is in conflict with the RFCs below and causes Traefik (a reverse proxy) to invalidate the responses. In this pull request, I add a response body to the redirect responses.
### References
- https://datatracker.ietf.org/doc/html/rfc7230#section-3.3
> All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses must not include a message-body. All other responses do include a message-body, although the body may be of zero length.
- https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.3
> The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).
- traefik/traefik#4456
- https://github.com/auth0/nextjs-auth0/pull/399
Since we are no longer accepting new built-in loaders, users may wish to use a different cloud provider.
So this PR renames `dangerously-unoptimized` to `custom` to handle this case as well as the intention of `next export`.
If the user doesn't add a `loader` prop, we throw an error.
If the user adds a `loader` prop but it doesn't return the width, we print a warning.
- Follow up to #26847
- Fixes#21079
- Fixes#19612
- Related to #26850
Improve typing for use with Typescript example
<!--
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:
## 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
- [X] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [X] Make sure the linting passes
I think the issue was due to ```nextjs-auth0``` package on version ```0.8.0```. Upgrading to latest version ```1.4.2``` resolve the issue.
## Bug
- [x] Related issues linked using `fixes` https://github.com/vercel/next.js/issues/19313
### Description
This changes the strict TS types to a looser implementation such that the user can pass `src` without TS errors.
### Pros vs Cons
- **Pros**: better support for wrapping `next/image` so that TS won't report false errors
- **Cons**: using `src: string` without `blurDataURL` will no longer show TS errors and instead fail with a runtime error
### Issues
- Fixes#26892
- Related to #26991
My last PR (#26205) made the hash change events not fire when in i18n was enabled, as seen in #26853. This PR fixes that and adds a test for this case.
fixes#26853
## 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
### Description
This changes the strict TS types to a looser implementation such that the user can always pass `width` and `height` (even when `layout=fill`) without TS errors.
### Pros vs Cons
- **Pros**: better support for wrapping `next/image` so that TS won't report false errors with `layout=fill`
- **Cons**: omitting width/height when using other `layout` will no longer show TS errors and instead fail with a runtime error
### Issues
- Fixes#26531
- Fixes#25440
fixes#19074
This change disables image lazy-loading when both of the following are true:
1) A image is being rendered following a client-side page transition
2) The image has been previously loaded during this session.
Before this change, all images with lazy-loading enabled have a visible flicker during client-side page transitions, even though they're already loaded.
With this change, there's are two performance risks:
1) There's a chance that some offscreen images will have lazy-loading disabled unnecessarily because they were previously loaded. I think the performance hit here is pretty negligible and the situation is unlikely to come up very often.
2) There's a chance a different-sized version of the image will be selected by the browser, but lazy-loading will be disabled anyway. This seems even more unlikely to me, and anyway the performance hit from a stray un-lazy-loaded image (on a client-side transition) is very minor.
In both cases, I think the performance risk is outweighed by the UX improvement of getting rid of the image flicker on page transition.
This will ensure `next/script` follows the same naming convention as `next/image`. For example:
```js
import Image, { ImageProps } from 'next/image'
import Script, { ScriptProps } from 'next/script'
```
Fixes#26290
If the `Image` src url had existing query params, the imgix loader would simply append another query string with `?` causing both query strings to break.
This PR adds a way to safely merge query strings if needed using [URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams).
## Bug
- [X] fixes#26288
- [X] Integration tests added
Make the typing for `IncrementalCache` more explicit. With streaming, we’ll want to stream page data as well as HTML. This is a bit complicated now because we’re overloading `pageData` for both redirects and pages.
This PR makes the different types explicit. With streaming, the data for redirects is synchronously available, while the data for pages will become a stream.
A follow up PR will add a “stream through” cache in front of `IncrementalCache`
Refactors the internals of `next-server` to use `ResponsePayload` instead of `string | null` and manual `sendPayload` calls. This is the first step toward streaming support.
I split `renderToResponseWithComponents` into a separate `renderToResponseWithComponentsInternal` function for ease of review: GitHub's diff rendering was highly misleading, making it seem as though more of the function had changed. The separate function just makes the actual change clearer: we split `renderToHTMLWithComponents` into two promises; one that represents the actual render result, and one that represents all of the work (including background work for e.g. revalidation) that needs to be done as part of generating the result.
These changes make it easier to bubble up a `ResponsePayload`, instead of sometimes calling `sendPayload` out-of-band, centralizing all payload handling in `sendResponse` and eventually a similar function for public APIs that return a string. This centralization will make it much easier to handle a response that needs to be streamed, which is coming soon in another PR.
Previous TypeScript template in `create-next-app` only had the following in `next-env.d.ts`
```ts
/// <reference types="next" />
/// <reference types="next/types/global" />
```
New `next-env.d.ts` has this:
```ts
/// <reference types="next" />
/// <reference types="next/types/global" />
/// <reference types="next/image-types/global" />
```
Next.js automatically adds the `image-types` reference, but it won't be included in the initial commit.
## Documentation / Examples
- [x] Make sure the linting passes
This decreases the body size limit that triggers a warning from 5MB -> 4MB, which provides a little more wiggle room. Certain things like using base64 on body, headers, path, etc can cause the response to be larger than initially calculated.
Initial PR: https://github.com/vercel/next.js/pull/26831
This ensures when an error occurs in an API route while using minimal mode the error is bubbled so it can be handled at the top-level
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
This fixes the React warning: `Warning: Each child in a list should have a unique "key" prop.` that is thrown when using the `Script` components with the `beforeInteractive` strategy.
Fixes: #26618
This PR adds a warning when api responses exceed 5mb since this will end up failing once deployed. In a future version this scenario will throw an error.
## Bug
- [x] Integration tests added
## Documentation / Examples
- [x] Make sure the linting passes
fixes#26607
This change makes it so the image loader plugin only emits a file while processing an image import for the client. The final generated image URL was already the same in SSR and CSR anyway, so this change doesn't have any functional impact.
I also changed the name of the static page in the image component tests, since it was causing some conflicts with the static assets folder.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
## 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
- [x] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
## Documentation / Examples
- [ ] Make sure the linting passes
## Why the change
I lost quite a few hours figuring out why my environment variable was `undefined` in the browser.
I read about the built-in support and was like: "Oh nice" and didn't read much further. I missed the part about how you need to prefix your variables with `NEXT_PUBLIC_` in order to expose them to the browser.
I think a hint to this in the anchor link to that section will make it more discoverable as it's then mentioned near the top and will save people who are like me some time and a headache.