This is actually intentional behavior. It’s perhaps confusing especially in this case – I’m wondering if we should make a change.
The issue here is Admin::Domain::Lib::Next::Admin::Dataconcat::Commands::BaseCommand doesn’t actually define any behavior! It’s an empty class that doesn’t define any methods or anything, so it’s not considered a definition.
Oh interesting. some of the other classes don’t have methods either, so i didn’t realize that was needed. apologies for the wild goose chase, as it seems
::one::Foo has methods, which is the only constant that needs em other than BaseCommand to have matching violations.
And no apology necessary – this is helpful feedback, thanks for your patience and helping me figure it out! The rationale behind ignoring constants that don’t define behavior is that at least in Gusto’s monolith, it’s really common for pack A to define a constant, and pack B to define additional submodules under that one. I wouldn’t recommend that pattern, but it seemed like counting those as definitions would lead to too much noise. I’m wondering if I should reconsider that and might see if I get more of the same feedback.
Let me know if you have any other feedback, if you think you’d be able to use packs in your monolith, and if not, what changes would need to be there to make it useful for you!
Ah, ok i understand. Yeah and this rails app was just thrown together to test. so normally there would not be empty classes. we definitely have a need for boundary enforcement. I think that packwerk will work for us, once we convert to zeitwerk. which seems to be necessary to get to rails 7 anyway. I think as i test within a real codebase, it’ll become more clear. Thanks for the help figuring this out