* Fix find_project_root hijacking git worktrees nested under a Serena project
find_project_root searched all ancestor levels for .serena/project.yml
before ever looking for .git. A git worktree whose own .git is a pointer
file, nested under a directory that is an explicit Serena project, was
resolved to the ancestor project instead of the worktree. With CLI agents
that launch via --project-from-cwd (Claude Code, Codex, Gemini), this
silently bound the server to the wrong working tree: reads returned stale
symbols and edits landed in the parent repo.
Walk up in a single pass so the nearest project boundary wins, whether it
is a .serena/project.yml or a .git (dir or worktree/submodule pointer
file). Same-level behavior is unchanged. Adds a regression test.
* Document worktree project-root fix in changelog and usage docs
upon project activation
Serena searches for the plugin instance upon project activation, and if the instance is not found
and the setting is configured, launches a new IDE instance based on the command
* Remove obsolete/outdated content
* git-worktree:
- Remove incorrect recommendation to copy the entire .serena folder
in order to retain the cache (cache contains abs. paths)
- Recommend to add the .serena folder to version control instead
(which will not include the cache folder)
Relates to #805
* Add util function subprocess_util.convert_shell_cmd
* Apply function in
- StdioLanguageServer (replacing use of quote_arg function)
- RuntimeDependencyCollection (previously no quoting applied)
* 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.
Add structured non-source file types (.yaml, .json, .toml, .graphql,
.proto, .sql, .tf, .hcl, etc.) to the read-file nudge set.
These extensions are common in real-world projects and repeated raw
reads of them are equally well served by `search_for_pattern` or
other Serena tools — the same rationale that applies to .py/.ts already
applies to config, schema, and query files.
Note added to the docstring: `search_for_pattern` works regardless of
extension and is always a valid alternative to repeated raw reads.
The _is_ignored_relative_path method used to raise FileNotFoundError
when checking a path that does not exist on disk. This prevented
editing tools (replace_content, insert_after_symbol, etc.) from
operating on newly created files.
Since a non-existent file cannot be matched by ignore patterns,
returning False (not ignored) is semantically correct and safe.
Changes:
- _is_ignored_relative_path: return False instead of raising for
non-existent paths, with a debug log message
- validate_relative_path docstring: updated to reflect new behavior
- Added 3 test cases covering non-existent path scenarios
* constants.py should remain the central place where a root path
is determined based on source file location
* SerenaPaths should consistently use strings
Serena's file-to-language router already maps `.t` to the Perl LS
(`Language.PERL` in `solidlsp/ls_config.py`), but the
Perl::LanguageServer-side `fileFilter` was hardcoded to
`[".pm", ".pl"]`. As a result Perl::LanguageServer skipped `.t`
files entirely: symbol queries on a `.t` returned empty, and
references to `.pm`/`.pl` subs missed any callers defined in
`.t` files.
Add `.t` to the filter, deduplicate the two `fileFilter` literals
into a `_FILE_FILTER` class constant, and note the sync requirement
with `Language.PERL.get_source_fn_matcher()` in a comment. Cover
the behavior with a new cross-file references test plus a `helper.t`
fixture; the test fails on unpatched `main` and passes on this
branch.
Tomi P. Hakala