How to enforce privacy in the root package and handle dependencies in a Rails application?

Tools Packwerk
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 U722S61U8KS

question around the root package being enforce_privacy: false and the suggestion

enforcing privacy is often not useful for the root package, because it would require defining a public interface for something that should only be a thin wrapper in the first place.
I want to:

  1. set my root package to enforce_privacy: true
  2. write thin wrappers inside app/public to access stuff internal to root package
  3. make my packs/current_project dependent on . and only have access to the app/public
  4. have less TODO’s in my packs/current_project/packwerk_todo.yml
  5. if at some stage I move out the “internal root stuff” into it’s own package, I can change my dependency inside of packs/current_project

am I missing something? given that root package is bound to stay around for quite a while, how could ever have my TODO’s removed from various packwerk_todo.yml files? is there something I am missing? another approach?

2

Message originally sent by slack user U722S61U8KS

reading in https://leanpub.com/package-based-rails-applications/c/railsconf2023

The first “group” (group #1) contains only the root package “.”. This package has no privacy violations because we emptied it out completely during the refactorings of Chapter 2. Turning on privacy enforcement is straightforward and will not require further work because there are no violations: We can and should just do it.

is this the thinking in general? move “EVERYTHING” out of root super early and hence not even have an app/public ?

3

@stephan is out this week, but that’s the idea. Of course there’s nothing objectively wrong or that will break if you leave things in your root pack, but we tend to think of the root pack as a sort of “application harness” that depends on all other packs to boot up the overall app, with nothing depending on it. By emptying out the root pack in the beginning, it helps it become less of a dumping ground (or alternatively moves the dumping ground to an explicit location like packs/unorganized_code ) which I think helps push things to be more organized long-term.

4

Message originally sent by slack user U722S61U8KS

perfect thanks, we will continue with our “root pack being the monolith” for the time being - time will tell if it’s a good idea :slightly_smiling_face:

5

Please report back on what you learn! :pray:

6

I am finally back from a bunch of weeks with lots of travel. I am still very interesting in hearing updates on how things go, <@U722S61U8KS>!

7

(also… +1 to Alex’ points)

8

Message originally sent by slack user U722S61U8KS

for the moment it’s steady as it goes - as I mentioned we are “scared” to move everything out and making this change was a start but we will only really tell in next month or so when we move a bunch of code out into a pack that will still have inter dependence with the main “legacy monlith app”