This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U72G25YSG30
Hi guys, what does it mean? Use engine: true in metadata? Not clear what’s the different and why engines autoload is preferred.
<@U72G25YSG30> The idea here is that instead of using packs-rails, you could choose to follow the Rails Docs to create an engine and then add a package.yml to make your engines a packwerk package.
Rails engine “autoload paths” (how zeitwerk, and therefore Rails, finds your code), are automatically set up by Rails. packs-rails sets up autoload paths manually, and does some other things.
The engine: true directive turns a folder of code into an “actual rails engine,” albeit through unconventional means (e.g. invoking certain Rails APIs to tell Rails that a folder of code is an engine, etc.)
We like packs-rails because we believe it provides an even simpler API than engines. As Rails engines become even simpler to use, and other frameworks (like rspec) support modular development out of the box, I wouldn’t be surprised if we no longer need packs-rails and are happy with the APIs provided by the underlying tools.
Let me know if this helps or if you have other questions 
Message originally sent by slack user U72G25YSG30
Yeah, it really helps, thanks!
I agree that packs-rails much simpler at least for granular migration stage.
Afterwards as soon as domain are established it’s possible to migrate to engines, but I do not like overhead related to versioning/gemfile and so on.
For what it’s worth, I think it’s possible to create a Rails engine without a Gemfile and only execute the tests for that Rails engine in the context of your broader modulith. That’s how packs-rails does it (tests are never run in isolation, which is why we don’t need separate Gemfiles)
Message originally sent by slack user U72G25YSG30
Engines approach require as well to implement dependency management solution, so if engine A is changed, tests from engine B (which depends on A) also should be run.
Message originally sent by slack user U72G25YSG30
But for starting point I prefer not to spend time on it and run the whole suite
Message originally sent by slack user U72G25YSG30
I like packs-rails cuz it makes process very granular and make it possible to split into small easy steps without breaking changes.
Message originally sent by slack user U72G25YSG30
As soon as all dependency/privacy violations are resolved I believe packs-rails is not needed.
Sounds good to me! An important principle of the toolchain (including packs-rails) is that you should be able to easily migrate off of it if you want different trade offs 
Message originally sent by slack user U72DOM2VVHS
Interestingly, I found the vanilla packwerk+rails engine approach while I was at Shopify pretty pleasant so their recommendation resonates with me based on that experience.
Though I think the lower lift of packs-rails will bring wider adoption of packwerk