Disable React 18 tests on PRs #70541
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
New CI budget is approved and the hydration tests are flaky. There's no active work on Pages router so this is safe-ish to ignore to unblock work on App router.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
ijjk
approved these changes
Sep 26, 2024
devjiwonchoi
added a commit
that referenced
this pull request
Sep 29, 2024
chore: codemod versions chore: remove chalk, use picocolors refactor chore: select codemods to run restore unexpected deletion ncc compiled refac: fetch next package after prompt wip before using next-test-util add find-up better handle package test: add basic test test: prompt test: fix temp dir names try try2 try try 3 is CNA np? is CNA np? set initial for codemod revert next codemod v15.0.0-canary.167 [Turbopack] fix rsc chunking optimization (#70461) * While looking for server component entries and client components, look for server utils too * Create a separate chunk group for server utils * Mark all user imports in the rsc entrypoint has server component entries * Fix order of imports to allow proper caching --------- Co-authored-by: Niklas Mischkulnig <[email protected]> Turbopack: allow shadowing the `require` global in ESM (#70453) Closes PACK-3275 Among other things, a regression from #70255, but it could also happen with `__dirname`. To prevent `SyntaxError: Identifier 'require' has already been declared` Add cause to turbopack-node error (#70456) Occurs for example in ``` Failed to load chunk server/chunks/08b5e__pnpm_560cbe._.js .... Caused by SyntaxError: Identifier 'require' has already been declared .... ``` test: disable next/test tests (#70460) chore(workflow): typo `popular-prs.ts` path (#70462) add @taskr/esnext to pnpm root to resolve hoisting issues (#70349) Add `@taskr/esnext` to the root package.json to get around hoisting rules breaking `taskr`'s automatic discovery (and fix builds on some platforms where it is broken). Some types of 'magically' imported packages (such as taskr automatically supporting es6 by just adding a package, or drizzle automatically finding a database driver) aren't hoisted on some platforms in the way the tool expects, breaking it. The symptom of this is taskr throwing a syntax error on some platforms, because we use ES6 syntax and it can't find the package it needs to support it. By adding it to the root package.json we ensure it is always hoisted in the way taskr expects. Turbopack: fix another case of edge runtime warnings (#70455) Closes PACK-3276 v15.0.0-canary.168 Extend support of Pages router to React 18 (#70219) codemod(turbopack): Inline trivial uses of `let this = self` (#70431) A follow-up to the #70431 codemod diff, which leave behind a lot of trivial `let this = self;` statements. Using the following ast-grep rule config: ```yaml language: rust id: inline_trivial_this utils: block-with-this: all: - pattern: $BLOCK - kind: block - has: all: - pattern: let this = $SELF; - any: - pattern: let this = self; - pattern: let this = &self.0; rule: matches: block-with-this rewriters: - id: remove-let-this rule: pattern: let this = $SELF; fix: "" - id: inline-this-auto-deref rule: pattern: this inside: kind: field_expression transform: SELF_AUTO_DEREF: replace: source: $SELF replace: "&?(?<INNER>.*)" by: "$INNER" fix: $SELF_AUTO_DEREF - id: inline-this rule: pattern: this fix: $SELF transform: NEW_BLOCK: rewrite: source: $BLOCK rewriters: - remove-let-this - inline-this-auto-deref - inline-this fix: $NEW_BLOCK ``` Applied with ``` sg scan -U -r ../codemod_inline_trivial_this.yml . ``` Fix comment numbering in middleware example in docs (#70465) This PR fixes a numbering issue in the example code of the documentation. The comments in the code jumped from step 3 to step 5, so I renumbered them to maintain the correct sequence. Correcting the comment numbering improves the clarity and readability of the code, ensuring that readers can follow the steps in the right order. I changed step 5 to step 4 and step 6 to step 5, adjusting the comment sequence without altering the logic or functionality of the code.  Co-authored-by: JJ Kasper <[email protected]> feat(next-swc): lint for `ssr: false` in server components (#70378) Co-authored-by: Jiachi Liu <[email protected]> [Turbopack] fix a bunch of bugs and inefficiencies in the call graph (#70243) * switch remove vs change order * take_collectibles does not need to return an Option * avoid double Option * fix edges set bugs * remove collectibles from outdated collectibles * remove unneccessary remove Basic implementation of cache-wrapper with RSC serialization (#70435) Co-authored-by: JJ Kasper <[email protected]> fix(example): Change hostname in docker multiple env examples (#70105) <!-- 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: - 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 - 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 - 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 - 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 - 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 --> Update the docker with multiple env examples by the correct hostname. I am verry happy when I see this example, I need to deploy a project with multiple environments, I tested current example for my machine, but it started but it didn't connect to app. I really try this example https://github.com/vercel/next.js/tree/canary/examples/with-docker-multi-env. but it doesn't connect to nextjs container because the hostname configuation is incorrect. I created this PR to change hostname from host ```localhost``` to ```0.0.0.0``` in docker with multiple environments Closes NEXT- No fixing any issues Co-authored-by: JJ Kasper <[email protected]> fix: updated typescript types for React API's (#70410) <!-- 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: - 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 - 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 - 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 - 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 - 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 Closes NEXT- Fixes # --> This adds and updates some Typescript types for the React libraries used by Next.js. As a result some of the code was modified to match. Fix type error from merge (#70481) x-ref: #70410 x-ref: #70435 Ensure validator is included in vendored AMP validator (#70482) This aims to provide more stability so we aren't hitting the network to grab the validator more than we need to and instead leverage the one from build instead which should also reduce some test flakiness we've been seeing. v15.0.0-canary.169 Updated the example of with-draft-js to utilize the App Router. (#70045) This PR updates the with-draft-js example for using the App Router. Here are the changes that have been made: - Renamed the "pages" folder to the "app" folder. - Added the layout.tsx file as part of the App Router. - Updated the package.json file. CC: @samcx --------- Co-authored-by: Sam Ko <[email protected]> v15.0.0-canary.170 [Breaking] Update Dynamic APIs to be async (#68812) Next.js has a number of dynamic APIs that aren't available during prerendering. What happens when you access these APIs might differ depending on the mode you are using, for instance if you have PPR turned on or the newly introduced `dynamicIO` experimental mode. But regardless of the mode the underlying API represents accessing something that might only be available at render time (dynamic rendering) rather than prerender time (build and revalidate rendering) Unfortunately our current dynamic APIs make certain kinds of modeling tricky because they are all synchronous. For instance if we wanted to add a feature to Next.js where we started a dynamic render before a Request even hits the server it would be interesting to be able to start working on everything that does not rely on any dynamic data and then once a real Request arrives we can continue the render and provide the associated Request context through our dynamic APIs. If our dynamic APIs were all async we could build something like this because they represnt a value that will eventually resolve to some Request value. This PR updates most existing dynamic APIs to be async rather than sync. This is a breaking change and will need to be paired with codemods to realistically adopt. Additionally since this change is so invasive I have implemented it in a way to maximize backward compatibility by still allowing most synchronous access. The combination of codemods, typescript updates, and backward compat functionality should make it possible for projects to upgrade to the latest version with minimal effort and then follow up with a complete conversion over time. `cookies()` now returns `Promise<ReadonlyRequestCookies>`. Synchronous access to the underlying RequestCookies object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component const token = (await cookies()).get('token') // sync Server Component import { use } from 'react' //... const token = use(cookies()).get('token') // ------------ temporarily allowed usage // javascript, dev warning at runtime const token = cookies().get('token') // typescript, dev warning at runtime import { type UnsafeUnwrappedCookies } from 'next/headers' // ... const token = (cookies() as unknown as UnsafeUnwrappedCookies).get('token') ``` `headers()` now returns `Promise<ReadonlyHeaders>`. Synchronous access to the underlying Headers object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component const header = (await headers()).get('x-foo') // sync Server Component import { use } from 'react' //... const header = use(headers()).get('x-foo') // ------------ temporarily allowed usage // javascript, dev warning at runtime const header = headers().get('x-foo') // typescript, dev warning at runtime import { type UnsafeUnwrappedHeaders } from 'next/headers' // ... const header = (headers() as unknown as UnsafeUnwrappedHeaders).get('x-foo') ``` `draftMode()` now returns `Promise<DraftMode>`. Synchronous access to the underlying DraftMode object is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Server Component if ((await draftMode()).isEnabled) { ... } // sync Server Component import { use } from 'react' //... if (use(draftMode()).isEnabled) { ... } // ------------ temporarily allowed usage // javascript, dev warning at runtime if (draftMode().isEnabled) { ... } // typescript, dev warning at runtime import { type UnsafeUnwrappedDraftMode} from 'next/headers' // ... if ((draftMode() as unknown as UnsafeUnwrappedDraftMode).isEnabled) { ... } ``` `searchParams` is now a `Promise<{...}>`. Synchronous access to the underlying search params is still supported to facilitate migration. ```tsx // ------------ preferred usage // async Page Component export default async function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const fooSearchParam = (await searchParams).foo } // sync Page Component import { use } from 'react' export default function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const fooSearchParam = use(searchParams).foo } // ------------ temporarily allowed usage // javascript, dev warning at runtime export default async function Page({ searchParams}) { const fooSearchParam = searchParams.foo } // typescript, dev warning at runtime import { type UnsafeUnwrappedSearchParams } from 'next/server' export default async function Page({ searchParams }: { searchParams: Promise<{ foo: string }> }) { const syncSearchParams = (searchParams as unknown as UnsafeUnwrappedSearchParams<typeof searchParams>) const fooSearchParam = syncSearchParams.foo } ``` `params` is now a `Promise<{...}>`. Synchronous access to the underlying params is still supported to facilitate migration. It should be noted that while params are not usually dynamic there are certain modes where they can be such as fallback prerenders for PPR. ```tsx // ------------ preferred usage // async Segment Component export default async function Layout({ params }: { params: Promise<{ foo: string }> }) { const fooParam = (await params).foo } // sync Segment Component import { use } from 'react' export default function Layout({ params }: { params: Promise<{ foo: string }> }) { const fooParam = use(params).foo } // ------------ temporarily allowed usage // javascript, dev warning at runtime export default async function Layout({ params}) { const fooParam = params.foo } // typescript, dev warning at runtime import { type UnsafeUnwrappedParams } from 'next/headers' export default async function Layout({ params }: { params: Promise<{ foo: string }> }) { const syncParams = (params as unknown as UnsafeUnwrappedParams<typeof params>) const fooSearchParam = syncParams.foo } ``` When using typescript with Next.js currently it is up to you to author types for Pages, Layouts and other Segment components that recieve props like `params` and `searchParams`. Next comes with some build-time type checking to ensure you have not improperly typed various top level module exports however the current type assertions for `params` and `searchParams` is `any`. This isn't very helpful because it allows you to erroneously type these props. `searchParams` is tricky because while the default type is a dictionary object parsed using node.js url parsing it is possible to customize when running a custom Next.js server. However we can ensure that you correctly type the prop as a Promise so with this change the validated type for `searchParams` will be `Promise<any>`. In the long run we will look at updating the `searchParams` underlying type to be URLSearchParams so we can move away from supporting customized parsing during rendering and we can get even more explicit about valid types. `params` is more straight forward because the framework controls the actual `params` prop implementation and no customization is possible. In the long run we want to enforce you are only typing params that are valid for the Layout level your file is located in but for now we are updating the allowed type to be `Promise<{[key: string]: string | string[] | undefined }>`. These new type restrictions may also require fixes before being able to successfully build a project that updates to include these breaking changes. These changes will also not always be codemodable because it is valid to type the entire component using an opaque type like `Props` which our codemods may not have an ability to introspect or modify. v15.0.0-canary.171 Base JS runtime for builds (#70169) fix failing ppr deploy test (#70491) This behavior is differing when deployed causing failures. [x-ref](https://github.com/vercel/next.js/actions/runs/11042054253/attempts/2) [x-ref](https://github.com/vercel/next.js/actions/runs/11041870219/attempts/2) chore(sass): add docs for `implementation` property in `sassOptions` and update `sassOption` types (#70428) We currently don't document the `implementation` property for `sassOptions`. Since this is one our maintained properties, we should also update the types for `sassOptions`. - Fixes #70020 --------- Co-authored-by: Zack Tanner <[email protected]> Co-authored-by: JJ Kasper <[email protected]> perf(turbopack): Optimize turbopack tree shaking using `pure` (#70433) Use `pure` property to check if we need a group To reduce the number of internal parts. codemod(turbopack): Remove unused async function modifier keywords (#70474) I left a bunch of these behind in #70412 . This cleans them up. The only remaining work after this is removing unused `Result<...>`s from return types. ast-grep config: ```yaml language: rust id: remove_unused_async_keyword rule: pattern: async inside: kind: function_modifiers inside: kind: function_item follows: pattern: context: | #[turbo_tasks::function] selector: attribute_item stopBy: not: kind: attribute_item has: field: body not: has: any: - kind: await_expression - pattern: context: foo!($$$ await $$$) selector: token_tree inside: kind: macro_invocation stopBy: end stopBy: any: - kind: function_item - kind: async_block - kind: closure_expression fix: "" ignores: - "**/turbo-tasks-testing/**" - "**/turbo-tasks-memory/tests/**" ``` Applied with: ``` sg scan -U -r ../codemod_remove_unused_async_keyword.yml . && cargo fmt ``` docs(cli): add mention of default port with experimental-https (#70497) There is no mention of what the default port is when you `next dev --experimental-https`. x-ref: https://x.com/rauchg/status/1839092783392632867 --------- Co-authored-by: Will Binns-Smith <[email protected]> remove redux devtools from router reducer (#70495) It's a bit odd that we expose this internal debugging capability in production and it seems to cause potential production issues when serializing unsupported data structures ([x-ref ](#69436)) If we feel a need to re-introduce the ability to introspect on the router state even in production we could consider relanding it in an opt-in way, and not run on every action. But I think since we've moved away from throwing promises in reducers (back when the reducers could potentially be replayed by React, in early Suspense implementations), I'm not sure this provides as much value. Fixes #70441 feat(turbopack): Evaluate simple numeric addition (#70273) Add evaluation logic for cases where we are sure that the result is a number and not a string. It's required for DCE. Upgrade React from `5d19e1c8-20240923` to `778e1ed2-20240926` (#70486) codemod(turbopack): Remove unused `Result<...>` return types from `#[turbo_task::function]`s (#70492) The `#[turbo_tasks::function]` macro always exposes a `impl Future<Output = Result<ReadRef<T>>>`, regardless of the function's actual return type. We only need to use a `Result<...>` return type when the function can fail. If it's infallible, this just adds noise. I left a bunch of these behind in #70412, plus I think we had a lot of these independent of that PR. This cleans them up. ```yaml language: rust id: remove_unused_result_return_type utils: last-expression-inside-block: any: - inside: # single-line blocks just have the expression as the only child kind: block nthChild: position: 1 reverse: true - inside: # multi-line blocks wrap their final expression in an expression_statement kind: expression_statement inside: kind: block nthChild: position: 1 reverse: true ok-expression: kind: call_expression any: - pattern: Ok($_ARG) - pattern: $$$::Ok($_ARG) ok-expression-capturing: kind: call_expression any: - pattern: Ok($ARG) - pattern: $$$::Ok($ARG) # ast-grep does not appear to allow utils to be recursive, split out "simple blocks", and limit supported nesting simple-block-with-implicit-ok-return: kind: block has: nthChild: position: 1 reverse: true matches: ok-expression simple-expression-ok-value: any: - matches: simple-block-with-implicit-ok-return - kind: if_expression all: - has: field: consequence matches: simple-block-with-implicit-ok-return - has: field: alternative has: matches: simple-block-with-implicit-ok-return - kind: match_expression has: field: body not: has: kind: match_arm has: field: value not: any: - matches: ok-expression - matches: simple-block-with-implicit-ok-return block-with-implicit-ok-return: any: - matches: simple-block-with-implicit-ok-return - kind: block has: nthChild: position: 1 reverse: true any: - kind: expression_statement has: matches: simple-expression-ok-value - matches: simple-expression-ok-value # single-line blocks don't result-return-type: pattern: context: fn func() -> Result<$INNER_RET_TY> {} selector: generic_type infallible-fn: # this function only appears to return `Ok(...)`, it does not use try_expression (`?`) or `anyhow::bail!(...)` kind: function_item not: has: field: body any: - not: matches: block-with-implicit-ok-return - has: stopBy: kind: function_item any: - kind: try_expression - pattern: "?" inside: kind: macro_invocation stopBy: end - pattern: bail!($$$) - pattern: $$$::bail!($$$) - kind: return_expression not: has: matches: ok-expression rule: all: - pattern: $FUNC - kind: function_item has: field: return_type matches: result-return-type follows: pattern: context: | #[turbo_tasks::function] selector: attribute_item stopBy: not: kind: attribute_item - matches: infallible-fn rewriters: # this rewriter is far from perfect, and might rewrite too much - id: rewrite-return-type rule: matches: result-return-type inside: kind: function_item field: return_type fix: $INNER_RET_TY - id: unwrap-ok-values rule: all: - matches: ok-expression-capturing - any: - matches: last-expression-inside-block - inside: kind: return_expression - inside: kind: match_arm fix: $ARG transform: NEW_FUNC: rewrite: rewriters: - rewrite-return-type - unwrap-ok-values source: $FUNC fix: $NEW_FUNC ignores: - "**/turbo-tasks-testing/**" - "**/turbo-tasks-memory/tests/**" ``` ``` sg scan -U -r ../codemod_remove_unused_result_return_type.yml && cargo fix --lib --allow-dirty && cargo fmt ``` I used `cargo fix` in this case to auto-remove the now-unused `anyhow::Result` imports. I manually fixed clippy lints that now violated the `let_and_return` lint rule (using a separate commit inside this PR), as `cargo clippy --fix` seemed to hang when processing our `build.rs` files? Sitemap video tag support (#69349) Co-authored-by: Sam Ko <[email protected]> Co-authored-by: Jiachi Liu <[email protected]> Respect reexports from metadata API routes (#70508) Move ci-info utility to be under the server folder (#70514) This is because CI info will be used by other modules of the server, not just Telemetry. This refactoring doesn't change any functionalities. Use Server/Client Manifests from Singleton in encryption-utils (#70485) The closure encryption utilities need the same module maps as use-cache-wrapper. We can share the same singletons. Using singletons for this is sketchy because if concurrent requests switches to another page with a different manifest, it would potentially have missing entries. We should ideally use AsyncLocalStorage but this is not making anything worse and any solution should apply to both. This doesn't actually make anything new work. Because you can't pass a Server References into these functions since React doesn't yet allow Server References inside the RSC layer to be encoded through encodeReply. We could. One thing to note there is that if we do allow that then the id of the Server Reference ideally includes the hash of its implementation (not just Cache IDs) because if the implementation can change without the id then passing a Server Reference as an argument to "use cache" and calling it within the cache should not reuse results if the implementation changes. It also doesn't yet work to pass Client References out of these functions because the SSR manifest is missing. That is already missing for encryption too and we should pass the same thing into both there. This clarifies that in either case we should always pass null for moduleLoading because that's only used for SSR and would lead to unnecessary preloads to be added if we replayed the preloads that are already covered by client references. refactor: remove ability to call getStaticPaths from app directory pages (#70477) We previously supported a legacy mode of exporting a `getStaticPaths` from app directory pages. This removes that option in favour of `generateStaticParams`. Turbopack build: Add devlow-bench (#70511) Ensures Webpack build and Turbopack build results for the heavy-npm-deps benchmark are uploaded to DataDog so that we can track them over time. <!-- 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: - 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 - 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 - 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 - 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 - 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 Closes NEXT- Fixes # --> refactor: extracted zod configuration (#70478) <!-- 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: - 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 - 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 - 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 - 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 - 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 Closes NEXT- Fixes # --> This just moves the zod helper utilities into it's own file so we can re-use it in future PR's. [ppr] Added fallback shell debugging (#70528) This enhances the experimental debugging mode for Partial Fallback Prerendering to only render the fallback shell. Remove shouldRevalidateStale concept from CacheHandlers (#70493) We want to immediately expire any stale entries from memory caches. So we just have treat them as missing/expired directly. fallback shell should not error when dynamic due to params access even with dynamic = "error" (#70534) When producing a fallback shell params is dynamic. Normally anything dynamic shoudl be a build error when `export const dynamic = "error"` is used. however for fallback shells we'll never have fully static shells, nor should we since the whole point is to produce a PPR shell that server a wide range of paths. In the refactor for async dynamic APIs I introduced a bug where fallback param dynamic also errored if `export const dynamic = "error"` was used. This change corrects this behavior and adds a corresponding test Add cache scope handling for dynamic IO for dev/build (#70408) As discussed this adds an in memory cache scope which is leveraged for seeding during prefetch and then leveraged during non-prefetch requests in development and during build it shares a cache scope across one build worker. During production server mode the cache scopes are specific per-request with no prefetch cache seeding. remove unimplemented onError errorInfo argument (#70531) RSC has never supported the `errorInfo` argument to `onError` unlike SSR. This PR updates our usage of onError in RSC contexts to clarify that this value does not exist This also updates the next interned types for react-dom/server to reflect that `renderTo...` and `prerender` support the `ErrorInfo` second arg and `resume` does not. Disable React 18 tests on PRs (#70541) New CI budget is not approved yet and the hydration tests are flaky. There's no active work on Pages router so this is safe-ish to ignore to unblock work on App router which doesn't run on the installed React anyway. Add env for setting cache handler path (#70537) As discussed this allows customizing the cache handler via env instead of only in `next.config`. Disable "use cache" outside of dynamicIO (#70538) Include buildId in the cache breaker until we have hashed Action IDs (#70542) Currently our Action IDs don't include hashing of the implementation which they ideally should, or at least have a separate ID for that. This means it is not safe to reuse cache entries across deployments since the Action ID can remain unchanged. For now we include the build ID as part of the cache key to ensure we don't use cache entries. We should remove this or replace it with the hash of the Action later. Support dynamicIO in middlware routes and generateStaticParams (#70544) route.ts files (and other routes like metadata routes) still need dynamicIO semantics when runnign in edge runtime. This change adds support for configuring dynamicIO for edge routes. It is hard to test properly because edge routes never statically generate and at the moment there are no other observable semantics. If we introduce new semantics that are distinct for dynamicIO that affect dynamic rendering we should update these tests to assert them. Similarly generateStaticParams also needs dynamicIO semantics when configured. Right now it's not quite possible to assert this because there are no observable semantics. We should have one which is that fetchCache is not configurable with dynamicIO on however that isn't implemented yet. This change adds tests but they will need to be updated once we update the fetchCache behavior Unwrap `createServerReference`, and pass additional parameters (#69190) For facebook/react#30741 This PR adds several additional parameters to the `createServerReference` calls generated by the Server Reference SWC transform, to later enable React to map server actions that are imported into client components back to their server locations (dev mode only). Currently the inner `findSourceMapURL` function is not yet implemented. In a follow-up we will unwrap `registerServerReference` as well, which is needed for server actions in the react server layer. --------- Co-authored-by: Hendrik Liebau <[email protected]> Turbopack build: Fix benchmark running with webpack (#70533) Ensures there is no error running Tailwind with webpack in this benchmark. <!-- 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: - 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 - 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 - 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 - 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 - 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 Closes NEXT- Fixes # --> uncomment test try test try test test: try package json remove temp try cli as before rc and transform path use process cwd run for change try cwd to packages try cna path try get pkg fix: path itg test.. try try e2e dep skip currnet testdir cwd exist sync? ? readdir dirent string lfg test: expected tests test: delete e2e try #70592 resolve conflict with canary Revert "resolve conflict with canary" This reverts commit 43d71ae. Revert "try #70592" This reverts commit 2637d43.
abhi12299
pushed a commit
to abhi12299/next.js
that referenced
this pull request
Sep 29, 2024
New CI budget is not approved yet and the hydration tests are flaky. There's no active work on Pages router so this is safe-ish to ignore to unblock work on App router which doesn't run on the installed React anyway.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New CI budget is not approved yet and the hydration tests are flaky.
There's no active work on Pages router so this is safe-ish to ignore to unblock work on App router which doesn't run on the installed React anyway.