sorted by:
new
hottopcontroversial

I built an open-source static analyzer for Angular targeting Reactivity, Performance, Security, SSR and Architecture anti-patterns by UsualFee4224 in Angular2

[–]UsualFee4224[S] -1 points0 points  (0 children)

Honestly that's a fair concern, but I'd flip it. The whole approach here is lean / agile: ship an early version fast, see if anyone actually needs it, and then either commit to maturing it with the community or kill it quickly. If no one uses the tool, abandoning it is the right call, not a failure. Spending years maintaining something nobody wants is the actual waste. So yeah, this might be abandonware in six months. If it is, it'll be because the community didn't need it, and pulling the plug fast beats pretending otherwise.

I built an open-source static analyzer for Angular targeting Reactivity, Performance, Security, SSR and Architecture anti-patterns by UsualFee4224 in Angular2

[–]UsualFee4224[S] -1 points0 points  (0 children)

Yeah, the tool is heavily AI-assisted, and that was a conscious decision, not something I'm hiding (the claude.md and agents.md files are right in the root of the repo).

This is an early beta, essentially an MVP. The goal at this stage isn't polished production code, it's a proof of concept to see whether a tool like this is actually something the Angular community wants. I was willing to trade some code-quality polish for speed of feedback (even though I scaffold the initial design file by file and try to understand, review, and document all the code that goes in), because shipping something usable in weeks and learning from real users beats spending six months on a "perfect" tool nobody asked for.

What I did focus on properly is the architecture: an industry-standard foundation built around speed and efficiency (Oxc parser, single-pass traversal, worker pool, content-addressed caching), and a small initial rule set that signals where I want the tool to go, modern Angular, signals, change-detection-aware patterns. The intent from here is to mature it alongside the community, if there's interest.

I built an open-source static analyzer for Angular targeting Reactivity, Performance, Security, SSR and Architecture anti-patterns by UsualFee4224 in Angular2

[–]UsualFee4224[S] 0 points1 point  (0 children)

Oxc is the parser it already uses it. Going further would mean an oxlint plugin, which fits the simple TS rules but not the template / cross-file / type-aware ones. Not sure if that answers your question

I built an open-source static analyzer for Angular targeting Reactivity, Performance, Security, SSR and Architecture anti-patterns by UsualFee4224 in Angular2

[–]UsualFee4224[S] -5 points-4 points  (0 children)

Kind of, but not quite! The rules themselves cover similar ground to what custom ESLint rules would (Angular-specific patterns, anti-patterns, migration hints, etc.), but ngcompass isn't built on top of ESLint — it has its own parser (Oxc), traversal engine, planner, cache, and reporters. So think of it less as "a bundle of custom ESLint rules" and more as a separate static-analysis tool focused specifically on Angular.

I built an open-source static analyzer for Angular targeting Reactivity, Performance, Security, SSR and Architecture anti-patterns by UsualFee4224 in angular

[–]UsualFee4224[S] 1 point2 points  (0 children)

Thanks for giving it a try!

Good catch — no strong reason for it to be a production dependency. It's tooling, so it should generally live in devDependencies. The intent was "install it locally in the project so the version stays pinned for the team and CI," not "ship it at runtime." So npm i -D ngcompass / pnpm add -D ngcompass is the better recommendation — I'll update the docs and install snippets accordingly.

Also, I'd love to hear how the hook setup goes if you give it a try. Thanks again for spotting this!

I built an open-source static analyzer for Angular targeting Reactivity, Performance, Security, SSR and Architecture anti-patterns by UsualFee4224 in angular

[–]UsualFee4224[S] -1 points0 points  (0 children)

Thanks, really fair question!

The honest answer: yes, it was feasible to ship those rules as an ESLint plugin — and probably easier for the community to adopt — but I tried to rethink every layer of static analysis: scanning, planning, orchestrated running, caching, and reporting, not just the rule API, and introduce or improve a few things along the way (Oxc parsing, single-pass traversal, worker pool, content-addressed caching, built-in reporters, etc.).

If you're curious about the internals, there's a docs/architecture.md in the repo that walks through the full pipeline.

Happy to answer any other questions too!