Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

v0.1.26: File Operations You Can Trust, Cleaner Auto-Import, and Better Bench Coverage

v0.1.26 is a workflow release.

Not a flashy benchmark-only release, not a refactor release for the sake of internals, and not a one-feature drop. This one closes several editor pain points that show up in daily Solidity work: creating files, renaming files, deleting files, and getting imports updated without weird buffer races.

If you’ve ever renamed a Solidity file and then watched Foundry fail because buffers were ahead of disk, this release is aimed directly at that class of problem.

What shipped

1) File operations are now configurable

All file-operation behaviors are controlled via settings:

  • fileOperations.templateOnCreate
  • fileOperations.updateImportsOnRename
  • fileOperations.updateImportsOnDelete

Defaults are enabled in v0.1.26.

That gives you sane behavior out of the box, while still letting teams opt out if they want explicit/manual workflows.

Example (Neovim):

settings = {
  ["solidity-language-server"] = {
    fileOperations = {
      templateOnCreate = true,
      updateImportsOnRename = true,
      updateImportsOnDelete = true,
    },
  },
}

2) templateOnCreate is the canonical naming

Scaffolding behavior was standardized under templateOnCreate.

This avoids terminology drift and keeps editor settings consistent across clients. The behavior is the same idea as before, but now the setting is clearer and future-proof.

3) Create-file scaffolding lifecycle was fixed

A lot of subtle bugs around willCreateFiles/didCreateFiles are timing bugs between disk, buffer state, and client lifecycle order.

v0.1.26 improves this flow so new files reliably receive scaffold content without empty-file races or accidental duplicate insertion.

Example scaffold produced for MyToken.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
 
contract MyToken {
 
}

What generated files look like in v0.1.26:

Vault.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
 
contract Vault {
 
}

Vault.t.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
 
import {Test} from "forge-std/Test.sol";
 
contract VaultTest is Test {
 
}

Vault.s.sol

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
 
import {Script} from "forge-std/Script.sol";
 
contract VaultScript is Script {
 
}

4) Auto-import completion is more reliable

Top-level symbol completion and import-edit attachment were improved.

The practical result: completions that should add imports are far more predictable, especially in larger projects where candidate selection can be noisy.

Example:

// In A.sol
contract A {
    function f() external {}
}
 
// In B.sol (typing `A`)
contract B {
    A a;
}

Completion now more reliably attaches import edits like:

import {A} from "./A.sol";

5) Benchmarks expanded around file operations

Coverage was added/updated for file operation lifecycle flows:

  • workspace/willCreateFiles
  • workspace/willRenameFiles
  • workspace/willDeleteFiles

This matters because these flows are where “works in theory” often diverges from “works in editor under real usage.”

Representative lifecycle request shapes:

{
  "method": "workspace/willCreateFiles",
  "params": { "files": [{ "uri": "file:///.../C.sol" }] }
}
{
  "method": "workspace/willRenameFiles",
  "params": {
    "files": [{
      "oldUri": "file:///.../A.sol",
      "newUri": "file:///.../AA.sol"
    }]
  }
}
{
  "method": "workspace/willDeleteFiles",
  "params": { "files": [{ "uri": "file:///.../A.sol" }] }
}

Why this release matters

Most Solidity LSP discussions focus on the obvious methods: definition, hover, references, completion.

But the real friction for production users is often file lifecycle correctness:

  • You rename a file.
  • Imports are patched in open buffers.
  • Disk isn’t updated yet.
  • forge test/forge build fails.

From the LSP side, behavior can be perfectly valid while UX still feels broken unless users understand when to persist edits.

That’s why this release also came with practical docs updates around editor workflows (for example, writing all changed buffers after renames).

Current benchmark snapshot context

For the release line around v0.1.26, benchmark summaries now explicitly include file-operation methods in the reporting flow.

This is important because file-op methods are often underrepresented in LSP comparisons even though they have high day-to-day impact.

Upgrade notes

If you’re already on solidity-language-server, v0.1.26 is a straightforward update:

cargo install solidity-language-server

Or download binaries from:

  • /changelog

If your team prefers explicit/manual file operation behavior, you can toggle the new settings accordingly.

Final note

v0.1.26 is about reducing “surprise cost.”

When file operations happen, users should get deterministic results. When completions imply auto-import, they should attach edits correctly. And when benchmark claims are made, file-op lifecycle methods should be part of the evidence.

That’s what this release delivers.