### What
Reland #64716
Removing the Suspense boundary on top of `next/dynamic` by default, make
it as `React.lazy` component with preloading CSS feature.
* Remove `suspense` option in `next/dynamic` since it's already
deprecated for a while
* Remove the default loading in app router implmentation of
`next/dynamic`
### Why
Extra Suspense boundary is causing extra useless rendering. For SSR, it
shouldn't render `loading` by default
Related: #64060
Related: #64687
Closes
[NEXT-3074](https://linear.app/vercel/issue/NEXT-3074/app-router-content-flickering-with-reactcreatecontext-and-nextdynamic)
This is sort of a breaking change, since removing the Suspense boundary
on top of `next/dynamic` by default. If there's error happening in side
the dynamic component you need to wrap an extra Suspense boundary on top
of it
### What
Provide a codemod to transform the promise of the access to named export
properties in dynamic import `next/dynamic`, this codemod transform all
the `next/dynamic` imports to ensure returning an object value with
`default` property, aligning with what `React.lazy` is returning
### Why
Follow up for #66990
It's not allowed to do dynamic import and access it's named export while
using `next/dynamic` in server component, and the dynamic import module
is from a client component. It's like accessing the nested client side
property of a module
### What
Add isEdgeRendering check condition for rewrite logic in edge adpator
Fixes#66837
Closes NEXT-3545
### Why
From headers `x-middleware-rewrite`, it's still relative url `/rewrite`,
reconstructing the url will lead to crash as it doesn't contain host.
### What
Render noindex into a flight data and rsc payload when page path is
`/404`
### Why
When it's static generation, noindex is not rendered due to the
statusCode from mock request is 200, but we can relying on the pagePath
as `/404` page should always contain `nonidex`
We were missing the noindex before for flight generation, now we'll
render it when it's 404 page.
### What
Show the full `pagePath` information for missing default component app
router convention files.
Move runtime error tests from `rsc-build-errors.test.ts` to the new test
`test/development/acceptance-app/undefined-default-export.test.ts`
### Why
Previously we only log `segment` which could be `[slug]` that is not
enough useful for users to locate the bad defined component
Bump conf to 13.0.0
I have changed the `moduleResolution` in tsconfig to `bundler` because
apparently the new versions of that dependency does not work with
`moduleResolution:node`, issues where it explains it: [issues in
conf](https://github.com/sindresorhus/conf/issues/181)
---------
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
What?
Updated blog-starter example to support dark theme. Also added a button
to switch modes (User preference).
→ User can opt for dark / light / system mode
→ Mode is persisted using localStorage
→ Mode is also synced across browsing contexts
→ No FOUC (Flash of Unstyled Content)
→ Full SSG
→ No additional dependency
Why?
Now that dark mode is a first-class feature of many operating systems,
it’s becoming more and more common to design a dark version of your
website to go along with the default design.
How?
- Used tailwind `dark:` modifier
- Used localStorage for persisting user's preference
- Used storage event to sync the mode across tabs/iframes
- Injected script to avoid FOUC
- Added appropriate comments in the code for clarity and readability
This PR adds a `.next/diagnostics` directory containing debug
information from during a build that can be used later on to debug the
build. The first use case is to output the exact Next.js version that
was used and to record information about the stage that the build failed
in and any options that were present.
This test was failing when deployed with _"Unsupported URL Type
"link:"._
This tweaks the linking behavior when deployed. I wasn't able to get
this test to pass when changing both `start` and deploy to use `link`.
When accessing search params, we only track dynamic access during static
generation. This has implications on fetch caching, because the fetch
cache relies on hints set during render that it's in a dynamic scope. In
15, this would signal that it should not attempt to cache the fetch at
all. In 14, this could impact the heuristic that bails from fetch cache
if dynamic access came before certain requests types, e.g. POSTs.
Currently webpack would be incorrectly used when some of the
experimental options for builds were enabled. For example
`parallelServerCompiles` and `parallelServerBuildTraces`. This ensures
Turbopack is always used when it's specified to be used.
Fixes around 100 Turbopack build 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 #
-->
Add support for `--dry` to the Next.js repo test runner, makes sure that
you can see all commands that are going to run before actually running
them.
Adds support for `--local` to strip some of the environment variables
that are entirely CI related.
<!-- 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?
Installing shadcn/ui after installing this example was a bad experience.
Running `npx shadcn-ui@latest init` overwrites existing files causing
errors and a confusing start.
This allows a installing shadcn/ui without these issues.
Co-authored-by: Sam Ko <sam@vercel.com>
...with `assertHasRedbox` and `assertNoRedbox`.
`hasRedbox()` has a hardcoded timeout of 5s that is only required for
the negative assertion.
Instead, we now have dedicated assertions for the positive
(`assertHasRedbox`) and negative case (`assertNoRedbox`).
The negative assertion still has the hardcoded timeout.
But the positive assertion just retries until we find the Redbox.
This speeds up tests using the positive assertion.
Removing `hasRedbox` also uncovered some unused expressions e.g. `await
hasRedbox(browser)`.
These expressions probably wanted to use `expect(await
hasRedbox(browser)).toBe(true)
## What?
This PR adds an option to use `sass-embedded`.
## Why?
For large projects sass-embedded improves SCSS compilation time by over
50%.
See also https://github.com/vercel/next.js/discussions/36160
## How?
Added a sassOption `implementation` to configure the sass-loader which
Sass implementation to use.
See also https://www.npmjs.com/package/sass-loader#implementation
I think this a similar approach to what is done for `additionalData`.
## Additional notes
In order to support `sass-embedded`, `sass-loader` is upgraded to
12.6.0.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
Writes the async flag to the client reference manifest to support ESM
externals in app dir.
The `app-ssr` context can't have esm externals as that might cause a
module to be async in ssr but not on the client.
Closes PACK-2967
Fixes#64525
