Think of srgn as a blend of rip-grep, tree-sitter and GNU `tr`/`sed`. At its core, it most closely resembles `tr`, but expands on it in two important ways.

First, srgn provides scoping, used to specify what part of an input to work on. This can be literal text, regular expressions, or tree-sitter queries. The latter is the most interesting one. As tree-sitter queries can be tough to construct (although the tool is excellent, with an online playground for testing and more), srgn has pre-defined queries and makes an effort to unify these across languages. For example, across TypeScript, C#, Go, Rust and Python, you can specify to scope all "comments", and it (hopefully) just works as expected, despite these languages having different ideas of how comments work and look like (C# has multi-line and inline, for example, while Python only has a single type, all of which is also reflected in what tree-sitter calls those corresponding nodes).

Secondly, there's actions, which simply perform text manipulation on whatever is in scope from the previous step. One could delete certain parts of all comments, for example, or rewrite all import statements across an entire code base (https://github.com/alexpovel/srgn#mass-import-module-renamin...).

I had looked around a bunch for similar tools (https://github.com/alexpovel/srgn#similar-tools), but couldn't find any that quite did what srgn does.

The CLI is a rather thin wrapper around the Rust library, which is usable in the usual way.

By the way, the name srgn stands for surgeon, in the sense of a code surgeon: precise manipulation of text. Regular expressions and tree-sitter queries can be combined, which turns out to be much more powerful than either of these by itself, and also fills a different niche than LSP-powered Rename all-like features. It can also be used in CI, as a simple custom linter ("fail if you find any 'TODO' strings in comments").

A lot of the use cases can be covered by just regex, and then fixing mistakes manually; srgn mainly inches the precision of these operations closer to 100%, for when it's needed (like large refactors, where srgn offers full parallelization as well).