This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U70NN25TNJA
Hey there everyone! This might be a very silly question, but….does anyone have any experience using Packwerk for a non-Rails Ruby application? As far as I can from first glance, Packwerk seems to be pretty tightly coupled to Rails, but I might be misreading things.
For context, I am a developer at Checkr. Our Monolith is a bit of a “frankenlith” - a combination of Sinatra, Grape and some “Rails” family dependencies (ActiveRecord et al). Would (at least partially) moving to Rails be a prerequisite for us to make use of Packwerk?
Hi Mike! At the moment, I believe that the short answer to your question is “yes.” Packwerk currently depends on Rails and there is a desire by the maintainers at shopify not to complicate things with other frameworks.
I wrote https://github.com/Shopify/packwerk/pull/218 a while back, which would switch the requirements: instead of depending on Rails (and its autoloading), it would move it to zeitwerk (and its registration of autoloaders). However, as you can see in the comments, there were two issues that I didn’t manage to resolve and so the PR never landed.
It was situations like yours and the use of unbuilt gems that I wanted to support better. If you are interested in seeing if we can make some progress here, please let me know!
Thanks for the reply Stephan! I’d definitely be interested in this switch in dependencies. It sounds super helpful for our predicament! Although we have moving our “frankenlith” to being a more regularly shaped Rails monolith on our long-term roadmap, being able to make use of Packwerk sooner would be fabulous. As one can imagine, a large application that doesn’t even have consistent Rails conventions to fall back on has one or two modularity issues that Packwerk could help with
Let me know if there’s anything I can help with here