Need clarification on setting a child pack within a parent pack on GitHub

Tools RubyAtScale
1

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Message originally sent by slack user U722X9GVQWA

Is there any further documentation on https://github.com/rubyatscale/packs/tree/dcab585c5d46126bc7731d60e59358c96aeceb15#set-packschild_pack-as-a-child-of-packsparent_pack? What is the intention / purpose of having a pack be a child of a parent pack? Anything special about such a pack?

2

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.

3

For RubyAtScale tooling, it depends on the gem. E.g., packs-rails requires you to add those nested folders (you can use globs).

4

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

5

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.

6

Message originally sent by slack user U722X9GVQWA

@stephan thank you! very helpful. this clarifies we don’t want to use the nesting option for the use case in question. thanks again.

7

<@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!).

8

So we nest them under those 3 “pack” directories.

9

packs/applications/admin
packs/applications/media_planner
packs/components/core_ui
packs/components/core_jobs
packs/domain/auth
packs/domain/products
packs/domain/inventory
packs/domain/orders

etc.

10

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”.

11

I’d like that. I think at the time tho the packs dir was required.

12

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).

13

Hmm, also interesting. Not sure about having just two top-level folders, though. Anyway, this is customizable, so I can make it fit.