This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Hi all, at my project we are thinking on starting a modularization effort (currently a monolithic rails app) and I’m inclined towards using engines + packwerk. I’d like to ask people that have done this in the past for any suggestions on what would be a good first step, and more in concrete I’ve one question. Would you recommend to start:
Creating an engine and moving the code for one component in there, and then as a follow up step make it be a packwerk package
Creating a packwerk package for one component, and then as a follow up step move it to an engine
Doing both at the same time (creating the engine + the packwerk package)
Move as much code as you can into as many good-ish domain packages as you can come up with (you’ll largely be dealing with relative file reference issues, code loading, and meta-programming issues
Activate all protections and try to get them to zero
When a package is at zero violations and has no package dependency, only dependencies on an engine, consider making it an engine.
I suspect that for an app of significant size the time between 2 and 3 is “many months” to “a few years”
Thanks for replying @stephan. I’ve been looking at the source code of your yet to release book, and it looks like a good approach . My main concerns with that approach are related to rails autoloading, rspec setup, etc that would be better solved with an isolated engine I guess…
Apart from that, I think in your other books you mention as a first step to make the entire repo be an engine and then start extracting out smaller components. Is that right? Is that still valid or maybe it isn’t really viable for large projects and maybe not so important now that we have packwerk?
The entire app in an engine is still a totally valid (but super-heavy-lift and maybe unnecessary) step in many scenarios. I am no longer convinced that the spec and dependency separation is a net-positive thing. There are just too many pitfalls around drift towards the main app. Which, incidentally, doesn’t happen with packages because all that stuff is shared
. My main concerns with that approach are related to rails autoloading, rspec setup, etc that would be better solved with an isolated engine I guess…