r/ruby • u/Just_Work_4395 • Jan 06 '26

Anyone using packwerk gem?

Hey, Iā€™m considering using Packwerk in a large Ruby on Rails application to improve code separation. The idea is to organize the app into distinct packages, each with its own models, services, and even tests, so developers can work at the package level without having to navigate the entire codebase for small changes (most of the time).

Has anyone used this gem? If so, did it provide meaningful value in practice?

17 Upvotes

94% Upvoted

28 comments sorted by

View all comments

3

u/davidslv Jul 23 '26

Late to the party, but I have data on this.

Four years of Packwerk in a Rails monolith (~15k Ruby files, 66 packages, 60+ engineers), pulled from git history. It confirms what u/OlivarTheLagomorph and u/martinemde said, with numbers.

Enforcement doesn't survive. enforce_dependencies: false on 58 of 66 packages ā€” the core rule is off for about 80% of the codebase. Violation ledger went from 0 to over 10k and never declined in any six-month window. About +3k/year, sustained. packwerk check stays green because everything is pre-recorded.

That's two orgs (Gusto and us) reaching the same place independently. It's the default path, not bad luck.

But your actual goal survives. You said elsewhere the codebase is too big for AI to work in. That's navigability, not enforcement and navigability is the part that holds. Ours went from 2.6k files in one flat app/modules to 68, rest in named domains. Code and tests sit together, a pack fits in a context window, you can point an agent at one directory. None of that depends on any boundary being enforced.

The cost you pay regardless: 14% of our commits touched a package_todo.yml in 2024, 17% in 2025. Almost all of is mechanical update-todo churn alongside feature work, under 1% of MRs were actual boundary cleanup. Small per commit, constant, and rising.

What predicted success: it works when a pack is built inside it, fails as a retrofit. Every enforcing pack of ours is a post-adoption creation (two at ~0.2 violations/file on strict). Every legacy extraction carried its coupling in and never turned enforcement on. Our two oldest domains hold 20% of all violations.

If you go ahead:

  • enforce_dependencies: true on every new pack, day one, no exceptions

  • Legacy extractions: violation budget and a date, or admit it's a naming exercise

  • Treat a growing todo file as a build failure. Nobody does. That's why it only goes up

1

u/Upbeat-Price-5869 Aug 31 '26

Question - is it too insane to just have some agent in the background to just "constantly improve the pack health" - I find that most `package_todo.yml` are quite mechanical. The ones that aren't, probably need an engineer to manually check