### What?
This modifies the static generation store to instead store a `url`
object with the `pathname` and `search` properties. This corrects the
previous behaviour which used the variable `urlPathname` which had
ambiguous meanings as it technically contained the search string as
well, not just the pathname.
In cases during the app render, this still grabs the contents of
`url.pathname + url.search` (where `url.search` always has a leading `?`
if it has any query parameters, [see the
docs](https://developer.mozilla.org/en-US/docs/Web/API/URL/search)) so
that it emulates the current behaviour. This allows more specific access
though, where now additional parsing can be eliminated which had to
strip the query string off of the `urlPathname` in a few places, and
more worrisome, still accidentally contained the search string causing
errors.
### How?
This requires an upstream fix (#64088) which corrected a bug with the
store access which had caused some previous test failures (accessing
`store.url.pathname` was throwing as `store.url` was undefined on the
wrong return, check the upstream PR for more details on that).
This also changes out usage of `pagePath` with `route`, and lets it be
the fallback (for debugging and error messaging). During static
generation, we will provide a value for the page being rendered that's
correlated to the particular file on the filesystem that the route is
based on:
```
// rendering app/users/[userID]/page.tsx
page: /users/[userID]
pathname: /users/1, /users/2, etc
```
The `route` is used only for debugging, such as when
`generateStaticParams` incorrectly calls `headers()`.
This also moves the pathname from the `staticGenerationStore` into the
`requestStore`, as it's tied to a given request.
Closes NEXT-2965
### What
Optimizing the static generation for dynamic metadata routes
If you're not using `generateSitemaps()` or `generateSitemaps()`, you
don't need to change any file conventions.
If you're using multi sitemap routes, make sure the returned `id`
properties from `generateSitemaps()` don't need to contain `.xml`, since
we'll always append one for you.
Analyzing the exports of metadata routes and determine if we need to
make them as dynamic routes.
### Why
Previously, users are struggling with the multi routes of sitemap or
images.
For sitemap, the `.xml` extension in url doesn't get appended
consistently to the multi sitemap route between dev and prod.
For image routes, the generated image routes are always dynamic routes
which cannot get static optimized.
The reason is that we need to always generate a catch-all route (such as
`/icon/[[...id]]` to handle both single route case (e.g. without
`generateImageMetadata`, representing url `/icon`) or multi route (e.g.
with `generateImageMetadata`, representing url `/icon/[id]`), only
catch-all routes can do it. This approach fail the static optimization
and make mapping url pretty difficult as parsing the file to check the
module exports has to be done before it.
#### Benifits
For image routes urls, this approach could help on static generation
such as single `/opengraph-image` route can be treated as static, and
then it can get static optimized if possible.
**Before**: `/opengraph-image/[[...id]]` cannot be optimized
**After**: single route `/opengraph-image` and multi-route
`/opengraph-image/[id]` are both possible to be statically optimized
For sitemap, since we removed appending `.xml` for dynamic routes, it’s
hard for users to have `/sitemap.xml` url with dynamic route convention
`sitemap.js` . But users desire smooth migration and flexibility.
**Before**: In v15 rc we removed the `.xml` appending that `sitemap.js`
will generate url `/sitemap` makes users hard to migrate, as users need
to re-submit the new sitemap url.
**After**: Now we'll consistently generate the `.xml`. Single route will
become `/sitemap.xml`, and multi route will become `/sitemap/[id].xml`.
It's still better than v15 as the urls generation is consistent, no
difference between dev and prod.
Here's the url generation comparsion
#### Before
All the routes are dynamic which cannot be optimized, we only had a
hacky optimization for prodution build multi-routes sitemap routes
| | only default export | `export generateImageMetadata()` | `export
generateSitemaps()` |
| -- | -- | -- | -- |
| opengraph-image.js | /opengraph-image/[[...id]] |
/opengraph-image[[...id]]/ | /opengraph-image/[[...id]] |
| sitemap.js | /sitemap/[[...id]] | /sitemap/[[...id]] | dev:
`/sitemap/[[...id]]` prod: `/sitemap/[id]` |
#### After
Most of the single route will are to get statically optimized now, and
the multi-routes sitemap are able to get SSG now
| | only default export | `export generateImageMetadata()` | `export
generateSitemaps()` |
| -- | -- | -- | -- |
| opengraph-image.js | /opengraph-image | /opengraph-image/[id] | - |
| sitemap.js | /sitemap.xml | - | /sitemap/[id].xml |
Next.js will have less overhead of mapping urls, we can easily multiply
the urls generation simply based on file conventions.
x-ref: feedback from #65507Closes#66232
This PR fixes the same case mention in #66464. Instead of collecting all
values eagerly, here we merge fields (on any level of depth) of the same
value and skip methods. For example:
```ts
foo.bar
foo.bar.baz
qux.fn()
```
Previously we're (wrongly) collecting `[foo.bar, foo.bar.baz, qux.fn]`,
and now it will be just `[foo.bar, qux]`.
Merging of fields is critical for collecting methods correctly because
in theory we can't tell if an object member is a method or not:
```ts
data.push.call(data, 1)
// or inside a function that does the same:
doPush(data.push, data)
```
If we don't merge fields we'll collect `[data.push, data]` which still
fails.
This removes the previous `server/future` directory and moves everything
into the `server` or `server/lib` directories. This is aimed to start to
flatten the server application structure.
### What?
optimize allocations in server actions transform
In one edge case it reduces allocations from 30GB to 4.5MB and time from
760ms to 11ms.
### Why?
make it faster
Effectively a revert of https://github.com/vercel/next.js/pull/66006,
but:
- Keeps the cleanup changes from that PR.
- With https://github.com/vercel/nextpack/pull/106 removing the explicit
`--features plugin` flag, we will match behavior between cargo's
defaults and the nextpack development scripts (which we want to do for
maximizing cache reuse).
The tradeoff here is faster cold builds, at the cost of waiting longer
when you want to test with plugins.
Feedback from @kdy1 was:
> I think it's a good idea to disable plugin by default for nextpack. We
don't use it for most of daily development, but it's very large and slow
to compile
Tested by running both:
```
pnpm build-native
pnpm build-native-no-plugin
```
### What
Use `next-flight-loader` to transform the client components into client
reference in middleware and instrumentation.
Add related required webpack aliases, such as alias for
`react-server-dom-webpack`
### Why
issue reported in
https://github.com/vercel/next.js/pull/65424#issuecomment-2128902585
