◉ COOLJAPAN
← All posts
April 25, 2026 • 6 min read

SplitRS 0.3.1 Released — Your Editor Now Refactors Oversized Rust Files In-Place via LSP

SplitRS is the AST-based Rust refactoring tool that splits monolithic source files into clean, compilable modules. 0.3.1 ships splitrs-lsp — a language server with diagnostics, a Refactor with splitrs code action, and live config watch — so the split happens right inside Neovim, Helix, or VS Code.

release splitrs rust refactoring lsp ast developer-tools code-organization

Your 2,400-line lib.rs should not be a wall you keep scrolling past. Now your editor offers to split it for you.

Today we released SplitRS 0.3.1 — and with it splitrs-lsp, a Language Server Protocol implementation that brings SplitRS’s AST-based refactoring directly into your editor.

If you have not met SplitRS yet: it is a production-ready Rust refactoring tool that takes a large source file — the kind that grows past 1,000 lines until nobody wants to touch it — and splits it into well-organized, compilable modules. It parses with syn, clusters related methods by call graph, infers the right visibility (pub(super), pub(crate), or pub), and generates the use statements and mod.rs for you. It already handles generics, async, Arc/Mutex, trait impls, and nested types. We built it because we needed it: SplitRS has been the workhorse behind keeping the COOLJAPAN codebase under the 2,000-line-per-file policy, and it cut its teeth refactoring tens of thousands of lines of real production Rust.

No language runtime. No external tool to install per editor. No Python sidecar. SplitRS is pure Rust — syn for parsing, prettyplease for formatting — and it compiles to a single static binary. splitrs-lsp speaks LSP over stdio and runs alongside rust-analyzer, not instead of it.

Why 0.3.1 matters

The CLI has always worked. But refactoring is a thing you do while reading code, and the friction of dropping to a terminal, typing a path, and re-opening files broke that flow. 0.3.1 closes the gap:

This release also sharpens the core engine: trait implementations for the same type are now batched into a single shared module instead of scattering one file per trait, line-count estimates are computed from prettyplease-formatted output (no more drift between the preview and the files actually written), and when the output target is the crate root, SplitRS writes mod.rs rather than overwriting your lib.rs. Duplicate std::collections imports across split modules are deduplicated.

Technical Deep Dive: how the LSP fits the pipeline

SplitRS’s analysis pipeline is unchanged — splitrs-lsp is a thin, correct front-end onto it:

  1. AST parsing (syn). The server parses the open document the same way the CLI parses a file argument.
  2. FileAnalyzer + metrics. The same FileAnalyzer that drives the CLI produces the LoC / method / complexity numbers surfaced on hover, so the editor and the command line agree.
  3. Module generation. When you invoke the code action, the server runs the standard generation path — method clustering, import synthesis, visibility inference — and serializes the result into a WorkspaceEdit rather than writing to disk directly.
  4. Config layer (.splitrs.toml). A single Config is shared: the watcher reloads it on change, the diagnostics read max_lines/max_impl_lines from it, and CLI runs honor the same file.

splitrs-lsp ships as a second [[bin]] gated behind the lsp feature, which is on by default — so a plain cargo install splitrs gives you both binaries. The feature pulls in tower-lsp, a small tokio runtime, and dashmap for document state; if you want the language server without the CLI surface, build --no-default-features --features lsp.

Getting Started

Install both the CLI and the language server:

cargo install splitrs

Split a file from the command line (still the fastest path for one-off jobs):

splitrs --input src/large_file.rs --output src/large_file/ --split-impl-blocks --max-impl-lines 200

Then wire the language server into your editor. Helix (languages.toml):

[[language]]
name = "rust"
language-servers = ["rust-analyzer", "splitrs-lsp"]

[language-server.splitrs-lsp]
command = "splitrs-lsp"

Neovim:

vim.lsp.start({ name = 'splitrs-lsp', cmd = { 'splitrs-lsp' } })

Drop a .splitrs.toml in your project root so the server knows your thresholds:

[splitrs]
max_lines = 1000       # diagnostic when a file exceeds this
max_impl_lines = 300   # diagnostic on oversized impl blocks
split_impl_blocks = true

Now open a large file: hover the top for metrics, watch for the diagnostic, and trigger Refactor with splitrs when you are ready.

What’s New in 0.3.1

Tips

This is the foundation

SplitRS keeps the COOLJAPAN ecosystem maintainable from the inside. It is a pure-Rust development tool — syn and prettyplease, nothing more — built and used by the same team behind the rest of the stack, where the under-2,000-lines-per-file rule is policy rather than aspiration. 0.3.1 is the point where that discipline stops being a terminal chore and starts living in your editor.

Repository: https://github.com/cool-japan/splitrs

Star the repo if you have ever scrolled past a file that should have been ten files. Pure Rust refactoring is here — fast, safe, and right inside your editor.

— KitaSan at COOLJAPAN OÜ April 25, 2026

↑ Back to all posts