This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U70VT3MWTF5
Another question, are there any plans on tracking external dependencies?
One of the issues we have in our project is the fact that there is a large number of gems, which is a maintenance burden. Some of those are now unused or used by a few components. We also have many different gems that are used for the same purpose, like handling http requests.
I’m asking this, because manually checking who uses a given gem is not straightforward. Some are autoloaded, some have a namespace, etc.
@AlexEvanczuk and I have spoken many times about what we’d get if the constant resolution was built on sorbet… then you could likely (at least for some gems) include dependencies on them in the packwerk feedback system
but since that is no longer within the core mission of packwerk (to help you modularize your own domain) I am not sure the added complexity would merit it being added
As Stephan said — no current plans… but I’d be so excited if we had this feature too!
There is a way to get this implemented without a sorbet-AST based constant resolution. Since constants from gems aren’t autoloaded via zeitwerk, we can’t rely on normal packwerk mechanisms to identify which gem a constant comes from. However, if you use sorbet, we could lean into tapioca to implement this.
Namely, packwerk could identify which constants come from which gem by using the gem RBIs generated by tapioca, and then when it finds a constant, if that constant can’t be mapped to a pack, it checks the gem constants index.
This would be awesome though. Like you said we could identify dead code, identify gems only used by one system (perhaps that system should be extracted?), and more. Would love to help support you in building this if other packwerk maintainers would buy into it.