perf: enable incremental TypeScript reparsing via getChangeRange

[MathiasWP]

Summary

Previously, both SvelteDocumentSnapshot and JSOrTSDocumentSnapshot returned undefined from getChangeRange(), which meant TypeScript had to fully reparse every file on each snapshot update. This PR implements getChangeRange() properly, enabling TypeScript's built-in incremental parser.

What changed

• New computeChangeRange() function — a simple linear scan (using charCodeAt for speed) that finds the minimal diff between old and new text, returning a ts.TextChangeRange with the exact changed span.
• SvelteDocumentSnapshot.getChangeRange() — now computes the change range between the old snapshot's text and the current text instead of returning undefined.
• JSOrTSDocumentSnapshot.getChangeRange() — same as above, with an additional optimization: when TS passes the same object reference (which happens because update() mutates the snapshot in-place and TS cached the reference before mutation), it returns a pre-computed change range from the last update() call, avoiding a redundant diff.
• 31 unit tests covering computeChangeRange correctness and getChangeRange integration for both snapshot types.

How computeChangeRange works

1. Scan forward to find the first differing character (prefix)
2. Scan backward to find the last differing character (suffix)
3. Return the span between them as a TextChangeRange

Why this matters

getChangeRange() is called by TypeScript every time a source file snapshot changes. Previously returning undefined forced a full reparse of the entire file. With a proper change range, TypeScript's incremental parser can:

1. Reuse unchanged AST nodes — only re-parsing the region that actually changed
2. Skip reparsing entirely for token-level edits where the AST structure is unchanged

In end-to-end benchmarks (including svelte2tsx, parseHTML, and TS program update), this yields roughly a 5-10% improvement in the full update pipeline.

Test plan

• All 31 unit tests pass (npm test in packages/language-server)
• Manual testing in VS Code with Svelte extension on a large project

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 8e6ecbb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte-language-server	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jasonlyu123]

I think we could add the change. However, the difference isn't really that big since it's not the part that spends the most time. I tried running a benchmark with our update process, including svelte2tsx, parseHTML and ts program update. The difference is around 5-10% average in 100 iterations. If starting from two 1000-line files and updating both per iteration, it went from 1300ms to 1200ms. So it might not be noticeable in most cases.

For the code changes, I don't think we need the "incremental reparse AST verification" part. We can keep a few of them. Most of the test AI generated in DocumentSnapshot.test.ts is not useful. Could you trim it down? I think the benchmark can also be deleted. It already served the demonstrative purpose. And as mentioned earlier, the benchmark doesn't tell the full picture.

[MathiasWP]

I think we could add the change. However, the difference isn't really that big since it's not the part that spends the most time. I tried running a benchmark with our update process, including svelte2tsx, parseHTML and ts program update. The difference is around 5-10% average in 100 iterations. If starting from two 1000-line files and updating both per iteration, it went from 1300ms to 1200ms. So it might not be noticeable in most cases.

For the code changes, I don't think we need the "incremental reparse AST verification" part. We can keep a few of them. Most of the test AI generated in DocumentSnapshot.test.ts is not useful. Could you trim it down? I think the benchmark can also be deleted. It already served the demonstrative purpose. And as mentioned earlier, the benchmark doesn't tell the full picture.

Thank you for the reply! I do not really have the full grasp of all of the inner workings of this setup (i tried to do some refactorings earlier as well), so i figured it would be worth it to just take a couple of shots with my best AI setup and see if something good comes out of it.

I implemented your feedback, want to re-review?

[MathiasWP]

I think we could add the change. However, the difference isn't really that big since it's not the part that spends the most time. I tried running a benchmark with our update process, including svelte2tsx, parseHTML and ts program update.

Also, could you share from your benchmarking what part spends the most time? Or is this a benchmark that is already in the repo that i can run?

[jasonlyu123]

You can find it here https://github.com/jasonlyu123/language-tools/tree/incremental-benchmark

While setting up this branch, I remembered we actually tried this before in #1192.

[MathiasWP]

@jasonlyu123 do you want to review the updates