Manage Angular Language Server in the extension, similar to the official VS Code extension #5

Summary

Explore changing the Zed Angular extension so users do not need to install @angular/language-server in every project.

The goal is to provide an install-and-use experience closer to the official Angular VS Code extension while keeping compatibility with projects that need a custom or pinned language server.

Background

An earlier attempt to automatically install @angular/language-server and @angular/language-service was proposed upstream:

• Auto install angular LSP and services nathansbradshaw/zed-angular#101
• Follow-up rationale: Update README.md to explain reason for BYO language server nathansbradshaw/zed-angular#102

The main concern raised upstream is that the Angular language server is sensitive to the Angular version used by the project, so managing a single extension-owned copy could introduce version mismatches.

That concern is valid, but the official Angular VS Code extension does not require each project to install its own language server. Instead, it ships/manages its own Angular language-service stack and contains compatibility logic for the Angular version used by the project.

Relevant Angular sources:

• VS Code Angular Language Service: https://github.com/angular/angular/tree/main/vscode-ng-language-service
• README: https://github.com/angular/angular/blob/main/vscode-ng-language-service/README.md
• Version resolver: https://github.com/angular/angular/blob/main/vscode-ng-language-service/server/src/version_provider.ts
• Project-local Angular version detection: angular/angular@8a7cbd4

Proposed direction

Instead of downloading latest on every session, make the Zed extension own a known-compatible language-server stack for each extension release.

For example:

zed-angular release
├── @angular/language-server
├── @angular/language-service
└── compatible TypeScript version
        │
        └── runs against the user's project
             └── detects/uses the project's local @angular/core version

The managed versions should be pinned by the extension release rather than automatically following npm latest. This makes behavior deterministic and avoids an extension changing underneath the user without an extension update.

Suggested behavior

1. By default, use the extension-managed Angular language server.
2. Install/download the pinned server packages into Zed extension storage when required.
3. Reuse the downloaded packages for subsequent sessions so the extension remains usable offline after installation.
4. Pass the appropriate Angular and TypeScript probe locations to the server.
5. Let the language service detect the Angular version installed in each project.
6. Keep angular_language_server_path as an escape hatch for users who need a project-local or manually pinned server.
7. Do not automatically update the server to npm latest independently of the Zed extension version.

Why this may be preferable

• No editor-specific @angular/language-server dependency needs to be added to application repositories.
• New users can install the Zed extension and immediately get Angular language features.
• Behavior is closer to the official Angular VS Code extension.
• Pinned extension-managed versions make the setup reproducible.
• Existing custom-server configuration can remain available for old Angular versions, unusual monorepos, or compatibility issues.
• Once packages are installed, normal startup does not need npm access.

Compatibility considerations

Version skew is still a real concern, especially around TypeScript and older Angular releases.

The implementation should therefore avoid assuming that one current server version can support every historical Angular project. A custom server-path override should remain supported, and we may eventually need a documented compatibility policy for older Angular majors.

For modern Angular versions, the Angular language service now detects the project-local @angular/core version when creating the language service. This was added specifically to improve cases such as monorepos containing projects on different Angular versions:

angular/angular@8a7cbd4

Acceptance criteria

• A normal Angular project does not need @angular/language-server in its devDependencies to get language features in Zed.
• The managed language server version is pinned to the Zed extension release.
• Managed packages are reused after the initial installation.
• Startup works offline when the required managed packages are already present.
• angular_language_server_path continues to override the managed server.
• TypeScript probe/version behavior is explicitly defined and tested.
• At least one test covers a project whose Angular version differs from the managed language-service version.
• Monorepo/project-local Angular version detection is verified.

Open questions

• Should TypeScript also be extension-managed, matching the official VS Code extension more closely, or should the project TypeScript remain preferred?
• What range of Angular major versions should a given extension release officially support?
• Should older Angular projects automatically fall back to a project-local server when one is available, or should that remain an explicit user override?