2 Commits

Author	SHA1	Message	Date
Tobias Koppers	4b3e4e8adc	turbopack: move CSS module composes validation from code generation to resolving (#92582) ... ### What? Move the validation that can produce `CssModuleComposesIssue` from code generation (`chunk_item_content`) to the reference's own `resolve_reference()` method, so these errors are surfaced during resolving rather than only during bundling. Two validation checks are moved into `CssModuleComposeReference::resolve_reference()`: 1. A `composes: ... from "...";` target module can't be resolved (unresolvable reference) 2. A `composes: ... from "...";` target module is not a CSS module (e.g. composing from a `.js` or `.txt` file) The `IssueStage` is updated from `CodeGen` to `Resolve` to reflect the new phase. Code generation still handles the error cases gracefully (skipping broken references with `continue`) — it just no longer re-emits the issue since it is already emitted by `resolve_reference()`. ### Why? `get_compilation_issues` (used by the MCP server and other tooling) only builds the module graph — it does not run code generation. Previously, both `CssModuleComposesIssue` variants were only emitted during `chunk_item_content()`, which meant they were invisible to `get_compilation_issues`. Developers using the MCP `get_compilation_issues` tool would not see errors from broken `composes` references until an actual build/bundle was triggered. Since `resolve_reference()` is called as part of module graph traversal, emitting the issue there means it is captured by `get_compilation_issues` alongside other resolve-phase errors. ### How? **`turbopack-css/src/references/compose.rs`** - `CssModuleComposeReference::resolve_reference()` is changed from `fn` to `async fn`. It calls `css_resolve` as before, then awaits `first_module()` on the result and validates: - Resolved to nothing → emit "can't be resolved" issue - Resolved to a module that doesn't implement `CssModuleComposable` → emit "not a CSS module" issue - `CssModuleComposesIssue` and its `Issue` impl are moved here from `module_asset.rs`, now using `ResolvedVc<FileSystemPath>` (from `origin_path()`) as the issue location rather than the `IssueSource` of the composing file. - A new `CssModuleComposable` marker trait (`#[turbo_tasks::value_trait]`) is defined here. `resolve_reference()` uses a `try_sidecast` to this trait to check whether the resolved module is a valid compose target — avoiding a hard dependency on `EcmascriptCssModule` from within `compose.rs`. **`turbopack-css/src/module_asset.rs`** - `EcmascriptCssModule` implements `CssModuleComposable`, marking it as a valid `composes:` target. - `module_references()` is reverted to its original simple form — it only collects references without any validation. - All issue-related imports (`Issue`, `IssueExt`, `IssueSource`, etc.) are removed. **Test fixtures** (`test/development/mcp-server/fixtures/compilation-errors-app/app/css-composes-error/`) - `styles.module.css` — CSS module with `composes: something from './not-a-css-module.txt'` - `not-a-css-module.txt` — a plain text file (resolves but is not a CSS module) - `page.tsx` — page importing the broken CSS module **`test/development/mcp-server/mcp-server-get-compilation-issues.test.ts`** - New test case `should detect CSS module composes errors` verifies the issue is surfaced via `get_compilation_issues`. <!-- NEXT_JS_LLM_PR --> --------- Co-authored-by: Tobias Koppers <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>	2026-04-10 21:11:29 +02:00
Tobias Koppers	41839289de	Add MCP get_compilation_issues tool and NAPI method (#92062) ... ### 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 <sokra@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>	2026-04-03 14:38:44 +02:00