Want to skip the docs? Check out pandamastery.com - the best way to learn Panda CSS

reference
editor tooling

Editor & IDE tooling

Preset-aware completions, hover, and diagnostics while editing panda.config.ts and your styles. Experimental in the v2 beta.

⚠️

These packages ship on the v2 beta (@pandacss/typescript-plugin, @pandacss/language-server) but are experimental. Coverage is still landing, so treat the feature list below as direction. Part of the rewrite in Upgrading to v2.

The problem it's meant to solve

Today, panda.config.ts is edited with no more help than plain TypeScript gives any object literal, no autocomplete for a token path inside theme.semanticTokens, no warning about a broken token reference, until you actually run codegen and see what it produced. Package types alone can't fix this: they describe config's shape, but not the design system a specific project's config resolves to once its presets are merged. That resolution has to happen at edit time, which needs an actual language service, not just better generated types.

Two thin transports over one core

One shared core, exposed to editors two ways depending on what the user's TypeScript setup can support:

  • @pandacss/typescript-plugin: a classic tsserver plugin, the same mechanism typescript-styled-plugin and early Vue/Angular tooling used. Works today in any editor built on classic tsserver (VS Code, and most others), registers automatically in VS Code via a thin extension.
  • @pandacss/language-server: a standard LSP server over the same core, for editors that aren't running classic tsserver, including TypeScript's newer Go-based compiler (tsgo, codename Corsa), which doesn't support the classic in-process plugin API at all.

Both ship together rather than one first and the other later, since betting entirely on the classic plugin API is risky while TypeScript's own team is consolidating around LSP for the newer compiler. Either way, the actual token/recipe resolution logic lives once in a shared @pandacss/compiler/tooling core, both transports are thin wrappers over it, and it's the same core the ESLint & OXLint Plugin is expected to use for its project metadata too.

What it's meant to provide

  • Completions and hover for token paths while writing theme.tokens/theme.semanticTokens in panda.config.ts itself, not just in application code that imports the generated styled-system.
  • Diagnostics for the same issues covered in the Diagnostics Reference, surfaced while you type instead of only at build time.
  • Module resolution for designSystem/importMap inside the editor, without needing to hand-write tsconfig.json path aliases yourself.
  • Zero-config setup in VS Code, the plugin is expected to register itself once installed. Other tsserver-backed editors would need the plugin wired manually.

See also