How to effectively move Rails concerns without causing dependency violations?

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 U729CX72B8B

Topic: Moving Rails Concerns - I noticed we had a long list of dependency violations for our Conversions concern (convert miles to meters, hours to minutes etc.) and decided to make a “utils” pack. Once I realized I’d have to go find all the places where Conversions methods were being called I got gun shy and moved it back. I’m very much in an experimental phase but wondered if/when you all started messing with mixins and concerns in your transition process?

2

Message originally sent by slack user U717FXJ8HWK

I don’t think we’ve ever had a phase where we addressed mixins specifically, it’s just a part of solving violations in general. :man-shrugging:

If Conversions concern is generic enough, you could make it public and call it a day. However, personally I don’t like concerns at all, I’d rather have a public module with methods. :smile:

3

I have the same issue!

you could make it public
what does it mean? like its own pack?

I guess they should be libraries/gems but don’t like making gems for a few lines of code.

4

Message originally sent by slack user U717FXJ8HWK

Yes, I was referring to this:

and decided to make a “utils” pack

Since there was already an utils pack, making the concern public should also work.

5

Oh ok thanks, I guess I should move small things shared to a utils pack

6

Message originally sent by slack user U717FXJ8HWK

However, an utils pack might be a problem in and of itself, as it might become just a collection of random stuff that is used in a lot of places.

7

Agree, but do you have other alternatives besides copy/pasting code or exporting to a gem? Following the example converting things (Leora example) ?
Something I’d like is to have is shared across all the packs (like application controller, the job/worker base class).

8

Message originally sent by slack user U717FXJ8HWK

I think its own pack would make the most sense here. For base classes, one of the books on modularization suggests you put those classes into a rails_shims pack. Here’s the folder from the book.

9

oh great! thank you

10

<@U729CX72B8B> Question about

Once I realized I’d have to go find all the places ….
Can you tell me what behavior you were seeing? Moving a constant into a different packs with bin/packs and packs-rails shouldn’t require you to actually change how a constant is defined. You can optionally choose to change the constant (e.g. nest a constant under the pack namespace), but it’s not actually necessary.

Typically at Gusto, I recommend folks move files/constants to different packs as an independent step before changing the constant module nesting and updating code that uses that constant. This lets you get incremental value (have code in the right place) without opening up a big can of worms.

Would this work for you?

11

Message originally sent by slack user U729CX72B8B

let me try! I started experimenting with packwerk and use_packs (adding packs into our autoload_paths manually) to see what it gave, going to add packs-rails into the Gemfile now