Best practices for managing factories in a monorepo using `packwerk` / `packs-rails` for Rails engines

System Design
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 U72E9Y4W095

Hello all. How are people handling factories?

We are exploring using packwerk / packs-rails to bring a set of rails engines (currently in separate repo’s) together in a monorepo to reduce our development overhead.

In our engine based approach some models were duplicated (user/organisation are common examples), and others that were only needed for test setup (e.g. dependent database records to satisfy foreign keys) were put into the test/dummy application, and we just had the factories reference those models.

So we’re wondering how people are handling factory data for entities that are needed to setup the state of the world for each pack? Things that are outside the core concerns of the pack

2

We’ve namespaced our factories (literally, named them with the pack name as prefix, eg. orders__purchase_order_line_item). We manually verify that each pack’s tests invoke factories for packs which it explicitly depends upon (package.yml) since packwerk can’t check that for us. But, in that sense, we’re regarding the factories as part of the public API for each pack.

3

Message originally sent by slack user U72E9Y4W095

That’s certainly something we can try. Thanks