Fixed the example functions in the documentation to use `async` in order to use `await` within the function body.
Co-authored-by: Michael Novotny <446260+manovotny@users.noreply.github.com>
An issue discovered from #56502 in azure pipeline
```
> Build error occurred
ReferenceError: structuredClone is not defined
```
`structuredClone` is not supported until nodejs 17, here we actually don't need to use `structuredClone` as the values are almost primitives, the deepMerge case we're using mainly objects and array, which are already handled above
This PR splits apart the function used to render App Router pages into smaller chunks for better readability + testing. A lot of the complexity is tied by the fact that a lot of the code of the function relied on closures so I had to coalesce a lot of the captured variables used into one big context that is then passed around during render.
There are a lot of things to slim down further but I don't have the energy to dig more.
### What?
Update documentation on dynamic routing to clarify the use of segment names within file names, rather than referring to them as "folder names".
### Why?
The original documentation used the example term `folderName` when it was referencing dynamic segment names within filenames. The paths being described here are file names but not folders, and end in a file extension. This could confuse readers and developers, especially those new to Next.js, leading to potential misunderstandings and misconfigurations. Perhaps folderName was a relic of a different example wrapping a folder name to do a nested path or other configuration? But here it seems out of place.
### How?
- Reviewed the provided documentation sections on dynamic routing.
- Replaced references to "folderName" with a different term "segmentName".
- Ensured the examples provided in the documentation correctly showcase the use of segment names within filenames.
When there's a version skew, it might be possible that the Action's ID has changed and we're no longer able to locate it. By definition, that means we **should** return a 404 because it might have a different implementation now. Currently this throws a "cannot access workers of undefined" error which doesn't make sense.
Please review with whitespace ignored.
IMO there is not enough of an indicator that client components render on the server on full page loads towards the top of the documentation page. I've seen plenty of experienced devs totally miss this critical info and get stuck on a problem due to a lack of understanding. Putting at least some kind of indicator above the fold would help with that.
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
### Observed Issue
```
⚠ Restarted collecting page data for [object Object] because it took more than 60 seconds
```
### Fix
The original issue is caused because the path is assigned to the `argument` array itself. Passing the argument type to the he worker, so in restart callback we're type safe, can the value will be correct.
<!-- 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(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
this is a follow-up to #48018 (don't add `isolatedModules: true` to
`tsconfig.json` when `verbatimModuleSyntax: true` is set), which also
handles the case where `verbatimModuleSyntax: true` is set in a base
tsconfig which is being referenced via `tsconfig#extends`.
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
This:
- Updates rust-toolchain to nightly-2023-10-06
- Removes allowing clippy rules for needless_pass_by_ref_mut and non_canonical_partial_ord_impl as these were never needed by this repo.
Test Plan: CI
Closes WEB-1733
This is just moving the `wrappedRender` function out of the `renderToHTMLOrFlight` function so that it's defined in the module scope.
You'll want to turn on hide whitespace during review 😉
Discovered while investigating https://github.com/vercel/next.js/pull/56526, turns out errors occuring during webpack builds do not fail the `pnpm build` which kicks off `taskr`. This is because `taskr` runs their plugins within coroutines, which based on the result, was not handling the promise rejections as expected.
### What?
While debugging #56456, I noticed that we cut useful information, namely the `Error` instances' [`cause` property](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause).
### Why?
In #56456, it was hiding the following:
```sh
Error: getaddrinfo EAI_AGAIN undefined
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:108:26)
at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
errno: -3001,
code: 'EAI_AGAIN',
syscall: 'getaddrinfo',
hostname: 'undefined'
}
```
which might be an indicator to the user what was going wrong with the `fetch` call.
### How?
If there is a `err.cause` property, log it together with `err.digest`
Note, this does not fix#56456 but might be useful to debug similar issues as well.
This applies the predefined list of packages in server-external-packages.json as always external when used by app router in Turbopack
Test Plan: Added integration tests
Closes WEB-1709
This adds a test that asserts that, without additional configuration like `experimental.bundlePagesExternals`, Next.js does not bundle `node_modules` for pages.
Closes WEB-1708
This PR flattens the recursive optimization logic of our barrel optimization loader. So now if there're any recursive `export * from ...`, they won't be created as multiple individual Webpack modules, but optimized in one module.
With this change, we are running SWC transform to get the export map directly inside the barrel loader (instead of a separate loader rule). And that map is recursively calculated and cached in memory.
I also published https://unpkg.com/browse/recursive-barrel@1.0.0/ to give this a test. It contains 4 levels of 10 `export *` expressions, which is 10,000 modules in total. Without this change, it takes ~30s to compile and with this change, it goes down to ~7s.
### What?
Step 3 in our chunking refactors extracts ChunkItem::as_chunk into a new ChunkType trait. This new trait isn't useful yet, but will eventually allow us to collect ChunkItems of a similar type into a lists, and perform chunking over all similar items at once.
### Why?
In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
https://github.com/vercel/turbo/pull/6123
Re: https://github.com/vercel/next.js/pull/56504
Closes WEB-1724
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
This PR fixes `next start` and `next dev` so that they show the correct server boot-up time. The previous way of computing the start time was incorrect and misleading as it did not start exactly when next started.
Before:
> ✓ Ready in 120ms
After:
> ✓ Ready in 286ms
### What?
The second step in our chunking refactoring, this removes our use of Module::as_chunk and Module::as_root_chunk. Instead, the only way to generate a chunk is directly from a root ChunkItem.
### Why?
In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
https://github.com/vercel/turbo/pull/6120
Re: https://github.com/vercel/next.js/pull/56467
Closes WEB-1721
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
When we landed #51179 it broke library like `apollo-client` as it's bundling client hooks into RSC bundle, so our RSC linter caught them and reported fatal errors. But those client hook APIs won't get executed in RSC. The original purpose of erroring on invalid hooks for server & client components was to catch bugs easier, but it might be too strict for the 3rd party libraries like `apollo-client` due to few reasons.
We changed the rules only applying on user land source code. For 3rd party packages if they're not being imported correctly into proper server or client components, we're still showing runtime errors instead of fatal build errors.
x-ref: https://github.com/apollographql/apollo-client/issues/10974
Closes NEXT-1673
This is the first in a series of PRs replacing our use of fs-extra with node's own `node:fs`.
Test Plan:
With clean and existing artifacts in each case, ran:
- `pnpm build`
- `pnpm dev`
- `./node_modules/.bin/taskr ncc`
Closes WEB-1717
### What?
This change moves a few methods around.
Module::as_chunk is moved to ChunkItem::as_chunk as temporary intermediate state.
EcmascriptPlaceable::as_chunk_item is moved to ChunkableModule::as_chunk_item. This generalizes the concept of converting a Module into a ChunkItem
### Why?
This is the first step of refactoring the chunking. In the end we want to avoid creating chunks from modules directly, but enforce everything going through the ChunkingContext to be chunked. This allows us to replace the existing chunking algorithm with a much more efficient one that avoid duplication between chunks in first place and doesn't require a post-chunking optimization.
### How?
see https://github.com/vercel/turbo/pull/6104
Closes WEB-1715
Co-authored-by: Justin Ridgewell <112982+jridgewell@users.noreply.github.com>
This replaces the `(global as any)._nextDevHandlers` invocation with references to a specific service instance while also removing the module scoped `devInstances`. This ensures that correct types are used.
This was done while changing the `match` parameter in `ensurePage` to `definition` which didn't cause a typescript error (it should have).
The PR supersedes the https://github.com/vercel/next.js/pull/53150, which is way too outdated, has way too many conflicts, and also heavily relies on GitHub Copilot (which makes the progress slow and tedious).
The PR uses [`json-schema-to-zod`](https://github.com/StefanTerdell/json-schema-to-zod) (instead of the GitHub Copilot) to generate the zod schema, and manually replaces all generated `z.customRefine` with my hand-written zod schema.
TODO:
- [x] Convert schema
- [x] Reduce `z.any()` usage
- [x] Create human-readable errors from the `ZodError`
- [x] Update test cases to reflect the latest error message
-----
The benefit of using zod over ajv:
- Easier maintenance: zod schema is straightforward to compose.
- Better typescript support: config schema now strictly reflects the `NextConfig` type.
- Smaller installation size: by replacing `ajv` and `@segment/ajv-human-errors` w/ `zod`, I am able to reduce installation size by 114 KiB.
- Better Extension: the zod error message is easy to customize.
-----
In the previous PR https://github.com/vercel/next.js/pull/56083, @feedthejim replaces `zod` w/ `superstruct`. `superstruct` is lightweight and fast, which makes it perfect for creating simple schemas for RSC payload. But, this also means `superstruct` has its limitations compared to `zod`:
- `superstruct`'s syntax is different, and some utilities's usage is counter-intuitive:
- `z.array(z.string()).gt(1)` vs `s.size(s.array(s.string()), 1)`
- `z.numer().gt(1)` vs `s.size(s.number(), 1)`, `s.min(s.number(), 1)`
- `z.boolean().optional().nullable()` vs `s.nullable(s.optional(z.boolean()))`
- `superstruct` has weaker TypeScript support and worse DX compared to `zod` when composing huge schema:
- `zod.ZodType + z.object()` can provide a more detailed type mismatch message on which specific property is the culprit, while `Describe + s.object()` provides almost no information at all.
- `zod`'s schema is more powerful
- `z.function()` supports `z.args()` and `z.returns()`, while `superstruct` only has `s.func()`
- zod also has Promise type `z.promise()` and intersection type `z.and()`
- `superstruct`'s error is harder to parse compared to `zod`'s `ZodError`
So in the PR, I re-introduced `zod` for `next.config.js` validation.
This adds types for the component modules so that the modules no longer need to rely on `ComponentMod` being `any`. This allows stricter typing for those elements.
This also improves types around template files to allow their exports to form the `ComponentMod` types.
Updates `.node-version` to allow any version of `18` which will allow development machines to update to newer minor releases without the need to update the repository each time.
### What?
This implements Server Actions inside the new Turbopack next-api bundles.
### How?
Server Actions requires:
1. A `.next/server/server-reference-manifest.json` manifest describing what loader module to import to invoke a server action
2. A "loader" entry point that then imports server actions from our internal chunk items
3. Importing the bundled `react-experimental` module instead of regular `react`
4. A little 🪄 pixie dust
5. A small change in the magic comment generated in modules that export server actions
I had to change the magic `__next_internal_action_entry_do_not_use__` comment generated by the server actions transformer. When I traverse the module graph to find all exported actions _after chunking_ has been performed, we no longer have access to the original file name needed to generate the server action's id hash. Adding the filename to comment allows me to recover this without overcomplicating our output pipeline.
Closes WEB-1279
Depends on https://github.com/vercel/turbo/pull/5705
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: Jiachi Liu <4800338+huozhi@users.noreply.github.com>
