My side project ArchUnitTS reached 200 stars on GitHub - Lukas Niessen

"My open source library just hit 200 stars on GitHub, making it the #1 architecture testing framework in the TypeScript world! 🌍 🥇", wrote Lukas Niessen in his blog post. I read it eagerly and was impressed. Read more, in his own words!

...

This is a big moment for me and the backstory is actually quite simple. In my time as a consultant, we needed an architecture testing framework similar to ArchUnit — but for TypeScript. There was nothing on the market that fully met our needs, so I started building one myself in my spare time: ArchUnitTS.

That was about a year ago, and since then more developers have joined me in actively maintaining it. Now it doesn’t just have more GitHub stars than other libraries, it also offers more functionality and greater reliability (link to a detailed comparison at the bottom). And it’s already being used in multiple enterprises.

I want to give a special thank you to Jan Heimann, Tristan Kruse and Sina Rezaei, who are actively contributing to the project — and to everyone who has reported bugs, suggested features, or helped improve it in any way.

ArchUnit TS: https://github.com/LukasNiessen/ArchUnitTS

More info: ArchUnit TS, https://www.linkedin.com/feed/update/urn:li:activity:7379093943030013953/

🕒 5-Min Quickstart

1. Install

npm install archunit --save-dev

2. Write your first architecture tests

Here are some simple examples of tests you could write.

import { projectFiles, metrics } from 'archunit';

it('should not have circular dependencies', async () => {

const rule = projectFiles()

.inFolder('src/**')

.should()

.haveNoCycles();

await expect(rule).toPassAsync();

});

it('presentation layer should not depend on database layer', async () => {

const rule = projectFiles()

.inFolder('src/presentation/**')

.shouldNot()

.dependOnFiles()

.inFolder('src/database/**');

await expect(rule).toPassAsync();

});

it('should not contain too large files', async () => {

const rule = metrics()

.count()

.linesOfCode()

.shouldBeBelow(1000);

await expect(rule).toPassAsync();

});

it('only classes with high cohesion', async () => {

const rule = metrics()

.lcom()

.lcom96b()

.shouldBeBelow(0.3);

await expect(rule).toPassAsync();

});

That’s it. These tests live alongside your regular tests. They’ll fail if your architecture drifts or new violations appear.

3. CI / Pipeline Integration

Since these are just tests, they run like any other suite. You can also generate HTML reports (still in beta):

await metrics().count().exportAsHTML('reports/count.html');

await metrics().lcom().exportAsHTML('reports/lcom.html');

Then treat reports/ as CI artifacts (e.g. GitLab, GitHub Actions).

GitHub

Why Architecture Tests Matter

When code evolves, we often rely on unit and integration tests to catch regressions. But those don’t guard architectural boundaries. Over time, code can creep across layers, violate module structure, or create hidden coupling — especially in large teams or microservices scenarios.

Architecture tests (also called fitness functions) allow you to encode your architectural invariants in code. When a pull request breaks the boundary, the tests catch it — just like any failing unit test. In the age of LLMs and AI-driven code generation, these boundaries are more important than ever. Without them, models or scaffolding tools might inadvertently violate the architecture you carefully designed.

Comparisons & Unique Strengths

In the ArchUnitTS README, we compare us with other TypeScript architecture testing libraries. A few differentiators:

Empty-test protection: If a rule matches no files, we treat it as a failure (preventing silent false passes). GitHub

Rich metrics support: Cohesion (LCOM), coupling, distance metrics, custom metrics. GitHub

UML / diagram validation + slicing: You can validate that your architecture matches PlantUML diagrams or your Nx project graph. GitHub

Custom rules & metrics: You’re free to author your own rule logic or metric logic. GitHub

Universal framework support: Works with Jest, Vitest, Jasmine, Mocha, or others — with syntax sugar (toPassAsync) for the common ones. GitHub

Detailed error messages and logging: Clickable file paths, debug logs, etc. GitHub

Because of all this, I believe ArchUnitTS isn’t just the most popular by stars — it offers more robust tooling for real-world TypeScript architecture tests.

What’s Next?

Core engine extraction: We will probably decouple the core AST / analysis engine and adapt it for Python, Go, Rust, or others.

Stronger cross-language support: Hybrid projects (e.g. TS + Python backend) could share architecture rules.

Better reporting / dashboards: Make the HTML reports more interactive, support trend analysis over time.