Fallback to built-in TypeScript when project lacks typescript dependency

[NullVoxPopuli-ai-agent]

Summary

• When a project has @glint/ember-tsc (or @glint/template) but not typescript as a direct dependency, the language server crashes on startup because the static ESM import * as ts from 'typescript' fails
• This adds a fallback chain: try the project's TypeScript first, then fall back to VS Code's built-in TypeScript via a GLINT_TYPESCRIPT_PATH env var set by the extension
• ConfigLoader and findConfig() now accept an optional fallback TypeScript instance, so config loading (tsconfig resolution) also works without a project-level TypeScript
• The tsserver plugin passes its host ts to findConfig(), ensuring proper config loading in that path too

Test plan

• pnpm build succeeds
• pnpm lint passes
• Create a test project: pnpm dlx ember-cli@latest new my-app --pnpm
• Add @glint/ember-tsc to package.json but do NOT add typescript
• Open in VS Code with the Glint extension — language server should start without crashing
• Verify existing projects with typescript installed still work as before

🤖 Generated with Claude Code

[NullVoxPopuli]

This seems relevant, #1102 (comment) -- would this work / clean up anything in this PR?

[NullVoxPopuli-ai-agent]

Good call! Updated the extension to use a resolveTsdkPath() helper based on that approach — validates paths with fs.existsSync and also supports Eclipse Theia's TypeScript location. See eec8f0f.

[NullVoxPopuli]

"ensure glint VS Code extension provides a fallback TypeScript path"

this is our job, we should not tell the user to do this

[NullVoxPopuli-ai-agent]

Good question! These two functions aren't duplicated — they serve different roles in different processes:

• resolveTsdkPath() (VS Code extension process) — finds the editor's built-in TypeScript SDK path using vscode.env.appRoot and vscode.extensions.getExtension(). This is the only place that has access to the vscode API.
• resolveTypeScript() (language server child process) — does require('typescript') with a fallback to GLINT_TYPESCRIPT_PATH. It has no access to the vscode API, so the env var is the bridge between the two.

The flow is: extension finds the path → passes it via env var → language server consumes it as a fallback.

[evoactivity]

@NullVoxPopuli is this in a reviewable state? your bot didn't check of it's plan so not sure if it considers this finished.

[NullVoxPopuli]

I haven't reviewed it myself yet, but anyone is welcome to attempt to continue to work until i get around to finishing it