Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Before migrating "loadable" the from js to ts, the reload-ready function initialized its "ids" parameter with an empty array. The migration step added the parameter type but removed the initialization.
Providing an empty array as the default value for the ids parameter is necessary; otherwise, the ids variable in the createLoadableComponent function, line 102, gets undefined, and the loading of components fails.
fixes#44695
Previously we were targeting lower versions of Node.js for `app` directory support, but a higher version of Node.js (with support for `AsyncLocalStorage`) was made required to use `undici` instead of `node-fetch`. This PR serves to:
1. Simplify the usage of those storage objects by removing the unnecessary fallback code. Everything now just uses the native `AsyncLocalStorage` interface.
2. Isolates the initialization of each store within it's own bound context to prevent leakage.
3. Adds immutibility flags to variables that should only be initlaized once upon store creation to prevent errors. This actually revealed some bugs in the implementation that were corrected.
In the event that this was in error, the following adapter could be used to simulate the previous beheviour with minor changes to the present implementation ([see this gist](https://gist.github.com/wyattjoh/6f3dffb99a4ac1a8254c90284f05026a)).
[Slack Reference](https://vercel.slack.com/archives/C04DUD7EB1B/p1673030967568029)
## 📖 What's in there?
With Edge Function GA for API Routes, it would make sense to suggest
developer to change their runtime key from `experimental-edge` to
`edge`.
Current behavior is:
1. when using `experimental-edge` in API route:
> prints a warning _once:_ `warn - You are using an experimental edge
runtime, the API might change.`
1. when using `experimental-edge` in pages:
> prints a warning _once:_ `warn - You are using an experimental edge
runtime, the API might change. `
1. when using `edge` in pages:
> throws an error _for each page_: `error - Page /xyz provided runtime
'edge', the edge runtime for rendering is currently experimental. Use
runtime 'experimental-edge' instead.`
This PR adjust case # 1 to indicates which API file is using
`experimental-edge` (a warning per page), and suggest to migrate:
`warn - /pages/api/xyz provided runtime 'experimental-edge'. It can be
updated to 'edge' instead.`
- [x] Integration tests added
## 🧪 How to test?
Besides running e2e tests with `NEXT_TEST_MODE=dev pnpm testheadless
--testPathPattern edge-configurable-runtime`, you can create a test app
in `examples` folder:
```jsx
// examples/edge-warnings/pages/api/edge.js
export default () => new Response('ok')
export const config = { runtime: 'experimental-edge' }
// examples/edge-warnings/pages/index.jsx
export default () => <p>hello world</p>
export const runtime = 'experimental-edge'
```
Build next.js then run with `pnpm next dev examples/edge-warnings`.
You can try adding more pages with `experimental-edge` runtime (will not
produce more warnings), adding more API with `experimental-edge` (will
produce new warnings), or change page runtime to `edge` (will produce
errors).
The initial prefetching implementation was based on the response
returning below the common layout, however when static generation was
added the RSC payload for these changed to only include the router tree
patch and the fully rendered page.
Currently the flow for prefetch is this:
- `router.prefetch`
- Fetch RSC payload
- Dispatch `ACTION_PREFETCH` with RSC payload. Note: the fetch is
intentionally not in the reducer as the fetch happens during an event or
effect, e.g. hover or `useEffect`
- Reducer handles `ACTION_PREFETCH`, creates the router tree, applies
the `subTreeData` to the cache append-only. Saves the new router tree in
the `prefetchCache` part of the reducer state.
- Then, on navigation, the `subTreeData` should be already available so
there's no additional apply. The router state is applied based on the
`prefetchCache`.
This approach is fine when the RSC payload returned never overrides the
`subTreeData` of an already existing node, however that does happen in
case of static pages because the subTreeData is for the root cache node
instead of a deeper node.
The new flow for prefetching:
- `router.prefetch`
- Fetch RSC payload
- Dispatch `ACTION_PREFETCH` with RSC payload
- Reducer handles `ACTION_PREFETCH`, creates the router tree, Saves the
new router tree and `subTreeData` in the `prefetchCache` part of the
reducer state.
- Then, on navigation, the `subTreeData` and router state are applied
based on the `prefetchCache`.
<!--
Thanks for opening a PR! Your contribution is much appreciated.
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/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`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Add aws-crt to server-external-packages
<!--
Thanks for opening a PR! Your contribution is much appreciated.
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:
-->
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/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`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
Co-authored-by: JJ Kasper <jj@jjsweb.site>
When parsing a cookie, extra `=` characters are removed, when only the
first should be removed.
e.g. with the cookie
`csrf_token_ae6261a96213c493a37ea69489ee39c8bc33a53cda7d95f84efa53146145d09c=lnQptRUO/gpU26e8ZKpGIFHKqtP54vVfR7RBiph8Uc0=`
You would expect:
key:
`csrf_token_ae6261a96213c493a37ea69489ee39c8bc33a53cda7d95f84efa53146145d09c`
value: `lnQptRUO/gpU26e8ZKpGIFHKqtP54vVfR7RBiph8Uc0=`
If you use `split`, it will remove the last `=` in value, so you get:
key:
`csrf_token_ae6261a96213c493a37ea69489ee39c8bc33a53cda7d95f84efa53146145d09c`
value: `lnQptRUO/gpU26e8ZKpGIFHKqtP54vVfR7RBiph8Uc0`
This is because `split` still removes all `=` characters, even if you
use the `limit` parameter to limit it to the first 2 elements (as in the
existing code).
Solution is to not use `split` (I've used `slice` instead)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [x] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## 📖 What's in there?
Yesterday we didn't had time to address leftovers from #44045.
Here it is.
- [ ] 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`
- [ ]
[e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
tests added
- [ ] Documentation added (from [PR
43814](https://github.com/vercel/next.js/pull/43814))
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## 🧪 How to test?
Several tests cases added:
- in dev mode, errors and warning: `NEXT_TEST_MODE=dev pnpm testheadless
--testPathPattern edge-configurable-runtime`
- in build mode, build error for pages on the `edge`:
`NEXT_TEST_MODE=start pnpm testheadless --testPathPattern
edge-configurable-runtime`
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This option was initialial added in #8378.
This pr removes `config.experimental.profiling` since this option is no
longer used.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Currently we use `this.appDir + entryName` as the key of app entries. The `appDir` part is an absolute path which contains `\` in Windows, but `entryName` is a general entry name for Webpack, like `app/page`. A quick fix is to replace all `/` in the entry name with the current system separator.
Confirmed that it fixed the problem in Windows.
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/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`
- [ ] [e2e](https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
## Documentation / Examples
- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
The default behavior for svg is `dangerouslyAllowSVG: false` which means we won't try to optimize the image because its vector (see #34431 for more).
However, svg was incorrectly getting the `srcset` attribute assigned which would contain duplicate information like:
```
/test.svg 1x, /test.svg 2x
```
So this PR makes sure we treat svg the same as `unoptimized: true`, meaning there is no `srcset` generated. Note that this PR won't change the behavior if `loader` is defined or if `dangerouslyAllowSVG: true`.
This fixes a bug where next.config.js was configured with `images.unoptimzed: true` but the Image Optimization API was not truly disabled. Since there is no way to override the config at the component level, its safe to say the API can be disabled.
