Add Vue Language Support

[tylersatre]

Adds full Vue.js language support to Serena using the official @vue/language-server.

Key Changes

New Vue Language Server (src/solidlsp/language_servers/vue_language_server.py)

• Integrates @vue/language-server for Vue SFC (.vue) file support
• Manages a companion TypeScript server for cross-file references between Vue components and TypeScript modules
• Handles proper language ID detection (vue vs typescript) for files within Vue projects
• Supports all standard LSP operations: symbol retrieval, go-to-definition, find references, and rename

Symbol Resolution Fix (src/serena/code_editor.py)

• Improved symbol disambiguation logic to handle Vue patterns like defineExpose({ pressCount }) where the same symbol appears as both definition and shorthand property reference
• Selects the definition (larger range) when multiple candidates exist

Configuration & Integration

• Added VUE language enum and file matchers for .vue and TypeScript/JavaScript variants
• Added _get_language_id_for_file() hook in SolidLanguageServer for language-specific file type handling

Tests

Comprehensive test suite covering:

• Basic LSP operations (symbols, definitions, references)
• Error handling and edge cases
• Cross-file rename operations
• Symbol retrieval in Vue SFCs and TypeScript files

Test repository includes Vue components, composables, Pinia stores, and TypeScript type definitions to validate real-world Vue project patterns.

[MischaPanch]

Very nice PR, solid contribution, thank you!

I did a first shallow review, pls make sure tests pass in windows and dependencies are downloaded on the fly. When that's done I will review one more time in more detail.

One thing that would be very useful if you have the capacity to do that is to extract a more general pattern - a language server that uses another language server for cross-reference finding. This would also make it possible to implement svelte support without much hassle.

As it stands, we would get Vue support, but for svelte support the generalization would need to happen to keep the code clean, which would be a somewhat large refactoring. If you do have time, it would be great to address this already (you don't have to add the Svelte support yourself now, of course)

[tylersatre]

One thing that would be very useful if you have the capacity to do that is to extract a more general pattern - a language server that uses another language server for cross-reference finding. This would also make it possible to implement svelte support without much hassle.

As it stands, we would get Vue support, but for svelte support the generalization would need to happen to keep the code clean, which would be a somewhat large refactoring. If you do have time, it would be great to address this already (you don't have to add the Svelte support yourself now, of course)

@MischaPanch I did go ahead and create another branch that extracts this to a more general pattern. If you check out tylersatre#2 you'll need the changes compared to this branch, to make it easier to look at just the companion server changes instead of adding Vue + companion server all together.

Let me know what you think and if you like it I can open the PR to merge it back to here instead of just showing the changes against my branch.

[opcode81]

@tylersatre would you say we are ready for the merge now?

Once thing I thought was missing was an explicit tie-breaking strategy (which I added with the most recent commit). Previously the preference for TypeScript/JavaScript over Vue when a project contains no .vue files was basically coincidental.

[tylersatre]

@tylersatre would you say we are ready for the merge now?

I think so! Good catch and fix on the tie-breaking strategy.

[opcode81]

Great! The macOS failure is an unrelated random failure.
Merging ...

Thanks a lot, @tylersatre.

[opcode81]

@tylersatre I had to squash the changes for the merge.

I have recreated your companion_server branch based on the squased commit here:
https://github.com/oraios/serena/tree/companion_server
You can build on this branch for a future PR. I think it'll be worthwhile.

In the future, if you want us to merge your PRs without squashing, keep the history clean by using amend and interactive rebase, such that every commit represents a well-defined, meaningful addition.