I built ezRegex because I was tired of writing ugly regex patterns just to search for a few words in any order.
For example, if I ever wanted to find lines containing both carl and paid, I had to type:
carl.*paid|paid.*carlThat’s fine for two words. But with three words, or four? it explodes. With six, it gets ridiculous. I kept hitting this in real projects, and it felt like a problem that should be solved once, properly, with a UI.
Why I made it
I wanted a tool that felt like VS Code search, but smarter:
- Type terms naturally
- Toggle match-case and whole-word per term
- Choose how matching should work
- Get usable results without hand-crafting regex
The goal was simple: remove regex busywork, keep search power.
The core idea
ezRegex takes your terms and generates the pattern strategy for you.
It supports three modes:
- Permutations: generates all possible term orders joined with
.* - Lookahead: builds cleaner patterns like
^(?=.*term1)(?=.*term2).*$ - Proximity: finds terms within N lines of each other (not something plain regex handles well in workspace-wide search)
That last mode pushed ezRegex beyond “regex generator” into “search workflow tool.”
Tech stack
ezRegex is a VS Code extension built with:
- TypeScript
- VS Code Extension API
- Webview UI in the VS Code sidebar
- Node.js runtime inside the extension host
It compiles with tsc and runs from out/extension.js.
The panel is activated with onView:ezregex-sidebar, so it feels native in the Activity Bar.
Design choices I cared about
I wanted the extension to be useful in real projects, not just demos.
- Per-term controls instead of one global setting
- Inline sidebar results with click-to-navigate
- Fast-enough workspace scanning with sane exclusions and capped results
- Automatic fallback to lookahead when permutations become too large
I also made sure the state is persisted, so your terms and mode are still there when you come back.
What I learned
Building ezRegex reminded me that “small dev pain” is often worth solving.
Regex is powerful, but authoring complex patterns manually is not where developers should spend their energy.
The most valuable part wasn’t generating regex strings. It was shaping the whole search experience around how people actually debug code.
