The previous default, 262.9593.0, is a JetBrains EAP-style build that has
expired: intellij-server exits at startup with "This build of intellij-server
has expired", so every Kotlin symbolic tool fails. 263.4702.0 is the newest
release on Kotlin/kotlin-lsp and starts normally.
Uses the same archive layout and CDN path as 262.9593.0. Hashes regenerated
with scripts/update_downloaded_dependency_hashes.py.
Fixes#2008
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cross-file queries waited 5s after the first file was opened. On a cold Metals
that is long before it has imported the build, indexed, and — crucially —
compiled: references come from SemanticDB, which the build server writes as it
compiles, so a query made in between returns some of the references rather than
none, with nothing to mark it partial. Against a ~700-file Scala 3 build the
first find-references returned 124 of 242.
Metals already reports all of this as work-done progress; Serena did not declare
`window.workDoneProgress`, so none of it arrived. Declare it, track the tokens,
and wait for them before the first cross-file query — the same event-based shape
as TypeScript's indexing wait (#1639), whose hooks this uses.
Readiness is "nothing outstanding for a moment", not "nothing outstanding":
Metals hands off between its phases rather than overlapping them, so the token
set empties for around a second between the import ending and indexing starting,
and a plain drain returns in that gap. Measured on the same build, the first
find-references now returns all 242, taking 32s rather than 22s.
* feat(kotlin): update language server to 262.9593.0
Note: download URL structure differs depending on version
---------
Co-authored-by: Dominik Jain <dominik.jain@oraios-ai.de>
find_referencing_symbols/request_references could return incomplete results on
large TypeScript projects. _wait_for_indexing_start_or_completion waits only
_INDEXING_START_GRACE_S (hardcoded 2.0s) for tsserver to *start* emitting
$/progress after opening files; if nothing has appeared by then, it assumes no
indexing is needed and proceeds immediately. On a large project, tsserver can
take longer than that just to resolve the project graph before it even creates
the first progress token, so the first cross-file reference query can race a
project that is still loading.
Every caller of _wait_for_indexing_start_or_completion (the base TypeScript
path and the Svelte companion) always calls expect_indexing() first, so the
"no progress observed" branch is reached specifically when indexing is already
expected; it cannot distinguish "nothing to do" from "not started yet",
because the two look identical from the client for as long as tsserver stays
quiet. That ambiguity cannot be resolved from client-observable signals alone,
so this makes the grace an ls_specific_settings knob (`indexing_start_grace`),
the same way indexing_timeout and server_ready_timeout already are, and raises
the default from 2.0s to 5.0s.
Fixes#1586
Adds first-class support for xAI's Grok Build CLI, following the
existing client-integration pattern (Claude Code, CodeBuddy, Codex):
- grok context: single-project, shaped like claude-code.yml, with the
file-tool exclusions appropriate for a CLI agent that has its own
read/edit/shell tools. structured_tool_output is left at the auto
default (as in the codex and codebuddy contexts); claude-code's
explicit false is a Claude-Code-specific bug workaround that is not
carried over.
- serena setup grok: registers Serena as a user-scoped MCP server via
"grok mcp add" after detecting a compatible grok CLI.
- serena-hooks --client=grok: Grok-native PreToolUse output
({decision, reason}) instead of the Claude-style hookSpecificOutput
envelope; grep/read detection extended to Grok's tool names and
shell payloads (target_file/targetFile path keys, non-string command
values handled defensively). The payload-parsing refinements live in
the remind hook's client-agnostic parsing and apply to all hook
clients: a non-string command value previously raised, and
target_file/targetFile paths were not recognized.
- Docs (030_clients.md #grok), unit tests for setup/hooks/context, and
scripts/live_test_grok.py - a zero-inference, state-preserving live
smoke test against a real grok installation (documented in
CONTRIBUTING.md). Its M5 check verifies the structured-output wire
shape: the grok context (auto default) serves an output schema and
structuredContent for string-returning tools, while the claude-code
context (explicit false workaround) serves plain text only.
- PHP/Intelephense: expose `file_filter` via `ls_specific_settings["php"]`, so that additional
extensions containing PHP sources (e.g. Drupal's `.module` / `.install` / `.inc` / `.theme`)
become visible to the symbol tools and are indexed by the language server
- PHP: treat `.phtml` files as PHP sources by default (all PHP language servers)
* Java (JDT-LS): allow registering additional JRE/JDK runtimes via config
JDT-LS resolves each imported module's JRE_CONTAINER/.../JavaSE-NN/
classpath entry against its own "Installed JREs" list, which Serena
previously hardcoded to a single JavaSE-21 entry pointing at the
bundled JRE. Projects whose source/target level exceeds that bundled
JDK (e.g. sourceCompatibility = VERSION_25) get a container that never
resolves, so every JDK type -- java.lang.Object, java.util.*, etc. --
comes back "cannot be resolved", silently breaking diagnostics and
cross-module resolution. There was no config key to tell JDT-LS about
an installed newer JDK.
Add an optional `runtimes` list under ls_specific_settings.java,
mirroring VS Code's java.configuration.runtimes shape (name, path,
optional default/sources/javadoc). Entries are validated (name+path
required, path must exist) via the new _resolve_configured_runtimes(),
then merged with the bundled JavaSE-21 default: configured runtimes
extend the list; an entry reusing the "JavaSE-21" name overrides the
bundled one; if a configured entry claims `default`, the bundled
runtime's own default flag is cleared so JDT-LS doesn't see two
defaults. The `runtimes` key is also added to the JDTLS workspace-hash
inputs so changing it lands in a fresh workspace instead of reusing a
stale Buildship/Maven import.
Testing: added 14 unit tests in
test/solidlsp/java/test_jdtls_path_resolution.py covering
_resolve_configured_runtimes validation (missing keys, wrong types,
nonexistent paths) and the merge behavior in
_create_base_initialize_params (extension, name-collision override,
default hand-off). Ran `poe format`, `poe type-check`, and
`pytest test/solidlsp/java -m "not java"` (69 passed, 8 deselected
real-JDTLS tests that require a JDK) locally.
Fixes#1478
* docs: document java.runtimes in configuration guide
Address review feedback on #1715 by documenting ls_specific_settings.java.runtimes
in 050_configuration.md (settings table, note, and example).
Co-authored-by: Cursor <cursoragent@cursor.com>
---------
Co-authored-by: arimu1 <19286898+arimu1@users.noreply.github.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Perl::LanguageServer only indexes files whose extension is in its
`perl.fileFilter` and skips directories in `perl.ignoreDirs`. Both were
hardcoded in PerlLanguageServer, so projects whose Perl source uses
non-standard extensions (e.g. .cgi / .psgi web handlers, which can
dominate a mature codebase) had no way to make those files visible to
symbol/reference queries without forking Serena (#1449).
Surface both lists through `ls_specific_settings["perl"]` (keys
`file_filter` and `ignore_dirs`), defaulting to the existing values so
behaviour is unchanged for current projects. The resolution lives in a
pure static method `_resolve_filter_settings` so the config plumbing is
covered by unit tests that don't require a Perl runtime.
Keep Serena's symbol index in sync with the LS (#1449, per review):
`find_symbol` and symbol indexing are driven by
`Language.PERL.get_source_fn_matcher()`, so adding an extension (e.g.
.cgi) to `file_filter` alone would leave the matcher untouched and the
extension's symbols invisible. Since that matcher is now a @cache'd
per-language singleton, add a `FilenameMatcher.add_extensions()` mutator
and call it from `PerlLanguageServer` so the configured extensions also
reach the symbol index, the ignore checks, and language composition.
Avoid cross-project leakage (per review): because the matcher is a
process-wide singleton, extensions added for one project would otherwise
persist into the next. `FilenameMatcher` now snapshots its initial
configuration and exposes `reset()`, and `SolidLanguageServer.__init__`
resets the matcher right after `self.language` is determined, so every
activation starts from the language's defaults before the subclass
re-applies its own `file_filter`.
This complements 860c5841 (which added .t to the default list as a
surface-level fix) by addressing the root configurability gap that the
maintainer acknowledged in #1449.
Make the Svelte companion TypeScript server raise on readiness and
indexing timeouts instead of silently proceeding with a partial index,
turning flaky/wrong cross-file results into clear failures:
- TypeScriptLanguageServer: timeout handling factored into overridable
hooks (_handle_server_ready_timeout, _handle_project_indexing_timeout);
the base server keeps its historical permissive behavior, so plain
TypeScript setups are unchanged.
- SvelteTypeScriptServer: both overrides raise TimeoutError; only the
indexing-timeout error includes describe_indexing_state(), instead of
serving requests from a cold or partially indexed program.
- Configurable server_ready_timeout / indexing_timeout via
ls_specific_settings.
- SvelteLanguageServer: file-open failures during companion preparation
raise SvelteCompanionPreparationError with a count-first file listing
(capped at 10), chained to the first underlying error so the cause is
visible without DEBUG logging.
Apply the same fail-loudly principle to the test fixture bootstrap:
- Svelte test repo: npm ci with a committed package-lock.json, removing
dependency-resolution non-determinism from CI runs.
- Run svelte-kit sync explicitly during fixture setup and fail loudly if
.svelte-kit/tsconfig.json cannot be generated. The fixture's "prepare"
script masks sync failures ("svelte-kit sync || echo ''"), and a known
npm bug (npm/cli#4828) can silently skip platform-specific optional
dependencies; the result is unresolvable $lib path aliases and
cross-file tests failing with partial results instead of a clear,
actionable error.
- codespell: skip third-party fixture repositories, using the anchored
pattern ./test/resources/repos (codespell matches skip globs against
the ./-prefixed paths it walks, so an anchor-less pattern never
matches).
Also add direct regression tests for the timeout-policy split
(test/solidlsp/test_typescript_timeout_policy.py: base stays
permissive, companion raises, settings plumbing and precedence, and
start-or-completion indexing-wait semantics). The tests use no mocking or
patching of any kind; a hand-written call-recording fake drives the companion
guard against real file discovery under a pytest tmp_path. They spawn no LS
process and avoid external readiness races; one wait test uses a real Timer
with a 30s ceiling.
The configuration docs state that the TypeScript table lists both knobs; the
Svelte table lists indexing_timeout, with readiness inheritance documented in
prose.
* TypeScript/VTS: event-based indexing wait, no automatic typing acquisition
- Set disableAutomaticTypingAcquisition in initializationOptions (TS and VTS)
so tsserver does not download type packages from the network during
language server initialization.
- Replace the fixed 2-second wait before cross-file reference requests with
$/progress-based indexing tracking: a pre-open hook arms the tracking
(expect_indexing) before didOpen, then the request waits until indexing
progress drains (wait_for_indexing), bounded by a configurable
'indexing_timeout' (ls_specific_settings, default 30s). If tsserver does
not start reporting progress within a 2-second grace period (the previous
fixed wait), the request proceeds — so the fast path is never slower than
before, while slow indexing is actually awaited instead of guessed at.
that use the newly introduced InitializeParamsBuilder
- Add new configuration option `ls_workspace_folders` to allow indexed source folders to be specified
explicitly. In monorepos, this allows the set of indexed folders to be restricted to a subset of
the repository. #1627
- Rename configuration option `additional_workspace_folders` to `ls_additional_workspace_folders`
and support the option across all language servers that use an InitializeParamsBuilder
(previously limited strictly to the TypeScript server).
Moved the option from SolidLSPSettings to LanguageServerConfig, where it belongs.
Apply InitializeParamsBuilder in TypeScriptLanguageServer and its subclasses.
ls_base_cmd allows the user to override the base command with a
multi-element command (e.g. ["npx", "-y", "/my/local/package"]),
generalising ls_path, which it takes precedence over.
* typescript_vts: add initialization_options pass-through
Extends ls_specific_settings["typescript_vts"] with an optional
initialization_options key — a dict forwarded to vtsls via all three
LSP configuration channels:
- the initialize request (initializationOptions field),
- a workspace/didChangeConfiguration notification right after initialize,
- and responses to workspace/configuration pulls, looked up per section
(e.g. "typescript", "vtsls", "javascript", or dotted paths like
"typescript.tsdk").
All three channels are necessary because different parts of vtsls read
settings from different places — notably typescript.tsdk, which vtsls
pulls via workspace/configuration rather than reading from
initializationOptions. Without the pull-answer, setting tsdk had no
effect.
Primary use case: Yarn Plug'n'Play projects. Running
`yarn dlx @yarnpkg/sdks vscode` in the project root generates
.yarn/sdks/typescript/lib/tsserver.js, a PnP-aware tsserver. The user
then points vtsls at it with:
ls_specific_settings:
typescript_vts:
initialization_options:
typescript:
tsdk: "<...>/.yarn/sdks/typescript/lib"
vtsls:
autoUseWorkspaceTsdk: true
autoUseWorkspaceTsdk is required alongside tsdk because, in a headless
LSP context, there is no UI prompt to confirm switching to the
workspace TypeScript version. See yioneko/vtsls#169 for the recipe.
Default behaviour is unchanged — the field is optional, omitted from
the initialize params and didChangeConfiguration when unset or empty,
and workspace/configuration continues to answer empty sections.
- Rename LSP_PORT → DEFAULT_GODOT_LS_PORT and add DEFAULT_GODOT_REQUEST_TIMEOUT
- Make port and request_timeout overridable via ls_specific_settings["gdscript"]
by reading self._custom_settings in _create_language_server_interface
- Move self._conn_info setup into _create_language_server_interface so it can
consume ls_specific_settings (which requires super().__init__ to have run)
- Fix _detect_godot_version to return int | None instead of always defaulting to 4:
use an explicit config_version→major dict; return None for unrecognized versions
and detection failures; caller logs warning on None
- Update setup guide and configuration reference docs with new settings
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(jdtls): surface Lombok-generated methods in document symbols
JDTLS' DocumentSymbolHandler filtered out every SourceMethod where
JDTUtils.isGenerated() was true, so Lombok-synthesised methods (getX/setX,
builder(), equals/hashCode/toString, withX, fluent accessors, ...) never
reached the LSP client. As a result Serena's symbol-aware tools — find_symbol,
get_symbols_overview, replace_symbol_body, insert_before_symbol,
insert_after_symbol — could not see, address or edit any Lombok-generated
member; only search_for_pattern / replace_content (text-based) worked.
Upstream introduced an opt-in preference java.symbols.includeGeneratedCode
in eclipse-jdtls/eclipse.jdt.ls#3706 (merged 2026-02-24) and surfaced it
through redhat-developer/vscode-java#4335. First vscode-java release with
the new JDTLS build is v1.53.0 (2026-02-26). Serena was pinned to v1.42.0-561,
well before the fix existed.
Changes:
- New ls_specific_settings.java.lombok_show_generated setting (default true);
forwarded to JDTLS as java.symbols.includeGeneratedCode in initialize
params. Older servers ignore the unknown preference key silently.
- Bump bundled vscode-java DEFAULT 1.42.0-561 -> 1.54.0-923 (brings JRE
21.0.10, Lombok 1.18.39 and Equinox launcher 1.7.100). INITIAL stays at
1.42.0-561, so per the per-version install-dir convention from #1438 the
new build lands in vscode-java-1.54.0-923/ while legacy vscode-java/
caches and any explicit vscode_java_version: '1.42.0-561' override keep
working.
- New VsixResourcePaths dataclass + INITIAL/DEFAULT_VSCODE_JAVA_PATHS pin
the JRE / Lombok / launcher filenames *inside* the VSIX. Without this,
bumping the archive would break users on legacy 1.42.0-561 because
resource paths inside the archive change between releases. Resolution
mirrors SHA pinning: known versions get their pinned paths; any other
version raises SolidLSPException with a pointer to upstream-jdtls mode
(which derives paths dynamically and needs no pinning).
- Drop dead 'static/vscode-java/...' placeholder in initialize params; the
real runtimes[] is overwritten below from runtime_dependency_paths
.jre_home_path, which is correct in both default-VSIX and upstream-jdtls
modes.
- Test fixtures: Lombok provided dep in test_repo/pom.xml plus
LombokModel / FluentLombokModel / DefaultGreeter covering @Data, @Builder
(toBuilder=true), @With, @Delegate, @AllArgsConstructor, @NoArgsConstructor
and @Accessors(fluent=true). Regression test in test_java_basic.py
asserts every generated-method shape lands in document symbols.
Closes#1432
- Add 'Additional Workspace Folders' section to project configuration docs
- Add cross-reference note to TypeScript LS settings section
- Include configuration example and usage notes
* Breaking change: Projects (project.yml) can no longer override `base_modes`.
Instead, they can define `added_modes` to add modes on top of base and default modes.
This allows `base_modes` to be fully applied for the computation of the base toolset
as they are no longer dynamic.
* Serena's default configuration now uses `interactive` and `editing` as `base_modes`
instead of as `default_modes`.
The upstream fix for the CRLF stale-tree crash (antaalt/shader-sense#44)
was merged and released as v1.3.1. This commit:
- Removes the client-side CRLF workaround (open_file override and
_preload_crlf_content helper) added in #1305, along with the
now-unused imports.
- Bumps _DEFAULT_VERSION to 1.3.1 and updates SHA-256 checksums for
all three pre-built platform archives (win-x64, linux-x64, win-arm64).
The regression test (test_include_file_document_symbols_directly) that
exercises the original crash scenario passes against v1.3.1 without the
workaround.
Co-authored-by: TheSmallKiwi <TheSmallKiwi@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
The upstream fix for the CRLF stale-tree crash (antaalt/shader-sense#44)
was merged and released as v1.3.1. This commit:
- Removes the client-side CRLF workaround (open_file override and
_preload_crlf_content helper) added in #1305, along with the
now-unused imports.
- Bumps _DEFAULT_VERSION to 1.3.1 and updates SHA-256 checksums for
all three pre-built platform archives (win-x64, linux-x64, win-arm64).
The regression test (test_include_file_document_symbols_directly) that
exercises the original crash scenario passes against v1.3.1 without the
workaround.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Max