There is nothing special about nesting packs from a packwerk perspective. In fact, every pack is nested in the root pack, but maybe you’d consider that the exception.
Last week, I added https://github.com/rubyatscale/packwerk-extensions#folder-visibility-checker to packwerk-extension, which gives you a folder-based visibility rule for packs: Unless pack is the sibling or parent, there will be a todo. With this extension, I believe, nesting does start to mean something
FWIW at gusto, we started nesting packs because we wanted to support “domain local use of packages” as well as “global use of packages” and we found that we didn’t want both of these uses to happen in the same folder.
<@U722X9GVQWA> We’re using nesting to create more context on the kinds of packs… we have application packs (task-based UIs, with views, routes & controllers), domain packs (core business logic around domain specific concepts), and component packs (everything else!).
Have any of you ever considered having applications, components and domain (in Gary’s example above) as top-level directories? We’re not at this point yet, but I thought if I’d ever go there, I would want to avoid the extra nesting. Also, having these concepts on the top level seems like a good example of “Screaming Architecture”.
I believe it would be even more “screaming,” if, instead of what you are proposing, you made the root folders rails_harness and packs (and nothing else) and then moved all of the Rails code away from the root. I proposed this for the Components-based Rails book and made it work with buildpacks (heroku / cloud foundry).