Expose candidatesToAst to the language server

[thecrypticace]

This will be used to improve performance and potentially enable future features that require generated CSS source locations.

Note: This is still 100% internal API. You can only access this via __unstable__loadDesignSystem for a reason. We may chance the structure of the arguments and/or return values as needed.

[coderabbitai]

Walkthrough

The changes introduce AST-based candidate conversion capabilities to the Tailwind CSS design system. The design-system module gains a new public method candidatesToAst() and the buildDesignSystem() factory now accepts an optional utilitiesNode parameter for source context. Two new internal functions handle candidate-to-AST and candidate-to-CSS conversions, with support for polyfill suppression. The index module updates parseCss() to pass the utilitiesNode context during design system construction and forwards source location information through the CSS parsing pipeline via the from option.

Pre-merge checks

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and specifically identifies the main change: exposing the candidatesToAst function to the language server, which matches the primary modification in the changeset.
Description check	✅ Passed	The description is related to the changeset, explaining the purpose of exposing candidatesToAst for performance improvement and future features requiring CSS source locations.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

packages/tailwindcss/src/design-system.ts (1)

114-151: candidatesToAst/candidatesToCss behavior aligns with the compilation pipeline; consider deduplicating src-propagation logic

The per-class compileCandidates call, invalid-candidate guard (wasValid + empty array), optional utilitiesNode.src propagation via walk, and use of optimizeAst(…, Polyfills.None) give you a clean, source-aware AST tailored for IntelliSense, and reusing it in candidatesToCss avoids double work. One small polish opportunity: the walk(…, node.src ??= utilitiesNode.src) pattern is now duplicated here and in compileAst.build in index.ts; factoring this into a shared helper (e.g., attachUtilitySources(astNodes, utilitiesNode)) would keep source-location behavior in one place.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a92fa97 and a4cee91.

📒 Files selected for processing (2)

• packages/tailwindcss/src/design-system.ts (5 hunks)
• packages/tailwindcss/src/index.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

packages/tailwindcss/src/index.ts (1)

packages/tailwindcss/src/design-system.ts (1)

• buildDesignSystem (69-251)

packages/tailwindcss/src/design-system.ts (3)

packages/tailwindcss/src/ast.ts (3)

• AstNode (68-68)
• optimizeAst (220-672)
• toCss (674-879)

packages/tailwindcss/src/walk.ts (1)

• WalkAction (10-20)

packages/tailwindcss/src/value-parser.ts (1)

• toCss (41-56)

🔇 Additional comments (4)

packages/tailwindcss/src/design-system.ts (2)

2-2: Imports for AST typing and walking are appropriate

Pulling in type AstNode from ./ast and WalkAction/walk from ./walk matches the new usage in candidatesToAst and keeps types explicit without affecting runtime behavior. No issues here.

Also applies to: 27-27

---

61-67: DesignSystem API extension and buildDesignSystem signature look correct

Adding candidatesToAst(classes: string[]): AstNode[][] to DesignSystem and wiring it (plus the refactored candidatesToCss) into the returned designSystem object is consistent with the stated IntelliSense use case. Making utilitiesNode an optional parameter on buildDesignSystem keeps the call sites backwards compatible while enabling source-aware behavior when it is provided.

Also applies to: 69-72, 160-162

packages/tailwindcss/src/index.ts (2)

598-605: Passing utilitiesNode into buildDesignSystem is consistent with the new AST APIs

Feeding utilitiesNode into buildDesignSystem(theme, utilitiesNode) nicely connects the parse phase to the new candidatesToAst logic that reuses utilitiesNode.src for generated utility nodes. This keeps the source-location handling centralized in the design system without changing behavior for callers that don’t use @tailwind utilities (where utilitiesNode is null).

---

829-844: Using CSS.parse with { from: opts.from } correctly enables source tracking for both compile and __unstable__loadDesignSystem

Parsing with CSS.parse(css, { from: opts.from }) in both compile and __unstable__loadDesignSystem aligns the AST’s src information with the caller-provided filename and matches the later use of toCss(newAst, !!opts.from) and utilitiesNode.src in downstream code. This is a straightforward, backwards-compatible improvement for source maps and language-server consumers.

Also applies to: 858-859