Support compilerOptions.plugins inside Astro Language Server (Breaks TS Language plugins)

[Stephcraft]

Astro Info

Astro                    v6.4.2
Vite                     v7.3.3
Node                     v24.4.0
System                   Windows (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             @astrojs/mdx (v6.0.1)
                         @astrojs/sitemap (v3.7.3)
                         astro-icon (v1.1.5)

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

Currently, the Astro Language Server completely strips out or ignores third-party TypeScript plugins defined in tsconfig.json (such as typescript-yaml-plugin, typescript-plugin-css-modules, etc.) when evaluating .astro frontmatter.

The Problem:
If I use typescript-yaml-plugin, importing a .yml file inside a .ts file perfectly infers the types.
Importing that exact same .yml file inside the --- block of an .astro file degrades instantly to any.

Because the Astro Language Server initializes its own isolated tsserver instance to parse scripts, it seems to bypass the native plugin initialization hooks.

What's the expected result?

The virtual TypeScript service that Astro boots up should map and initialize the plugins array defined in the user's tsconfig.json so that custom AST parsers and module resolvers work consistently across both .ts and .astro files.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-8fbjjymg?file=src%2Fpages%2Findex.astro

Participation

• I am willing to submit a pull request for this issue.

[astrobot-houston]

• Reproduced: Skipped — this is a feature request for the Astro Language Server, not a runtime bug reproducible in a CLI environment.
• Exploration: No
• Unit Test: No — Language Server behavior cannot be tested in this repository.
• Priority: P2: Nice to Have. This affects users who rely on third-party TypeScript plugins (e.g. typescript-yaml-plugin, typescript-plugin-css-modules) for type inference inside .astro frontmatter. The workaround is that these plugins still work correctly in .ts files, and runtime behavior is unaffected — only IDE type inference in .astro files is degraded.

This issue describes the Astro Language Server not forwarding compilerOptions.plugins from the user's tsconfig.json to its internal TypeScript service. As a result, third-party TS plugins that provide custom type inference (like typescript-yaml-plugin) work in .ts files but lose their type information inside .astro frontmatter blocks. This is a Language Server–level concern that doesn't affect builds, dev server, or runtime behavior.

I was unable to determine the cause of this issue. The Astro Language Server lives in the withastro/language-tools repository, not in this repo. This issue may be better filed there, where the relevant code for TypeScript service initialization and plugin forwarding resides. Specifically, the area to investigate would be how the Language Server creates its TypeScript language service instance and whether it passes through the plugins array from the resolved tsconfig.json.

Full Triage Report

Triage Report: Issue #16917

Issue Details

• Title: Support compilerOptions.plugins inside Astro Language Server (Breaks TS Language plugins)
• URL: Support compilerOptions.plugins inside Astro Language Server (Breaks TS Language plugins) #16917
• Author: @Stephcraft
• Created: 2026-05-30T01:20:07Z
• State: open
• Labels: needs triage

Environment (from issue)

• Astro v6.4.2
• Vite v7.3.3
• Node v24.4.0
• System: Windows (x64)
• Package Manager: npm
• Output: static
• Adapter: none
• Integrations: @astrojs/mdx (v6.0.1), @astrojs/sitemap (v3.7.3), astro-icon (v1.1.5)

Issue Description

The reporter states that the Astro Language Server ignores third-party TypeScript plugins defined in tsconfig.json under compilerOptions.plugins (such as typescript-yaml-plugin, typescript-plugin-css-modules, etc.) when evaluating .astro file frontmatter.

Specifically, importing a .yml file inside a .ts file correctly infers types (via typescript-yaml-plugin), but importing the same .yml file inside the --- block of an .astro file degrades to any.

The reporter explains this happens because "the Astro Language Server initializes its own isolated tsserver instance to parse scripts" which "bypasses the native plugin initialization hooks."

Expected Result (from issue)

The virtual TypeScript service that Astro boots up should map and initialize the plugins array defined in the user's tsconfig.json so that custom AST parsers and module resolvers work consistently across both .ts and .astro files.

Reproduction

StackBlitz: https://stackblitz.com/edit/github-8fbjjymg?file=src%2Fpages%2Findex.astro

Reproduction Status: SKIPPED

Skip Reason: not-actionable

This issue was skipped for two reasons:

1. Feature Request, Not a Bug

The issue title itself says "Support compilerOptions.plugins inside Astro Language Server." The reporter is requesting that Astro add support for forwarding compilerOptions.plugins to the Language Server's internal TypeScript service. This is a feature that doesn't exist today — it's not a regression or broken existing functionality. The reporter acknowledges that the Language Server "strips out or ignores" these plugins and asks for them to be supported.

2. Language Server / IDE Issue — Cannot Reproduce in CLI Sandbox

Even if this were classified as a bug, it cannot be reproduced in our headless sandbox environment. The issue is entirely about IDE type inference behavior in the Astro Language Server (LSP), which runs inside VS Code or similar editors. The bug:

• Does not affect astro build or astro dev
• Does not produce runtime errors
• Does not affect CLI type checking via astro check (which uses a different code path)
• Can only be observed by examining hover tooltips and type inference in an IDE with the Astro VS Code extension

Our sandbox has no IDE, no VS Code, and no running Language Server instance. There is no way to verify whether TypeScript plugin types are correctly inferred in .astro frontmatter vs .ts files.

Additional Context for Downstream Processing

The Astro Language Server code lives in a separate repository: https://github.com/withastro/language-tools. This issue may be better filed there rather than in the main withastro/astro repo. The relevant code would be in how the Language Server initializes its TypeScript service and whether it passes through compilerOptions.plugins from the user's tsconfig.json.

Comments

No comments on this issue.

This report was made by an LLM. The analysis may be wrong, and the potential fix might not work, but is intended as a starting point for exploring the issue.

[Princesseuh]

This is not really possible to support with the way the Astro language server works as far as I'm aware. It requires recreating it as a TypeScript plugin (like the Vue language server works), which runs into a few issues with some Astro features.