# Welcome to Interlace



Interlace is a family of TypeScript-native developer tools. Every plugin we ship is **measured against alternatives**, every claim is backed by a versioned benchmark, and every dependency we add is one we can defend.

## Where to go next [#where-to-go-next]

* **[What is Interlace](/docs/concepts/what-is-interlace)** — the philosophy and what the label guarantees.
* **[Ecosystem map](/docs/concepts/ecosystem-map)** — every product in the family today and what each one solves.
* **[How we measure](/docs/concepts/how-we-measure)** — the rubric behind every "X is faster than Y" claim.

## The products [#the-products]

| Product                   | Where to read                | Subdomain                                                        |
| ------------------------- | ---------------------------- | ---------------------------------------------------------------- |
| `eslint-plugin-*`         | ESLint plugin suite          | [eslint.interlace.tools](https://eslint.interlace.tools)         |
| `@interlace/serverless-*` | Serverless Framework plugins | [serverless.interlace.tools](https://serverless.interlace.tools) |
| `@interlace/ui`           | Design system + registry     | [ds.interlace.tools](https://ds.interlace.tools)                 |

The ESLint plugins are **unscoped** — you install `eslint-plugin-jwt`, with no `@interlace/` prefix — because ESLint resolves plugins by that name convention. The only scoped ESLint package is `@interlace/eslint-devkit`, the authoring toolkit.

More on the way.


# Ecosystem map



Each Interlace product is a separate package suite with its own subdomain, its own release cadence, and its own evidence files. They share a brand and a docs experience so they feel like the same product line — but each one is independently installable and independently versioned.

## The products today [#the-products-today]

### `eslint-plugin-*` [#eslint-plugin-]

A suite of ESLint plugins for security, accessibility, and modern framework correctness. Each plugin ships with a measured corpus and an explicit comparison set against the existing alternatives in its category.

These are **unscoped** packages — ESLint resolves plugins by the `eslint-plugin-<name>` convention, so putting them behind the `@interlace/` prefix would break config resolution. The one scoped ESLint package is `@interlace/eslint-devkit`, the toolkit we author the plugins with.

* **Read:** [eslint.interlace.tools](https://eslint.interlace.tools)
* **Sample plugins:** `eslint-plugin-jwt`, `eslint-plugin-mongodb-security`, `eslint-plugin-react-a11y`, `eslint-plugin-vercel-ai-security`

### `@interlace/serverless-*` [#interlaceserverless-]

TypeScript-native replacements for community Serverless Framework plugins. Cleanup on removal, CLI commands, no ghost billing — fixing the real problems that cost teams money and deploy time.

* **Read:** [serverless.interlace.tools](https://serverless.interlace.tools)
* **Sample plugins:** `@interlace/serverless-api-gateway-caching`, `@interlace/serverless-iam-roles-per-function`, `@interlace/serverless-devkit`

### `@interlace/ui` [#interlaceui]

The design system every Interlace site is built from — primitives, blocks, layout templates, and the token baseline (colour, type, spacing, radius, breakpoints) that keeps all of them looking like one product line.

It ships as a [shadcn-compatible registry](https://ui.shadcn.com/docs/registry) rather than an npm dependency, so you copy components into your own repo and own them outright — no version lock, no runtime dep on us:

```bash
npx shadcn@latest add https://ds.interlace.tools/r/button.json
```

Every component carries the same floor: axe-clean, dark mode, RTL, and keyboard support, all verified in CI against every story.

* **Browse + install:** [ds.interlace.tools](https://ds.interlace.tools)
* **See every state:** [storybook.interlace.tools](https://storybook.interlace.tools)

## How they relate [#how-they-relate]

Every product in the family agrees to the same **shared baseline**:

* **Same docs experience** — same theme, same navigation, same components, same brand tokens.
* **Same evidence contract** — every comparative claim cites a versioned, reproducible benchmark.
* **Same primitives** — TypeScript-first config, zero ghost runtime dependencies, full IntelliSense everywhere.

That's what "Interlace" guarantees as a label. The npm name follows whatever the ecosystem expects — unscoped for ESLint plugins, `@interlace/` for everything else — but the guarantees are the same either way.

## Adding new products [#adding-new-products]

The line is intentionally small today. Future products will appear here when they ship, not before — every product on this page has a measured corpus, a real user, and shipped releases.

If you have a use case Interlace doesn't cover yet, the best signal is to open an issue against an existing product asking for what's missing. The roadmap follows demand.


# Evidence philosophy



Most plugin READMEs say things like "faster", "lighter", "more secure" without saying "than what" or "by how much." Interlace doesn't.

## The contract [#the-contract]

Every comparative claim across every Interlace product must:

1. Name what it's compared to (the alternative, with a specific version).
2. Cite a versioned result file (a JSON benchmark, a measurement script).
3. Be reproducible by anyone who clones the repo.

If a claim cannot meet all three, it doesn't ship.

## Where claims appear [#where-claims-appear]

Each product's docs have two canonical pages:

* A **landscape** page — the comparison table for that product, backed by versioned benchmark result files.
* A **how-we-measure** page — the methodology: what each metric means, who's in the comparison set, why the rubric is fair.

This apex site explains the shared rubric in [how we measure](/docs/concepts/how-we-measure); each product's own landscape page lives in that product's docs.

## Why this is hard but worth it [#why-this-is-hard-but-worth-it]

It would be much easier to write "blazingly fast" without measuring. But:

* Users have been burned too many times by README claims that don't survive their actual workload.
* The discipline of having to measure forces real design decisions during development, not after.
* A versioned benchmark ages well — a vague claim doesn't.

The contract is the same one every Interlace product agrees to follow — see [how we measure](/docs/concepts/how-we-measure) for the four-axis rubric and what reproducibility means in practice.


# How we measure



Each product has its own per-product methodology page (e.g. ESLint's [how-we-measure](https://eslint.interlace.tools/docs/concepts/how-we-measure)). This page explains the **shared rubric** that every product builds on.

## The four-axis rubric [#the-four-axis-rubric]

Every Interlace benchmark reports against four axes, regardless of product domain:

| Axis            | Question it answers                                                                                                                           |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Correctness** | Does the tool catch what it claims to catch? Run against a corpus with known-positive and known-negative inputs; report precision and recall. |
| **Performance** | How long does it take on a representative workload? Wall-clock, CPU time, memory peak.                                                        |
| **Footprint**   | What does the user have to install — runtime deps, bundle size, peer-dep surface?                                                             |
| **Ergonomics**  | How much config is required to make it useful? Lines of YAML, lines of TS, error-message quality.                                             |

Per-product pages add domain-specific axes (e.g. ESLint adds rule-coverage; Serverless adds deployment-time impact).

## Comparison set selection [#comparison-set-selection]

The comparison set for any benchmark must be:

* **Public and named** — every alternative is linked, with the exact version benchmarked.
* **Representative** — if a category has a clear leader, it's in the set; we don't cherry-pick weak comparisons.
* **Currently maintained** — abandoned packages are noted but not used as the headline comparison.

## Reproducibility [#reproducibility]

Every benchmark suite ships with:

* A `README.md` that explains how to run it.
* A `latest.json` result file in the repo, with a timestamp and the host machine specs.
* Pinned dependency versions — the result is what you get when you run it on the same inputs against the same versions.

## Where to look [#where-to-look]

| Product                   | Suite location                                                                                     | Methodology                                                                                                                |
| ------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `eslint-plugin-*`         | [eslint/packages/benchmarks/](https://github.com/ofri-peretz/eslint/tree/main/packages/benchmarks) | [eslint.interlace.tools/docs/concepts/how-we-measure](https://eslint.interlace.tools/docs/concepts/how-we-measure)         |
| `@interlace/serverless-*` | (in development)                                                                                   | [serverless.interlace.tools/docs/concepts/how-we-measure](https://serverless.interlace.tools/docs/concepts/how-we-measure) |


# What is Interlace



Interlace is a family of small, focused, TypeScript-native developer tools. Each one solves a single problem really well, and together they share a baseline that makes them feel like the same product:

* **Same docs experience** — every product site uses the same Fumadocs theme, navigation, components, and brand tokens. Synced from a central baseline so they cannot drift.
* **Same evidence contract** — every comparative claim ("faster than X", "fewer deps than Y") is backed by a versioned benchmark file. No marketing assertion ships without a result behind it.
* **Same primitives** — TypeScript-first config, zero ghost runtime dependencies, full IntelliSense everywhere.

## What "interlace" means here [#what-interlace-means-here]

The name describes how the products relate. They are not a monolith and they are not unrelated — they **interlock**. The same brand, the same docs experience, the same evidence contract. A pattern proven in one product (e.g. cleanup-on-removal in `@interlace/serverless-api-gateway-caching`) becomes the template for the next one.

## What it is [#what-it-is]

Interlace is a **community and an ecosystem**, built in the open. Independent, MIT-licensed, and accountable to its users — not to investors. The work is funded by the people doing it, the direction is set by the people using it, and every claim is backed by evidence anyone can rerun.

It might grow into a company someday — that's not ruled out. But that decision will follow the work, not lead it. For now, "Interlace" is the shared standards (docs baseline, evidence contract, brand) that the products under it agree to follow.

## What it isn't (today) [#what-it-isnt-today]

* A framework. You don't pick "Interlace" — you pick a specific plugin that solves a specific problem.
* A bundle. You install `eslint-plugin-jwt` or `@interlace/serverless-api-gateway-caching` directly. There is no umbrella package.