This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U70DMI6W1TM
OK, having a weird issue: we have packs defined in two places – within /app (covering code we haven’t yet moved into our domain-specific packs) and in /services (the domain-specific packs; these are Rails engines). We’re trying to add a third location to differentiate packs with HTTP APIs (which will stay in services) and those that are purely internal, which will live in /packages and which won’t be engines.
My problem is that packwerk check is warning when code in one of the new /packages violates a /services dependency, but it isn’t warning in the other direction, when code in a /services pack violates a /packages dependency. Pack config is the same between the two (enforce_privacy and enforce_dependencies both set to true in all relevant packs)
Yeah, that’s the problem – I can repro it in our system (where the /packages pack is super barebones), but the system as a whole is … very far from minimal. I haven’t had time to stand up a fresh Rails 6 app, add an engine to it, and try there yet
So I pulled your repo and noticed a couple of things. The path to EaterData::Eater is packages/eater_data/models/eater.rb. By default, zeitwerk won’t know how to find this. You need to configure your autoload paths so that zeitwerk would know how to find these constants, as packwerk relies on the conventions of zeitwerk to work.