Transitive Dependencies

[shioyama]

If you have three packages (based on the ones in the Packwerk intro video):

# app/models/building/package.yml
enforce_depencencies: true
dependencies:
- app/models/vehicle

# app/models/building/house.rb
module Building
  class House
    def initialize(blocks:, vehicle:)
      @blocks = blocks
      @vehicle = Vehicle::Truck.new(
        engine: Parts::CustomEngine.new
      )
    end
  end
end

# app/models/vehicle/package.yml
enforce_dependencies: true
dependencies:
- app/models/parts

# app/models/vehicle/truck.rb
module Vehicle
  class Truck
    def initialize(engine: Parts::Engine.new)
      @engine = engine
    end
  end
end

# app/models/parts/package.yml
enforce_dependencies: true
dependencies:

# app/models/parts/engine.rb
module Parts
  class Engine
  end
end

# app/models/parts/custom_engine.rb
module Parts
  class CustomEngine
  end
end

Based on the common understanding of "dependency", you would expect that referencing Parts::TruckEngine from inside Building::House would be allowed since building depends on vehicle, which depends on parts, which contains Parts::TruckEngine. But this would in fact fail since Packwerk does not consider dependencies transitively, so you would have to change the app/models/building package like so:

 # app/models/building/package.yml
 enforce_depencencies: true
 dependencies:
 - app/models/vehicle
+- app/models/parts

This is fine for three packages like this, but the problem scales badly with number of packages. We now have nearly 100 packages in our core monolith and the number of times dependencies are duplicated in package.yml files is getting out of hand.

I'd like to propose that Packwerk consider dependencies transitively, such that the change to app/models/building/package.yml would not be necessary. This seems like it shouldn't be hard to do.

Any thoughts?

[gmcgibbon]

After some discussion internally about this, we decided to keep package dependencies transitive. This is because it is immediately obvious what a package depends on, and there is no guesswork when moving / extracting / isolating packages from one another.

[exterm]

Indeed I think the explicitness is a huge advantage over how gem dependencies work.

It seems the problem described by Chris is one of granularity. Would it alleviate some of the problems felt at Shopify if dependencies implicitly included nested packages?

E.g. if a specified dependency on components/merchandising would implicitly add dependencies on components/merchandising/*.

Or if we allowed explicitly including nested packages by specifying the asterisk.

[alexevanczuk]

At least at Gusto, we don't use nested packs enough for it to resolve the pain felt here. We've found this pain the most for things like utilities that all product domain packs depend on.

What if we supported package groups?

e.g.:

# packwerk.yml
package_groups:
  utilities:
    - packs/feature_flags
    - packs/background_jobs
    - packs/rails_shims
    - packs/authentication
    - packs/authorization
    - packs/whatever

# packs/my_pack/package.yml
dependencies:
  - utilities

This would help us a lot at Gusto and feels like a compromise between implicitness and explicitness.

[mclark]

Agreed.

you would expect that referencing Parts::TruckEngine from inside Building::House would be allowed since building depends on vehicle, which depends on parts, which contains Parts::TruckEngine

From a gem perspective, I might expect Parts::TructEngine to be loaded and defined, but that's a different concern that should be kept separate. By referencing Parts::TruckEngine directly from Building::House you are adding an explicit dependency on parts from building and that should be part of the package.yml for building.

Dependency Injection works around this by having house just take a vehicle, or some implementation of an engine interface as an initialization parameter rather than knowing about concrete implementations, but maybe that's overkill in your case.