[Flight] Source Map Server Actions to their Server Location #30741

sebmarkbage · 2024-08-17T22:35:02Z

This uses a similar technique to what we use to generate fake stack frames for server components. This generates an eval:ed wrapper function around the Server Reference proxy we create on the client. This wrapper function gets the original name of the action on the server and I also add a source map if findSourceMapURL is defined that points back to the source of the server function.

For "use server" on the server, there's no new API. It just uses the callsite of registerServerReference() on the Server. We can infer the function name from the actual function on the server and we already have the findSourceMapURL on the client receiving it.

For "use server" imported from the client, there's two new options added to createServerReference() (in addition to the optional encodeFormAction). These are only used in DEV mode. The findSourceMapURL option is the same one added in #29708. We need to pass this these references aren't created in the context of any specific request but globally. The other weird thing about this case is that this is actually a case where the compiled environment is the client so any source maps are the same as for the client layer, so the environment name here is just "Client".

  createServerReference(
    id: string,
    callServer: CallServerCallback,
    encodeFormAction?: EncodeFormActionCallback,
+   findSourceMapURL?: FindSourceMapURLCallback, // DEV-only
+   functionName?: string, // DEV-only
  )

The key is that we use the location of the registerServerReference()/createServerReference() call as the location of the function. A compiler can either emit those at the same locations as the original functions or use source maps to have those segments refer to the original location of the function (or in the case of a re-export the original location of the re-export is also a fine approximate). The compiled output must call these directly without a wrapper function because the wrapper adds a stack frame. I decided against complicated and fragile dev-only options to skip n number of frames that would just end up in prod code. The implementation just skips one frame - our own. Otherwise it'll just point all source mapping to the wrapper.

We don't have a "use server" imported from the client implementation in the reference implementation/fixture so it's a bit tricky to test that. In the case of CJS on the server, we just use a runtime instead of compiler so it's tricky to source map those appropriately. We can implement it for ESM on the server which is the main thing we're testing in the fixture. It's easier in a real implementation where all the compilation is just one pass. It's a little tricky since we have to parse and append to other source maps but I'd like to do that as a follow up. Or maybe that's just an exercise for the reader.

You can right click an action and click "Go to Definition".

For now they simply don't point to the right place but you can still jump to the right file in the fixture:

In Firefox/Safari given that the location doesn't exist in the source map yet, the browser refuses to open the file. Where as Chrome does nearest (last) line.

vercel · 2024-08-17T22:35:05Z

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 18, 2024 4:25pm

react-sizebot · 2024-08-17T22:38:55Z

The size diff is too large to display in a single comment. The GitHub action for this pull request contains an artifact called 'sizebot-message.md' with the full message.

Generated by 🚫 dangerJS against b56c1d5

sebmarkbage · 2024-08-17T23:04:47Z

Another thing to note is that useActionState / useState / useReducer all the return their own dispatcher function that doesn't point to anywhere useful and the Hooks inspecting doesn't show to the actual action/reducer. So there's no way to find the original action for those.

We should probably 1) expose those on the hooks inspection 2) do something clever with the dispatcher function so that it can point to whatever it wraps. E.g. it could itself be an eval like this or we could instrument it with something that at least React DevTools knows about and maybe you can expand in Chrome DevTools.

packages/react-client/src/ReactFlightReplyClient.js

…ences This ensures that it looks nicer when printed in debug tools and so that you can inspect the function and see the server code location. This assumes that the compiler generates source map locations that map the location of the registerServerReference/createServerReference call to the original function location or at least where the export happened.

Follow up to #30741. This is just for the reference Webpack implementation. If there is a source map associated with a Node ESM loader, we generate new source map entries for every `registerServerReference` call. To avoid messing too much with it, this doesn't rewrite the original mappings. It just reads them while finding each of the exports in the original mappings. We need to read all since whatever we append at the end is relative. Then we just generate new appended entries at the end. For the location I picked the location of the local name identifier. Since that's the name of the function and that gives us a source map name index. It means it jumps to the name rather than the beginning of the function declaration. It could be made more clever like finding a local function definition if it is reexported. We could also point to the line/column of the function declaration rather than the identifier but point to the name index of the identifier name. Now jumping to definition works in the fixture. <img width="574" alt="Screenshot 2024-08-20 at 2 49 07 PM" src="https://github.com/user-attachments/assets/7710f0e6-2cee-4aad-8d4c-ae985f8289eb"> Unfortunately this technique doesn't seem to work in Firefox nor Safari. They don't apply the source map for jumping to the definition.

Follow up to #30741. We need to keep the location of the action when it's bound so we can still jump to it.

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 <mail@hendrik-liebau.de>

In the same vein as #69190, where we already unwrapped `createServerReference`, we now also unwrap `registerServerReference`, which is required for React to select the right call stack frame when generating source locations for server actions facebook/react#30741. Whereas unwrapping of `createServerReference` was required for server actions that are imported into client components, unwrapping `registerServerReference` is needed for server actions that are passed from server components to client components. This does not fully enable the source mapping just yet. For this to work end-to-end, the next step is to generate proper spans in the SWC transform, which will be done in the next PR.

@samcx

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 <4586894+mischnic@users.noreply.github.com> 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. ![image](https://github.com/user-attachments/assets/12b15de3-2cc3-4dca-9185-cde5a97cd0c3) Co-authored-by: JJ Kasper <jj@jjsweb.site> feat(next-swc): lint for `ssr: false` in server components (#70378) Co-authored-by: Jiachi Liu <inbox@huozhi.im> [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 <jj@jjsweb.site> fix(example): Change hostname in docker multiple env examples (#70105)  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 <jj@jjsweb.site> fix: updated typescript types for React API's (#70410)  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 <sam@vercel.com> 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 <1939140+ztanner@users.noreply.github.com> Co-authored-by: JJ Kasper <jj@jjsweb.site> 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 <wbinnssmith@gmail.com> 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 <sam@vercel.com> Co-authored-by: Jiachi Liu <inbox@huozhi.im> 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.  refactor: extracted zod configuration (#70478)  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 <mail@hendrik-liebau.de> Turbopack build: Fix benchmark running with webpack (#70533) Ensures there is no error running Tailwind with webpack in this benchmark.  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.

…l#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 <mail@hendrik-liebau.de>

In the same vein as #69190, where we already unwrapped `createServerReference`, we now also unwrap `registerServerReference`, which is required for React to select the right call stack frame when generating source locations for server actions facebook/react#30741. Whereas unwrapping of `createServerReference` was required for server actions that are imported into client components, unwrapping `registerServerReference` is needed for server actions that are passed from server components to client components. This does not fully enable the source mapping just yet. For this to work end-to-end, the next step is to generate proper spans in the SWC transform, which will be done in the next PR.

In the same vein as #69190, where we already unwrapped `createServerReference`, we now also unwrap `registerServerReference`, which is required for React to select the right call stack frame when generating source locations for server actions (see facebook/react#30741). Whereas unwrapping of `createServerReference` was required for server actions that are imported into client components, unwrapping `registerServerReference` is needed for server actions that are passed from server components to client components. This does not fully enable the source mapping just yet. For this to work end-to-end, the next step is to generate proper spans in the SWC transform, which will be done in the next PR.

…71042) This PR adds support for showing the original server sources of server components and server actions in the browser's developer tools. To accomplish that, we're building on top of #69190, #70563, and #70564, in which we prepared the proper generation of the source maps. This PR completes the feature, by wiring up `findSourceMapURL` (see facebook/react#30741) with a new dev server middleware that serves those source map files to the browser. Another change we had to make is disabling the dead-code elimination of server actions in client bundles (see #70103), but only in development mode. This optimization is primarily intended for production bundles, so the change should not pose a problem. With that, it's now possible to jump directly into the server sources from the browser's dev tools, e.g. for component stacks of server logs that are replayed in the browser, or when inspecting server action props in the React DevTools.

Track Creation Location of Server Referencecs

91a2e0c

sebmarkbage requested review from gnoff and eps1lon August 17, 2024 22:35

facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Aug 17, 2024

vercel bot deployed to Preview August 17, 2024 22:37 View deployment

Serialize Server Reference Debug Meta Data

44839f4

sebmarkbage force-pushed the serverreferencelocation branch from 09ec4fe to 751b9b6 Compare August 17, 2024 22:51

vercel bot deployed to Preview August 17, 2024 22:53 View deployment

gnoff approved these changes Aug 18, 2024

View reviewed changes

packages/react-client/src/ReactFlightReplyClient.js Outdated Show resolved Hide resolved

sebmarkbage force-pushed the serverreferencelocation branch from 751b9b6 to b56c1d5 Compare August 18, 2024 16:23

vercel bot deployed to Preview August 18, 2024 16:25 View deployment

sebmarkbage merged commit 6ebfd5b into facebook:main Aug 18, 2024
185 checks passed

sebmarkbage mentioned this pull request Aug 20, 2024

[Flight] Source Map Actions in Reference Node Loader Transforms #30755

Merged

sebmarkbage mentioned this pull request Aug 21, 2024

[Flight] Preserve location of bound server actions #30778

Merged

sebmarkbage added a commit that referenced this pull request Aug 22, 2024

[Flight] Preserve location of bound server actions (#30778)

eb7570b

Follow up to #30741. We need to keep the location of the action when it's bound so we can still jump to it.

eps1lon mentioned this pull request Aug 22, 2024

Update React from 1eaccd82-20240816 to eb3ad065-20240822 vercel/next.js#69196

Merged

shuding mentioned this pull request Aug 23, 2024

Unwrap createServerReference, and pass additional parameters vercel/next.js#69190

Merged

unstubbable mentioned this pull request Sep 27, 2024

Unwrap registerServerReference function vercel/next.js#70563

Merged

unstubbable mentioned this pull request Oct 9, 2024

[Not for merge] Lazily require react-server-dom-webpack in next-flight-loader vercel/next.js#71023

Closed

unstubbable mentioned this pull request Oct 10, 2024

Add source map support for server components/actions in the browser vercel/next.js#71042

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Flight] Source Map Server Actions to their Server Location #30741

[Flight] Source Map Server Actions to their Server Location #30741

sebmarkbage commented Aug 17, 2024 •

edited

Loading

vercel bot commented Aug 17, 2024 •

edited

Loading

react-sizebot commented Aug 17, 2024 •

edited

Loading

sebmarkbage commented Aug 17, 2024

[Flight] Source Map Server Actions to their Server Location #30741

[Flight] Source Map Server Actions to their Server Location #30741

Conversation

sebmarkbage commented Aug 17, 2024 • edited Loading

vercel bot commented Aug 17, 2024 • edited Loading

react-sizebot commented Aug 17, 2024 • edited Loading

sebmarkbage commented Aug 17, 2024

sebmarkbage commented Aug 17, 2024 •

edited

Loading

vercel bot commented Aug 17, 2024 •

edited

Loading

react-sizebot commented Aug 17, 2024 •

edited

Loading