Archprint is a tool that infers architectural rules from the real import graph of a TypeScript repository and automatically writes evidence-backed rules into the existing toolchain. Its core goal is not to impose an external rulebook on a project, but to first survey how the code is actually structured, and then turn boundaries that are already followed into automated checks, so that architectural drift is discovered in the editor and CI rather than only surfacing weeks later in review.
Purpose It is aimed at developers, tech leads, code reviewers, and teams using AI coding agents. For the former, it generates evidence-backed ESLint and dependency-cruiser rules; for reviewers, archprint check only flags rule violations newly introduced by a single change, rather than dredging up old issues; for AI agents, it provides project rules and evidence via MCP; and for anyone evaluating a codebase, it gives an honest picture of the project's actual structure.
Main capabilities Archprint scans TypeScript projects, identifies rules the code already follows, and shows the evidence for each rule: number of compliant files, violating files, and confidence. It uses the Wilson score lower bound for statistical confidence judgments, classifying each rule as AUTO (enforceable), SUGGEST (provisional, for review), or REJECT (insufficient signal). Only rule families with clear mechanical signals are trusted by default and automatically generated, including forbidden imports (AP-001, AP-002), circular dependencies, test isolation, import style, console isolation, and public API barrels; structural rule families (such as layers, role boundaries, UI/data separation, entry-point purity, server/client, feature slice isolation, environment variable access, workspace package APIs, stories isolation, dependency hygiene, and dependency declarations) are kept for review by default, and are only written into enforced configuration with --include-structural. It can also recognize stacks such as Next.js, Nest, SvelteKit, Nuxt, and Remix, and classify React, Angular, Vue, and Svelte components, making component-related rules applicable across frameworks.
Usage Requires Node 20 or newer, and runs in a directory containing tsconfig.json. Common commands include init, wire, generate, generate --check, eject, migrate, check, allow, and others.init generates configuration and connects, wire inserts managed references into existing enforcement tools, eject can remove Archprint's files and all wired references and restore the configuration to its original state. archprint generate --check can first run the generated ESLint rules to verify they pass before connecting. Rules are written to .archprint/config.json, and when ESLint or dependency-cruiser is detected, the corresponding .archprint/eslint.mjs or .archprint/dependency-cruiser.json is generated. --expand additionally writes rule cards, fixtures, ts-arch tests, as well as Mermaid and Graphviz DOT hierarchy diagrams. In a monorepo, scan and recommend can accept a root directory and cover all apps, whereas init and generate target only one app at a time. It can also be installed into a project via npm install --save-dev archprint.
Use cases Suitable for TypeScript teams that want to turn implicit architectural boundaries in their codebase into executable checks; for code review processes that want reviews to focus only on newly introduced breakage without being drowned by historical backlog; for teams that want AI coding agents, via MCP, to understand project rules before writing code and check their own changes; and for evaluators who need to quickly understand a project's actual structure. In CI, archprint check can compare against a baseline branch and report only violations introduced by the current changes, displaying them inline on pull requests on GitHub, warning only by default, with --fail-on new available to make it fail.
Limitations Archprint only reports; enforcement is still carried out by the project's linter. Circular dependencies are currently only reported as results and are not written into rules. Rules involving structural inference may be unreliable due to incorrect path inference, so they are not enforced by default. Statistical confidence is based on the number of files and the compliance ratio, so evidence may be insufficient for small repositories. Currently no specific charging, pricing, or platform restriction information is provided.
