### What?
Converts every test under `test/integration/` to an isolated test
running through `nextTestSetup` (under `test/e2e/`, `test/production/`,
`test/development/`, or `test/unit/`), then deletes `test/integration/`
along with the legacy CI orchestration that was specific to it.
- `test/integration/` removed entirely (~327 test suites)
- New isolated suites added across the existing folders:
- `test/e2e/` — 175
- `test/production/` — 130
- `test/development/` — 43
- `test/unit/` — 1
- `.github/workflows/build_and_test.yml` and `run-tests.js` no longer
have any `integration` branches
- `nextTestSetup` gained a `baseUrl` option on `next.browser()` so a
small number of tests that drive their own proxy/static-export server
can keep using `next.browser(...)` instead of importing `next-webdriver`
directly
### Why?
`test/integration/` predated `nextTestSetup` and ran tests directly
against the source checkout via custom helpers (`launchApp`,
`nextBuild`, `nextStart`, `runNextCommand`, `webdriver`, `fetchViaHTTP`,
…). Each suite hand-rolled its own dev/start/build orchestration,
fixture mutation, and process management.
The isolated test model used by the rest of the repo gives each suite an
isolated working directory containing a packed `next.tgz` install, a
uniform `next.start()` / `next.build()` / `next.fetch()` /
`next.browser()` API, and the same lifecycle for dev, start, and deploy
modes — so a single set of assertions covers all three. Deploy-mode
skips and per-feature gates are expressed declaratively
(`skipDeployment`, `disableAutoSkewProtection`, `if (skipped) return`)
instead of branching on `process.env`.
Removing `test/integration/` lets us:
- Delete the bespoke orchestration code in the CI workflow and
`run-tests.js`
- Run every converted suite consistently in dev, start, and deploy modes
(where applicable)
- Reproduce every test locally with the same `pnpm
test-{dev,start}-{turbo,webpack}` commands; no separate `integration`
path
- Open the door to running `test/production` against deployments in the
future (the converted suites already declare `skipDeployment` so they
can be flipped on)
### How?
Mechanical conversion per suite, with targeted clean-ups:
1. **Per-suite conversion.** Each
`test/integration/<name>/test/index.test.{js,ts}` was rewritten into a
single `<name>.test.ts` under the right folder based on what the
original exercised:
- `launchApp` / dev-only assertions → `test/development/`
- `nextBuild` + `nextStart` / start-only assertions → `test/production/`
- Both → `test/e2e/`
- The one pure jsdom render check (`link-without-router`) → `test/unit/`
2. **API mapping.** Custom helpers were replaced by `nextTestSetup`
equivalents: `launchApp` → `next.start()`, `nextBuild` → `next.build()`,
`runNextCommand` → `next.runCommand`, `fetchViaHTTP` → `next.fetch`,
`webdriver(...)` → `next.browser(...)`. Fixture mutations switched from
raw `fs.writeFile`/`fs.rename` to `next.patchFile` (with the 3-arg
`runWithTempContent` callback when the change has a defined scope) and
`next.deleteFile`.
3. **Deploy-mode handling.** Suites that can't run in deploy mode (use
`patchFile` / `next.build()` / depend on local CLI output) declare
`skipDeployment: true` and early-return on the `skipped` boolean. Suites
where Vercel's edge mutates URLs (`&dpl=`, immutable assets) declare
`disableAutoSkewProtection: true`.
4. **`next.browser({ baseUrl })`.** A handful of tests
(`prerender-export`, `cdn-cache-busting`, `preload-viewport`, both
`react-virtualized` suites) need to drive a separate server (a
static-export server or an `http-proxy` instance) rather than the
Next.js process. Instead of importing `next-webdriver` directly, those
tests now pass `{ baseUrl: <port|url> }` to `next.browser()`. For the
proxy cases, the proxy was moved into `server.js` inside the fixture and
`http-proxy` declared via the `dependencies` option of `nextTestSetup`,
so the test runs with a fully isolated dependency graph.
5. **CI clean-up.** With `test/integration` gone, the `test
integration*` jobs and `integration-tests-manifest`-related logic in
`.github/workflows/build_and_test.yml` were removed, and `run-tests.js`
no longer has the `integration` test-folder branch.
6. **Validation.** The PR was iterated against multiple full CI runs;
the remaining failures on the latest run are pre-existing flakes
(segment-cache 60s `act` timeouts in turbopack-prod) or transient
infrastructure issues unrelated to the conversion.
### What?
Adds a new \`get_compilation_issues\` MCP tool (and the underlying
\`projectGetAllCompilationIssues\` NAPI method) that returns all
compilation issues from all routes in a single call.
**New files:**
- \`crates/next-napi-bindings/src/next_api/project.rs\` —
\`project_get_all_compilation_issues\` NAPI function +
\`get_all_compilation_issues_operation\` /
\`get_all_compilation_issues_inner_operation\` turbo-tasks operations
- \`packages/next/src/server/mcp/tools/get-compilation-issues.ts\` — MCP
tool implementation
-
\`packages/next/src/server/mcp/tools/utils/format-compilation-issues.ts\`
— output formatter
-
\`test/development/mcp-server/mcp-server-get-compilation-issues.test.ts\`
— e2e test
- \`test/development/mcp-server/fixtures/compilation-errors-app/\` —
fixture app with three routes (valid page, missing-module error, syntax
error)
**Modified files:**
- \`packages/next/src/build/swc/generated-native.d.ts\` + \`types.ts\` +
\`index.ts\` — expose the new NAPI method
- \`packages/next/src/server/mcp/get-or-create-mcp-server.ts\` —
register the new tool, accept \`getTurbopackProject\` option
- \`packages/next/src/server/dev/hot-reloader-turbopack.ts\` — pass
\`project\` to MCP middleware
- \`packages/next/src/telemetry/events/build.ts\` — add
\`'mcp/get_compilation_issues'\` to the \`McpToolName\` union
### Why?
The existing MCP tools require a browser session (and thus a specific
route to be rendered) to surface compilation errors.
\`get_compilation_issues\` works without a browser session and covers
all routes proactively — useful for AI coding agents that want to check
for errors across the whole app before trying to render a page.
### How?
**NAPI layer:**
\`project_get_all_compilation_issues\` calls a two-level turbo-tasks
operation pair:
1. \`get_all_compilation_issues_inner_operation\` — iterates all
endpoint groups via \`project.get_all_endpoint_groups(false)\` and calls
\`endpoint_group.module_graphs().as_side_effect()\` on each. This builds
the module graph (resolution + transformation) for every entrypoint
without chunking, emitting, or code generation. Issues are emitted as
turbo-tasks collectables.
2. \`get_all_compilation_issues_operation\` — wraps the inner op in
\`strongly_consistent_catch_collectables\` to harvest
issues/diagnostics/effects, then returns an \`OperationResult\`.
> **Why not \`project.whole_app_module_graphs()\`?**
> \`whole_app_module_graphs()\` calls \`drop_issues()\` in development
mode to prevent every per-route HMR subscription from seeing all global
issues. Calling it here would return zero issues in dev. Per-endpoint
\`module_graphs()\` calls don't have this suppression.
**Output formatting (\`format-compilation-issues.ts\`):**
The raw Turbopack wire types are transformed before being returned to
MCP consumers:
- **StyledString → plain string**: \`title\`, \`description\`, and
\`detail\` are \`StyledString\` union trees (recursive \`{type, value}\`
objects). These are flattened to plain strings —
\`text\`/\`code\`/\`strong\` variants return their \`.value\` directly,
\`line\` joins with \`""\`, \`stack\` joins with \`"\n"\`.
- **ANSI codes stripped**: \`codeFrame\` is a pre-rendered string from
the Rust NAPI layer that contains ANSI terminal colour codes. These are
stripped via \`next/dist/compiled/strip-ansi\`.
- **1-indexed source positions**: Turbopack's \`SourcePos\` is 0-indexed
for both \`line\` and \`column\`. The formatter adds \`+1\` to each so
consumers get the conventional editor-style 1-indexed values.
- **Deduplication**: the same issue can surface from multiple endpoints
during the module graph traversal. Issues are deduplicated by a
\`severity|filePath|title|startLine:startCol\` key.
- **No diagnostics**: Turbopack diagnostics are internal telemetry
(\`EVENT_BUILD_FEATURE_USAGE\` feature-adoption counters). They are not
actionable for the user, so the \`diagnostics\` field is omitted
entirely from the response.
**MCP tool (\`get_compilation_issues\`):**
Calls \`project.getAllCompilationIssues()\`, passes the issues through
\`formatCompilationIssues()\`, and returns \`{ issues: FormattedIssue[]
}\` as JSON. Works without a browser session.
**Test:**
A fixture app with three routes (valid \`app/page.tsx\`,
\`app/missing-module/page.tsx\` importing a non-existent package,
\`app/syntax-error/page.tsx\` with unclosed JSX) is used to verify:
1. The tool returns a result without any browser session
2. Module-not-found errors are detected
3. Syntax errors are detected
4. Issues include \`severity\`, \`title\`, \`filePath\` metadata — all
as plain strings (not StyledString objects)
e2e tests: added —
\`test/development/mcp-server/mcp-server-get-compilation-issues.test.ts\`
---------
Co-authored-by: Tobias Koppers <[email protected]>
Co-authored-by: Claude <[email protected]>
## What?
This PR improves CSS parsing error handling in Turbopack by making parse errors recoverable instead of fatal.
1. **Extracting CSS parsing logic** into a new `parse_css_stylesheet` function that handles both parsing and CSS module validation in one place
2. **Fixing error recovery** when CSS minification fails — instead of immediately returning an unparsable result, the code now re-parses the original CSS to recover valid styles
3. **Improving error reporting** by renaming variables for clarity (`source` → `issue_source`) and ensuring errors are properly emitted before attempting recovery
4. **Adding comprehensive tests** for CSS parse error scenarios with both snapshot tests and e2e tests
The snapshot test fixture exercises several CSS features to confirm they survive error recovery:
- Basic selectors (`.before`, `.after`) — valid rules are preserved when surrounded by invalid ones
- `::highlight(highlight-test)` — CSS Custom Highlight API pseudo-element
- `scroll-marker-group`, `::scroll-marker`, `::scroll-marker:target-current` — CSS scroll marker pseudo-elements (new spec)
- `oklch()` color values — converted to `#rrggbbaa` + `lab()` fallbacks for broader browser compatibility
## Why?
Previously, when CSS minification encountered an error, the entire stylesheet would be marked as unparsable, losing any valid CSS that could have been recovered. This meant `turbopackIgnoreIssue` could not suppress the errors since the module produced no output regardless.
Now, when lightningcss recovers from parse errors (collecting them as warnings), issues are still emitted but processing continues with the recovered stylesheet. Only truly fatal parse errors (where `StyleSheet::parse` returns `Err`) remain non-recoverable.
The refactoring also consolidates CSS validation logic into a single function, reducing code duplication and making the error handling flow clearer.
## How?
- Created `parse_css_stylesheet()` function that wraps `StyleSheet::parse()` and applies CSS module validation
- Modified error handling in `process_content()` to call the new function and recover from minification errors by re-parsing
- Changed early returns to error emission followed by recovery attempts
- Added test fixtures and e2e tests to verify CSS parse error recovery works correctly
- Added snapshot tests showing expected output when CSS contains parse errors (valid rules are preserved, invalid ones are skipped)
- Skipped CSS parse error recovery e2e tests for webpack (webpack has its own CSS pipeline)
## Test Plan
- Added e2e tests in `css-parse-error-recovery.test.ts` that verify:
- Pages with CSS parse errors still render when using `turbopackIgnoreIssue` config
- Parse errors are properly reported in CLI output
- Added snapshot tests showing CSS output with parse errors, including modern CSS features (`::highlight`, `scroll-marker-group`, `oklch()` color conversion)
- Existing CSS tests continue to pass
# What
Add an ast-grep rule to use `bail!` rather than `Err(anyhow!(` in a
return position.
# Why
This is slightly more compact, and allows us to port more code over to
turbofmt/turbobail.
Note: _this PR was previously merged into another branch due to a GH
bug_
Add support for the `--debug-build-paths` flag in Turbopack builds. Previously this flag only affected which routes were prerendered (statically generated), but the bundler still compiled all routes.
Now routes are filtered early in `Project::entrypoints()`, so excluded routes are never compiled by Turbopack. Framework routes like `/_not-found` and `/_error` are always included to ensure the runtime works correctly.
This significantly reduces build times in large apps when building individual routes for debugging purposes. It also allows us to exclude building incompatible paths in end-to-end tests depending on whether `__NEXT_CACHE_COMPONENTS` is defined or not (see upstack PR).
### What?
Adds a Claude Code plugin marketplace to the Next.js repository with an
initial `cache-components` plugin that provides expert guidance for
Cache Components and Partial Prerendering (PPR).
### Why?
Cache Components introduces a new programming model that combines
Partial Prerendering, Dynamic I/O, and the `"use cache"` directive. Team
members and contributors need guidance on:
- The `'use cache'` directive and its variants (`private`, `remote`)
- Cache lifetime configuration with `cacheLife()` and predefined
profiles
- Cache tagging and invalidation with `cacheTag()`, `updateTag()`,
`revalidateTag()`
- Parameter permutation rendering and subshell generation with
`generateStaticParams`
- Migration from deprecated `revalidate` and `dynamic` segment configs
- Build-time error resolution (dynamic data outside Suspense, uncached
data, etc.)
A Claude Code plugin allows this knowledge to be distributed directly
from the repo and proactively activated when working in projects with
`cacheComponents: true`.
### How?
Introduces the `.claude-plugin/` directory structure:
```
.claude-plugin/
├── marketplace.json ← Marketplace catalog (name: "nextjs")
└── plugins/
├── README.md ← Documentation for adding plugins
└── cache-components/
├── .claude-plugin/plugin.json ← Plugin manifest
├── README.md ← Plugin documentation
└── skills/cache-components/
├── SKILL.md ← Core concepts, mental model (496 lines)
├── REFERENCE.md ← API reference, migrations (875 lines)
├── PATTERNS.md ← 12 production patterns (781 lines)
└── TROUBLESHOOTING.md ← Build errors, debugging (721 lines)
```
**Installation:**
```bash
/plugin marketplace add vercel/next.js
/plugin install cache-components@nextjs
```
**Key skill features:**
- **Proactive activation** when `cacheComponents: true` is detected in
next.config
- **Mental model decision tree** for thinking through caching decisions
- **Cache scope clarification** explaining what creates new cache
entries
- **updateTag vs revalidateTag guide** with decision table and examples
- **Migration scenarios** from deprecated `revalidate`/`dynamic` segment
configs
- **Quick debugging checklist** for common cache issues
- **Parameter permutation rendering** (how `generateStaticParams`
creates subshells)
- **12 production patterns** including e-commerce, multi-tenant SaaS,
and subshell composition
### Documentation Highlights
| Section | Description |
|---------|-------------|
| Mental Model | Decision tree for when to use `'use cache'`, `'use
cache: private'`, or `<Suspense>` |
| Cache Scope | What creates new cache entries (function identity,
arguments, file path) |
| updateTag vs revalidateTag | Decision guide with e-commerce examples |
| Migration Scenarios | Before/after examples for `revalidate`,
`force-dynamic`, and ISR patterns |
| Quick Debugging Checklist | Copy-paste checklists for common issues |
Flagged behind `experimental.strictRouteTypes`
This fixes issues where cache profiles where not included or routes not validated if `.next` was excluded to squeeze out every bit of TypeScript performance.
It also fixes a redundant type-check since we have separate dev and prod dist folders. If you run `next dev` and (`next build` or `next typegen`), you'd type-check routes and links twice. Now `next-env.d.ts` only exists once where we decide which dist folder to type-check.
Going forward, new Next.js type-checking should be added to `next-env.d.ts`. That file is fully controlled by Next.js and churning it, does not churn users since it's not in version control.
`next-env.d.ts` will be moved into `.next` in a follow-up. Ideally independent of the dist folder i.e. independent of `next dev` vs `next build`.
Closes https://linear.app/vercel/issue/NXT-124/https://github.com/vercel/next.js/pull/87319 but flagged.
`no_early_errors: true` was causing parse errors to be discarded.
For example with https://github.com/swc-project/swc/issues/11142 where there was a parse error (though it was a bug in this case), that left a `Invalid` AST node in the output, which only broke minification/SSG later on in the build (and potentially would have resulted in some error at runtime, if that specific chunk was never executed during SSG).
Enables AI agents to programmatically access the runtime/build errors
from the current devtool overlay of a dev session. The errors are
pretty-printed by default with source-mapped stack frames. In
particular, it supports pulling error information from multiple browser
tabs.
What?
This PR updates the dependency "prettier" from version 3.2.5 to version
3.6.2. It also modifies other scripts by using the pnpm run prettier-fix
after updating the dependency.
Why?
This is updated to benefit from the changes and fixes introduced in the
newer versions of prettier, from versions 3.3 to 3.6.
How?
The package has been updated using pnpm install prettier@latest, and the
files other than package.json and pnpm-lock.json have been modified
using the script pnpm run prettier-fix.
This PR does only have formatting changes introduced by the updated
dependency
This PR is the same as #82719 , with fixes implemented to prevent
prettier to modifiy symlink files
Closes PACK-4881
Previously, you'd get both a `Parsing ecmascript source code failed`
error and a `export Abc was not found in module` error if anything
imported from the module with the parse error (because it had
`EcmascriptExports::None` in that case).
Enable Turbopack to merge modules together (when possible), getting rid of the `"module id...": (__turbopack_context__) => { ... __turbopack_esm_export__({foo: () => foo})` overhead:
<img width="1591" alt="Bildschirmfoto 2025-06-14 um 14 13 36" src="https://github.com/user-attachments/assets/b6baccbe-a2c7-4acd-b17b-f7bd91c8f349" />
## Details
There is a lot of complexity here, mostly for the problem of when this is actually safe to do.
Generally, modules can only be merged if they are known to always execute in that exact order (also meaning in every chunk these modules are part of).
This is done by first propagating a bitmap on the whole module graph, to determine which modules are safe to merge together (module type is compatible, only ESM, etc). Then, these potential merged groups are linearized in execution order _per chunk_. These orderings are then split up until every module is just part of a single ordering (together with the modules that are always executed before/after it, if any). Each of these orderings then becomes a merged module.
This information is then used to replace these modules with the merged version in the middle of chunking (after the module graph -> vec of modules step, but before turning vec of modules -> vec of chunks).
For code generation, the runtime helpers are omitted and imports just become straight variable references (i.e. across modules). This (together with preventing local variable naming collisions in the merged module) is achieved by leveraging swc's syntax contexts (each module effectively gets it's own syntax context, so that variables of the same name don't collide, and then imports are rewritten to point to the local variable in the other module). Comments and source maps work by encoding the module into the `BytePos`, so that a given `BytePos` in the merged AST can be decoded back into the module that it originated from, to lookup comments and source locations in the right structs.
Enable prettier for turbopack
While the majority of the javascript in turbopack is for tests, this code is generally hand authored so prettier will help us. There are also core parts of turbopack implemented in JavaScript/TypeScript so a formatter will help.
This was done by simply fixing prettier ignore and chasing lint errors. There were a few fun issues
* We had a test file called `won't-run-tla.js` and this triggered a bug in our eslint precommit hook. The simplest thing was to simply drop the `'` character so that is what i did. I spent a small amount of time trying to narrow this down't in the `lint-staged` dependency but failed, so i think the problem is probably in `eslint`, but it isn't really clear.
* We had another test exercising `import.meta` but in a file called `.cjs`, which prettier rejects due its default `babel` parser. So i excluded this from prettier.
### What & Why
It's common to have top-level "dynamic" params that remain constant (as "global" or "root" params) regardless of where you are within a root layout. For example, `[lang]` or `[locale]`, regardless of where you are in that layout that param will be available. We should provide a more convenient way to access these params without requiring it to be plumbed through ALS or context.
### How
This introduces a new API, `unstable_rootParams`, that will return all segment params up to and including the [root layout](https://nextjs.org/docs/app/api-reference/file-conventions/layout#root-layouts). In other words:
`/app/[foo]/[bar]/layout.tsx` -> `{ foo: string, bar: string }`
`/app/[foo]/[bar]/[baz]/page.tsx` -> `{ foo: string, bar: string }` (`baz` is not included here since the root params up to the root layout were just `foo` & `bar`.
This also supports the case of having multiple root layouts. Since navigating between a root layouts will trigger an MPA navigation, we're still able to enforce that those params will not change.
This PR also includes some work to the types plugin generate types for root params because they can be statically determined ahead of time. For example, in the above example, `unstable_rootParams()` will be typed as `Promise<{ foo: string, bar: string }>`.
In the case where there are multiple root layouts, it gets a bit more nuanced. e.g. at build time we aren't able to determine if you're going to be accessing rootParams on root layout A or root layout B. For this reason, they'll become optionally typed, eg: `Promise<{ foo?: string }>` where `foo` might only be available on the `/app/(marketing)/[foo]/layout.tsx` root.
This feature is experimental and under active development and as such, is currently exported with an `unstable` prefix.
This PR has two main goals:
- **Consolidate the detection of server directives in modules and function bodies.** Previously, these were two separate implementations with significant overlap, but also some [questionable discrepancies](https://github.com/vercel/next.js/pull/72811#discussion_r1843660381).
- **Model the current directive (in a file or function) using an enum instead of two separate booleans.** This change prevents any confusion that both directives might be present simultaneously. Additionally, we're now emitting an error if multiple directives (`"use server"` and `"use cache"`) are defined in the same location (at the top of a file or function body).
A mixed usage of `"use server"` and `"use cache"` _across different locations_ is still allowed, e.g. `"use cache"` at the top of a file, and `"use server"` in a function.
> [!NOTE]
> The diff may be tricky to review because chunks from two different functions are combined into a single function. Fortunately, we have comprehensive test coverage for the transforms, which instills high confidence that these changes are correct.
## What?
- Changes webpack output target to `es6` (required for `async function`
output)
- Adds tests for top level await in server components and client
components (App Router)
- Converted the async-modules tests to `test/e2e`
- Has one skipped test that @gnoff is going to look into. This shouldn't
block merging this PR 👍
Adds additional tests for top level `await`.
Since [Next.js
13.4.5](https://github.com/vercel/next.js/releases/tag/v13.4.5) webpack
has top level await support enabled by default.
Similarly Turbopack supports top level await by default as well.
TLDR: You can remove `topLevelAwait: true` from the webpack
configuration.
In writing these tests I found that client components are missing some
kind of handling for top level await (async modules) so I've raised that
to @gnoff who is going to have a look.
<!-- 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-3126
Fixes https://github.com/vercel/next.js/issues/43382
### What?
This PR improves turbopack documentation, mostly collects existing
documents into a single place.
Also, adds a support to render mermaid diagram.
Closes PACK-2488
### What?
A follow up for #58267 and #58394.
We no longer need the git branch for history it's stored in datadog now
and we also decided that we no longer need slack reporting.
Closes PACK-2039
---------
Co-authored-by: Tim Neutkens <[email protected]>
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
### What?
Moving maintenance to a separate repository.
### Why?
I want to make these actions reusable in other projects as they seem to work well in the Next.js repository.
### How?
The code is moved to https://github.com/balazsorban44/nissuer
I tested it on my fork, and all the following functionality is preserved: https://github.com/balazsorban44/next.js/issues/56
- [x] Close/lock/comment without a valid reproduction link
- [x] Minimize "+1"
- [x] Add labels based on user selection
- [x] Add comment based on the maintainer's label (eg.: "please add a complete reproduction")
### What?
Adding a new label comment for "please simplify reproduction".
### Why?
During triaging, a lot of time is gone into trying to isolate the actual bug being reported. Reproductions sometimes contain unrelated code - that sometimes can be the actual cause of an issue, reported as a bug in Next.js, or require third-party services, secrets, setting up databases, and other tasks that take up much of the resources before the issue can even be verified.
### How?
Similar to the `please add a complete reproduction` and `please verify canary` labels, if a maintainer adds the `please simplify reproduction` label, an automatic comment will appear on the issue, asking for a minimal reproduction
[Slack thread](https://vercel.slack.com/archives/C04DUD7EB1B/p1685527818400339)
This PR migrates and adapts the [validate docs links script from `next-site`](https://github.com/vercel/front/pull/23185). This script is triggered by a GitHub action whenever a file in the `/docs` folder is updated. If broken links are found in the docs, the check fails and we post a comment on the PR with a list of broken links.
Co-authored-by: Michael Novotny <[email protected]>
There are some incoming docs / MDX changes where prettier will throw an error when using the older version. Updating prettier before I bring in those changes.
Looks like the most notable change is adding parentheses around `typeof` checks in TypeScript.
**Before**
```
export type Locale = typeof i18n['locales'][number]
```
**After**
```
export type Locale = (typeof i18n)['locales'][number]
```
### What?
* allow to apply existing pipeline
* change webpack loader key to glob for more flexibility
* add test cases
* add special error message when using the old config syntax
Old config:
```js
experimental: {
turbo: {
loaders: {
".mdx": ["mdx-loader"]
}
}
}
```
New config
``` js
experimental: {
turbo: {
rules: {
// key is a glob now
// normal syntax will treat the result as ecmascript code
"*.mdx": ["mdx-loader"],
// glob allows more advanced matching
"./images/**/*.png": {
loaders: ["image-optimize-loader"],
// result of loader will be handled in other steps
// under the same name/path (here .png)
// This will use the existing .png pipeline (static asset)
// It might also use other rules matching .png.
as: "*"
},
"*.generate-image.js": {
loaders: ["image-generation-loader"],
// It also possible to pass this under a different name
// into the pipeline. Here it will treat the result as png image
as: "*.png"
}
}
}
}
```
### Why?
More flexibility and allowing to use the builtin module handling over
non-js types.
fixes WEB-1009
### Turbopack changes
* https://github.com/vercel/turbo/pull/4955 <!-- OJ Kwon -
refactor(turbopack-ecmascript): deprecate enable_emotion, enable_styled*
-->
* https://github.com/vercel/turbo/pull/4880 <!-- Tobias Koppers -
refactor webpack loader execution -->
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
