Fixes#64018
Adds support for modern configurations introduced in TS 5.4
Expected output: not modifying the `module`, `esModuleInterop` configs
since `module: preserve` is present
```
We detected TypeScript in your project and reconfigured your tsconfig.json file for you. Strict-mode is set to false
by default.
The following suggested values were added to your tsconfig.json. These values can be changed to fit your project's n
eeds:
- lib was set to dom,dom.iterable,esnext
- allowJs was set to true
- skipLibCheck was set to true
- strict was set to false
- noEmit was set to true
- incremental was set to true
- include was set to ['next-env.d.ts', '**/*.ts', '**/*.tsx']
- exclude was set to ['node_modules']
The following mandatory changes were made to your tsconfig.json:
- isolatedModules was set to true (requirement for SWC / Babel)
- jsx was set to preserve (next.js implements its own optimized jsx transform)
```
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What?
Emit `<link data-next-font="size-adjust" rel="preconnect" href="/"
crossorigin="anonymous"/>` in more cases.
### Why?
To align with the default mode
### How?
This is a hotfix since it breaks `next lint`, I'll start to implement
eslint v9 for canary.
x-ref: #64114
x-ref: [eslint v9
release](https://github.com/eslint/eslint/releases/tag/v9.0.0)
Fixes#64136
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
## What?
When creating the Next.js instance fails for whatever reason (most
commonly `next build` failing) it currently exits the process, this
causes Jest to not report these tests as failed.
The change in this PR ensures that anytime creating the instance fails
it throws an error that is caught by Jest and then causes Jest to report
the tests as failed.
The reporting of tests is relevant as our monitoring tools (i.e. DataDog
/ Turbopack test manifest) rely on correct reporting of all failing
tests.
<!-- 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-3016
Next creates an alias for `@opentelemetry/api` to a prebundled version
[here](a9f85d14c0/packages/next/src/build/create-compiler-aliases.ts (L108-L110)).
However, there's a bug in `hasExternalOtelApiPackage` - it currently
always fails to remove `@opentelemetry/api/package.json` because it's
not one of the exports.
## What?
There's a bug currently that shows the "webpack has been configured"
warning incorrectly:
```
pnpm next dev --turbo examples/hello-world
> nextjs-project@0.0.0 next /Users/timneutkens/projects/next.js
> cross-env NEXT_TELEMETRY_DISABLED=1 node --trace-deprecation --enable-source-maps packages/next/dist/bin/next "dev" "--turbo" "examples/hello-world"
▲ Next.js 14.2.0-canary.58 (turbo)
- Local: http://localhost:3000
✓ Starting...
✓ Ready in 791ms
⚠ Webpack is configured while Turbopack is not, which may cause problems.
⚠ See instructions if you need to configure Turbopack:
https://nextjs.org/docs/app/api-reference/next-config-js/turbo
```
This PR ensures the warning is only shown when you have actually
configured `webpack` in `next.config.js`.
<!-- 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-3013
<!-- 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 #
-->
### What?
Primarily, this is fixing the code highlighted here:
073cd74433/packages/next/src/server/lib/patch-fetch.ts (L228-L230)
As `(fetch as any).__nextGetStaticStore?.()` returns
`StaticGenerationAsyncStorage | undefined`, and not
`StaticGenerationStore`. A call to `.getStore()` as the previous line
does corrects this issue.
Secondarily, this improves the `as any` type access being done on the
patched fetch object to make it more type safe and easier to work with.
Since this was added, some features like the `.external` files were
added that allowed files to import the correct async local storage
object in client and server environments correctly to allow for direct
access. Code across Next.js no-longer uses this mechanism to access the
storage, and instead relies on this special treated import.
Types were improved within the `patch-fetch.ts` file to allow for safer
property access by adding consistent types and guards.
### Why?
Without this change, checks like:
073cd74433/packages/next/src/server/lib/patch-fetch.ts (L246)
Always fail, because when `(fetch as any).__nextGetStaticStore?.()`
returns `StaticGenerationAsyncStorage`, it isn't the actual store, so
the type is wrong.
Closes NEXT-3008
Previously, the `serve-static` utility function in Next.js would
determine which codepath to use based on the version of `mime` **for
every incoming request**. The PR changes so that the codepath **will be
determined in advance**, thereby reducing the overhead.
When adding refresh markers for refetching segments that are "stale"
(the soft navigation case where they are still in the Router State Tree
but not part of the page that we're rendering), they only contained a
reference to the pathname. Once the actual refresh was triggered we
added the current search params to the request.
However, this causes an issue: segments in the `FlightRouterState` can
contain searchParams (ie, `__PAGE__?{"foo": "bar}` is what the segment
becomes when adding `?foo=bar` to a page). This means that when we
refresh those nodes from the server, it won't know how to find the
`CacheNode` for the stale segment since we won't have them in the
refetch tree. This updates to keep a reference to the searchParams that
were part of the request that made it active.
While fixing this, I also noticed that we were missing a spot to add the
refetch marker in `applyRouterStatePatchToTree` in the case of a root
refresh (caught by these tests failing in PPR)
[x-ref](https://github.com/vercel/next.js/discussions/63900#discussioncomment-9002137)
<!-- 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-3007
This documents the behavior introduced in #62856 to allow globally
overriding the router cache invalidation period.
`static` and `dynamic` in this case refer to variable levels of
"liveness" and are unrelated to whether the segment itself is opting
into static or dynamic rendering. In other words, the current `dynamic`
default of 30s suggests that we consider the 30s delta to feel dynamic
while still providing some caching for performance reasons. Others might
prefer a value of 0s here, hence the configuration.
<!-- 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-2995
This adds an experimental flag to allow testing preloading all server
chunks including webpack chunks during the server initialization. It is
disabled by default and only opt-in for experimenting.
Closes NEXT-3005
### What?
Fixes#61611
### Why?
Any one having custom server may be having logic to set cookies during
GET requests too. Currently nextjs in app directory does not allow to do
so but with custom server its very much possible.
### How?
By merging cookies of redirect response and server action POSt response
### Tests
I have added one more test to existing suite and it passing with fix in
place.
### Notes
This bug is reproducible only if developer has custom server on top of
next app but still very probable
---------
Co-authored-by: Shu Ding <g@shud.in>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
Fix the status code in static generation metadata for `/_not-found`
route, aligning it as 404 for both dev and build
### Why
`/_not-found` route should still return 404 code as it's reserved as
default not found route
Closes NEXT-3001
The docs make a distinction between prefetch behavior based on
static/dynamic data but this is not how it's implemented. The correct
heuristic is based on the `prefetch` prop. The original PR describing
this behavior can be found in #48383.
This clarifies how the prefetch prop influences the invalidation period,
and how `loading.js` influences the prefetch response.
<!-- 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-2994
### What?
Match on `pages_api_unknown-domain-no-await_.*?\.js/` instead of
`/at.+\/pages\/api\/unknown-domain-no-await.js/`
### Why?
Turbopack generates a different chunk path for js files. This PR fixes
one integration test case.
### How?
Closes PACK-2883
### What?
Print an error message to stdout if stylesheet fetching fails.
### Why?
To align behavior with the default mode. This PR fixes one integration
test case.
### How?
Closes PACK-2896
> Note: Did not add additional tests or make many changes to the utils,
possible refactoring on the following PR.
This PR split the legacy tests into four sections to improve the
maintenance and concurrency of CNA tests:
- `prompts`: target prompt interactions. `Y/n`
- `examples`: target `--example` and `--example-path` flags.
- `templates`: target the flag values such as `--app`, `--eslint`, etc.
- `package-manager`: target package managers: npm, pnpm, yarn, bun
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
