ESLint is pass/fail. Every pattern is either an error everywhere or ignored entirely. This makes it useless for the most common real-world scenario: you have hundreds of occurrences of something you want to get rid of, but you can't fix them all at once.
Baseline introduces ratcheting. You set a ceiling on how many times a pattern can appear across your codebase. You migrate some, lower the ceiling. CI blocks any PR that increases the count. The number only goes down.
Next sprint: 180. Then 150. Eventually 0. This one concept has been the most useful thing in the tool for me -- I've used it to drive migrations on large codebases where the alternative was "ignore the lint rule on 200 files and hope for the best."
Other things it does that ESLint can't:
- Path-scoped pattern bans. "no db. in app/*/page.tsx" is one line of TOML.
- Dependency bans on package.json, not just source imports.
- Proximity rules. "every DELETE needs an orgId within 80 lines."
- File presence. Require LICENSE, forbid .env.
- Tailwind dark mode + semantic token enforcement.
Rust, single binary, tree-sitter for AST rules, rayon for parallel scanning. TOML config, 8 presets, also runs as an MCP server so AI tools can query the rules.
On crates.io and npm (`npx code-baseline scan`). MIT.
Inspired by Matt Holden's guardrail coding concept [1].
Pulumi updates: Yes, exactly. Pulumi manages infrastructure state and handles diff-based updates. When we ship new features or improvements, users run wraps email upgrade, and Pulumi figures out the minimal changes needed. We also have a versioned metadata system that auto-migrates configs - so if we change how we store deployment info, it upgrades transparently on next run.
Cost tracking: Yes! Every resource we create is tagged with ManagedBy: "wraps-cli" plus service-specific tags (Service: "email", Provider: "vercel", etc.). You can filter by these in AWS Cost Explorer to see exactly what Wraps infrastructure costs.
In practice, the costs are minimal - most users see $0.05-5/mo for the infrastructure itself (DynamoDB, Lambda, SQS). The main cost is just SES usage at $0.10 per 1,000 emails.
Automations is a visual workflow builder for multi-step sequences.
Consider:
- Welcome series (signup → 3 emails over a week)
- Cart abandonment (wait for purchase, timeout → reminder)
- Re-engagement (segment-based triggers)
- Multi-channel flows (email + SMS in one workflow)
You can trigger on events, segment changes, or schedules. Use delays, conditions (branch on contact properties), and wait-for-event (pause until X happens or timeout).
There's also an AI designer. You describe what you want in plain english, and it generates the workflow.
Baseline introduces ratcheting. You set a ceiling on how many times a pattern can appear across your codebase. You migrate some, lower the ceiling. CI blocks any PR that increases the count. The number only goes down.
```toml [[rule]] type = "ratchet" pattern = "legacyFetch(" max_count = 200 ```
Next sprint: 180. Then 150. Eventually 0. This one concept has been the most useful thing in the tool for me -- I've used it to drive migrations on large codebases where the alternative was "ignore the lint rule on 200 files and hope for the best."
Other things it does that ESLint can't: - Path-scoped pattern bans. "no db. in app/*/page.tsx" is one line of TOML. - Dependency bans on package.json, not just source imports. - Proximity rules. "every DELETE needs an orgId within 80 lines." - File presence. Require LICENSE, forbid .env. - Tailwind dark mode + semantic token enforcement.
Rust, single binary, tree-sitter for AST rules, rayon for parallel scanning. TOML config, 8 presets, also runs as an MCP server so AI tools can query the rules.
On crates.io and npm (`npx code-baseline scan`). MIT.
Inspired by Matt Holden's guardrail coding concept [1].
[1]: https://www.fuzzycomputer.com/posts/guardrail-coding
reply