We've rearchitected Next.js+Turbopack so Turbopack does not run
reimplement pieces of Next.js in its devserver. This:
- Removes the `next-dev` binary, which is no longer reachable through
`next --turbo`.
- Removes its test suite, as much of it is tested (and often more
thoroughly) by the Next.js test suite
- Removes its benchmark suite, which should be covered by
`Turbopack-bench` by
https://github.com/vercel/turbo/tree/main/crates/turbopack-bench
Test Plan: CI
Closes WEB-1652
Updated with new `Metadata` API.
Here in this example there is `legacy.tsx` in `/pages` folder should i remove it or retain it??
Also in `/pages/legacy.tsx` we have defined `/preact-stars` route but we don't have the corresponding file.
I have remove `/preact-stars` from `/app/page.tsx` as there is no `/app/preact-stars/page.tsx` in this example.
And `/shared/fetch-github-stars.ts` is fetching only `next.js` stars.
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
### What?
This PR fixes import source for turbopack's compiler.emotion config, mimics the current webpack configuration behavior.
Unfortunately this does not fixes the whole emotion transform with appdir yet, it looks like there are additional problems with server components.
Closes WEB-1655
This ensures we don't block sending the stream down when handling stale revalidates, in edge runtime we leverage the existing `waitUntil` handling and in node.js runtime we couple this into our pipe readable handling to wait to close the writable until after the promise resolves.
x-ref: https://github.com/vercel/next.js/issues/54193
If multiple weights or styles are requested, e.g. `Open_Sans({ weight: ['300', '400']})` or `Open_Sans({ style: ['normal', 'italic']})`, don't insert css rules for those properties.
Prior behavior was to insert the first ('300' or 'normal' in the above cases), which did not match webpack's behavior.
Closes WEB-1645
### What?
Fixing a little mistake in the documentation, where the placement of the `extension` option for `createMDX()` was described as being inside the `options` property:
```ts
const withMDX = createMDX({
options: {
extension: /\.mdx?$/,
```
But it's actually a property of its own:
```ts
const withMDX = createMDX({
extension: /\.mdx?$/,
```
I confirmed that the latter is correct because:
- It solves an issue I was having: Unable to import `.md` files
- On the same docs page, there's another place where it mentions this `extension` option and the code example is correct there
- The option is described in a similar issue, such as https://github.com/vercel/next.js/issues/45431#issuecomment-1410363864
Noticed a couple of directories had unit tests in `dist` which are being
run and reported during the Turbopack runs. These are generally quite
small so I'm not expecting this to have much effect on the package size
or CI runs, just making sure the data is correct.
<!-- 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 #
-->
- Related issues linked using fixes#55891
Wrap binaryPath, keyPath, certPath with double quotes
this with casing an error if there is a directory name has a space for ex. folder with name **test https**
Issue: https://github.com/vercel/next.js/issues/53888
Added "not-found.js" information to error.mdx after the `global-error.js`. Please approve.
Co-authored-by: Lee Robinson <9113740+leerob@users.noreply.github.com>
### What
#51394 introduced a pretty strict type of return value of route type
that causing failure with `next build`.
There're few ways of writing a app route, it could contain few return
values based on the usage:
* return a `Response` or promise of it
* return `NextResponse` of promise of it, since it's extended from
`Response`, same type
* use `redirect()` or `notFound(), since it returns `never`, and the
below code is not reached, the handler itself could still return void.
e.g. using `redirect` in a `GET` route
We loosed the type so `redirect()` can be still allowed without
specifying the return value there.
Related typescript issue:
https://github.com/microsoft/TypeScript/issues/16608#issuecomment-309327984
### How
* Re-enable the bail on types / build error in the app-routes tests
* Separate the tests, move runtime erroring ones to
`test/e2e/app-dir/app-routes-errors`
* Add new case to app-routes tests of mixed return value
Closes#55623
Related #55604
This fixes some scenarios where executing a server action after navigation can cause the action to behave incorrectly (double submitting, not resolving). There are two separate issues:
- `canonicalUrl` and `pendingNavigatePath` were not constructed using the same function (`createHrefFromUrl`) so in certain situations they'd be comparing different values
- a fulfilled inFlightServerAction should not be invoked again
Closes NEXT-1655
Closes NEXT-1654
Fixes#55845Fixes#55814Fixes#55805
This swaps the existing minifier for the Next.js runtime bundling from [terser](https://github.com/terser/terser) over to [swc](https://swc.rs/docs/configuration/minification). This small change has slightly decreased development file sizes, and dramatically decreased the time it takes to bundle the runtime. The results below were ran once on my MacBook Pro (M1 Pro).
## Compilation Speed
About 3 times faster
- `next_bundle_pages_dev`: improved from 7.28s to 1.85s.
- `next_bundle_pages_turbo`: improved from 7.28s to 1.85s.
- `next_bundle_pages_prod`: improved from 7.28s to 1.93s.
- `next_bundle_server`: improved from 7.28s to 2.68s.
- `next_bundle_app_turbo`: improved from 8.09s to 2.89s.
- `next_bundle_app_turbo_experimental`: improved from 7.74s to 2.77s.
- `next_bundle_app_prod`: improved from 7.86s to 2.77s.
- `next_bundle_app_dev`: improved from 9.41s to 2.86s.
- `next_bundle_app_prod_experimental`: improved from 8.01s to 3.12s.
- `next_bundle_app_dev_experimental`: improved from 9.11s to 3.58s.
- `next_bundle`: improved from 9.50s to 3.69s.
## File Sizes
About the same, small improvements in development bundle sizes
```shell
# Using terser
692K packages/next/dist/compiled/next-server/app-page-experimental.runtime.dev.js
460K packages/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js
460K packages/next/dist/compiled/next-server/app-page-turbo-experimental.runtime.prod.js
436K packages/next/dist/compiled/next-server/app-page-turbo.runtime.prod.js
672K packages/next/dist/compiled/next-server/app-page.runtime.dev.js
436K packages/next/dist/compiled/next-server/app-page.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route-experimental.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api-turbo.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.dev.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.prod.js
64K packages/next/dist/compiled/next-server/pages-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/pages.runtime.dev.js
64K packages/next/dist/compiled/next-server/pages.runtime.prod.js
204K packages/next/dist/compiled/next-server/server.runtime.prod.js
# Using swc
684K packages/next/dist/compiled/next-server/app-page-experimental.runtime.dev.js
460K packages/next/dist/compiled/next-server/app-page-experimental.runtime.prod.js
460K packages/next/dist/compiled/next-server/app-page-turbo-experimental.runtime.prod.js
436K packages/next/dist/compiled/next-server/app-page-turbo.runtime.prod.js
660K packages/next/dist/compiled/next-server/app-page.runtime.dev.js
436K packages/next/dist/compiled/next-server/app-page.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route-experimental.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo-experimental.runtime.prod.js
48K packages/next/dist/compiled/next-server/app-route-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/app-route.runtime.dev.js
48K packages/next/dist/compiled/next-server/app-route.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api-turbo.runtime.prod.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.dev.js
28K packages/next/dist/compiled/next-server/pages-api.runtime.prod.js
64K packages/next/dist/compiled/next-server/pages-turbo.runtime.prod.js
68K packages/next/dist/compiled/next-server/pages.runtime.dev.js
64K packages/next/dist/compiled/next-server/pages.runtime.prod.js
204K packages/next/dist/compiled/next-server/server.runtime.prod.js
```
### What?
Updates `run-test.js` to allow running individual test cases inside a test file.
### Why?
So that we can dramatically increase Turbopack's test coverage. Turbopack has implemented most (but not all) necessary features from the webpack bundles. But a single failing test case would prevent us from running any case inside a test file. With case filtering, we're able to run the cases we know will pass and prevent regressions on those.
### How?
Case filtering is only exposed via the `NEXT_EXTERNAL_TESTS_FILTERS` ENV, which points to a JSON file containing a map of test files with the test cases inside those files that are known to pass.
The known-passing test cases can be updated after Turbopack's daily integration test run by running `test/build-turbopack-tests-manifest.js`, which will update the `test/turbopack-tests-manifest.json` manifest.
Closes WEB-1640
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
```
Pages and Layouts
The Pages Router has a file-system based router built on the [concept of pages](https://nextjs.org/docs/pages/building-your-application/routing/pages-and-layouts).
```
Change requested:
Here `concept of pages` hyperlinks routes to the current page. This bit confusing for someone trying to learn next.js. removing the hyperlink to the text would make clear.
This:
- Updates to the latest api change for `StdError` in `error_generic_member_access` rust-lang/rust#99301
- Updates `pathfinder_simd` for compatiblity
Closes WEB-1636
### What?
This PR enables basic support for next.config.js's `distDir` config. PR have two main pieces, one for honoring distDir and construct output path other than `.next`, and secondly assign `process.env.__NEXT_DIST_DIR` to client / edge. The latter increased size of PR bit as had to downstream to the compile_define calls.
Corresponding tests are enabled to verify its behavior.
Closes WEB-1610