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`

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.

![image](https://github.com/user-attachments/assets/12b15de3-2cc3-4dca-9185-cde5a97cd0c3)

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.

Closes PACK-3275

Among other things, a regression from
vercel#70255, but it could also happen
with `__dirname`.

To prevent `SyntaxError: Identifier 'require' has already been declared`