When we apply `createActionProxy` twice to the same value, it currently
errors because we can't override the ID of it.
This PR makes sure that 1) when the value already have an ID defined, we
skip setting it again; 2) all the action IDs are being tracked even for
duplicated ones.
Note that it's technically impossible to "detect" the duplication here
(via static analyzation) and only set it once. For example:
```ts
'use server'
export async function foo () {}
export const bar = a_value_we_dont_know_yet ? foo : async () => {}
```
So, the compiler will always wrap `createActionProxy` for every exported
value and assume they're different Server Actions (hence different IDs).
With this fix, if we find that it's already defined before, we just
return the defined reference as they're strictly identical so the ID
does't matter.
Closes#54655, closes#61183.
Closes NEXT-2264
### What?
The import alias had no way to resolve the page extensions and we
already have them resolved in the `PagesStructure`, so with this PR we
use the already resolved paths.
Closes PACK-2085
Fixes#59264
### What?
This fixes 2 issues with app 404 pages.
1. The root layout in a group was previously ignored when hitting the
404 page.
2. The default app 404 page was missing the correct path for dev
`/not-found` so it would fall back to the pages 404 page.
Closes PACK-2241
Fixes#60688
This PR improves the Server Actions SWC transform to make it able to
handle nested Action declarations (check
`fixture/server-actions/server/28/input.js` for more details).
It is also a simplification of that transform's internal states and
methods, with the removal of an extra AST pass
(`stmts.visit_mut_with(&mut ClosureActionReplacer {
replaced_action_proxies: &self.replaced_action_proxies, })`). The
generated code is also smaller in some cases. So overall I'd expect the
compilation and runtime performance to improve as well.
## Details
With this change, we're now using `self.declared_idents` and
`self.names` to track closure arguments. `declared_idents` keeps the
identifiers **declared** in the current closure and above. `names` keeps
identifiers **appeared** in the current closure and above. In an example
of the following cursor:
```ts
let x
async function foo() {
"use server"
let y
async function bar() {
"use server"
let z
console.log(x, y, z)
}
// <- cursor
}
```
`declared_idents` would be `y` (`x` isn't in a closure), and `names`
would be `x, y, z`. By manipulating these two states we're able to track
closure closed-up variables recursively.
Closes NEXT-2189
# Turbopack
* https://github.com/vercel/turbo/pull/7027 <!-- Donny/강동윤 - Update `swc_core` to `v0.87.28` -->
---
### What?
Update swc crates
### Why?
Required for #57718.
`styled-jsx` crate now has a hook to transform CSS code using a
Rust-side API
### How?
Fixes#57718
Closes PACK-2256
## What?
Implements https://github.com/vercel/turbo/pull/7081. Ensures image
imports in the edge runtime have the correct asset url. Previously it
would be `/assets/file.hash.png` but it should be
`/_next/static/media/file.hash.png`.
Updates the image tests to correctly compare the values in Turbopack and
the values in Webpack. Currently it only checks webpack values, causing
the tests to fail in Turbopack.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-2194
### Description
This PR refactors existing `analysis/get-static-page-info`, moves over
most of parse / ast visiting logic into next-swc's rust codebase. By
having this, turbopack can reuse same logic to extract info for the
analysis. Also as a side effect, this removes JS side parse which is
known to be inefficient due to serialization / deserialization.
The entrypoint `getPageStaticInfo` is still in the existing
`get-page-static-info`, only for extracting / visiting logic is moved.
There are some JS specific context to postprocess extracted information
which would require additional effort to move into.
Closes PACK-2088
This:
- Makes makes reporting hmr changes more accurate by emitting an
explicit start event and lowering the aggregation period for reporting
completed turbo tasks
- Parameterizes the aggregation period, allowing JS subscribers to
request different intervals, such as for the next-rs-api test
- Aligns path pattern with webpack by normalizing its layer names
- Fixes a bug in `drainAndGetNext` where the stream never could drain
past the first item
- Sends `client-hmr-latency` spans from Turbopack in both page and app
router pages
Closes PACK-2252
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
This PR fixes the issue where an inline Server Action gets exported. As
this isn't the designed use case for inline Server Actions (they're
supposed to be defined and used inside another closure, such as
components), we are not handling the export cases currently:
```ts
export async function action() {
"use server"
...
}
<form action={action}/>
```
...which gets compiled into:
```ts
export async function action() {} // No-op function
<form action={...actionReference...}/>
```
Note that everything works inside this module until you `import` that
action and use it in another module.
To tackle that, this PR changes how that works as described in
`server/27/output.js`.
Closes NEXT-2140
### What?
When webpack loaders are applied on a page file and it's renamed with
the `as` key, layout segment key no longer matches. This fixes that
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes PACK-2251
## What?
Skip postcss config resolving in node_modules for Turbopack. This
matches current Next.js on webpack closer as that only resolves the
postcss config from the project root. The additional feature Turbopack
has is that it can find a postcss config relative to the css being
compiled. This is useful for e.g. reducing the amount of overhead
certain postcss plugins that only have to run against a single file take
(i.e. Tailwindcss).
Depends on github.com/vercel/turbo/pull/7012 landing first.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Closes NEXT-2109
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
### What?
* creates a separate chunk group for client components per layout
segment (before it was per page)
### Why?
This fixes a bug with css loading on client transitions as next.js
assumes that the chunk group for the unchanged layout segments are
already loaded (fixes PACK-2163)
Closes PACK-2232
