This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U70K2MT6OHQ
Hey all! Excited to be here! We are still pretty early in our packwerk adoption but would love to get some feedback on some decisions we’ve made so far. We have some small wrappers around other non-rails 3rd party gems (for example: pundit). We followed Stephan’s suggestions in his book but then included some of these other wrappers as well, and decided to call it framework-shims instead of rails-shims.
Has anyone encountered this as well? Have you separated other non-rails wrappers into gems or some other construct instead?
Hey, good to hear more people is using packwerk 
I haven’t followed that approach, but given that you mentioned pundit , what we are doing is having the policies together with the controllers that use them. For the base ApplicationPolicy we keep that in the app_base which is our name for Stephan’s rails_shims .
Message originally sent by slack user U70K2MT6OHQ
Ah cool! We were a little hesitant to name it something like base or root because we didn’t want it to be de-facto solution when something didn’t fit in other packages. And good to hear you also added the application policy in there seems like we are on the right track 
This kept me thinking, maybe it’s wrong to have it there and should be in a separate place… because it knows about the user right? so it’d be a cyclic dependency ApplicationPolicy -> User -> ApplicationRecord , assuming ApplicationRecord and ApplicationPolicy are in the same pack. I didn’t notice this before because we don’t have Sorbet 
Message originally sent by slack user U70K2MT6OHQ
yeah that’s a good point 
I’m not liking having micro-packages to only have things like the ApplicationPolicy there :rolling_on_the_floor_laughing: I wonder if there is any other way, maybe user could be a Hash so we don’t have that dependency?
At Gusto we do a couple of things:
• We sometimes but not always wrap gems in helpful interfaces that allow us to be more specific to our use case. For example, we have a packs/gusto_slack package that wraps our slack integration.
• We call rails-shims packs/rails_controllers and packs/rails_models . It basically just houses are base controllers and we generally lock down dependencies on those, asking users to not add domain-specific responsibilities to those base models.
• We have a pack called packs/unpackaged_code_that_needs_to_be_organized . We moved everything in the root package to that pack and then added a danger check that asked users to categorize stuff in there as they have context for it. This pushes users to organize things as they encounter them.
Message originally sent by slack user U70K2MT6OHQ
that’s what i was thinking as well Santiago, but it feels little weird to dependency inject on that class that is generated by Pundit. And that’s super interesting Alex. We are still dividing up what we “know” but may get to that point as well.