Make Packwerk work in in-repo gems and other dependencies
Opened this issue · 5 comments
Description
Currently Packwerk can only check constant references that are being autoloaded. This excludes any dependencies and in-repo gems that could exist in a codebase. Especially for in-repo gems we have a strong need for boundary checking.
To Reproduce
Add a package.yml with enforced privacy or dependency violations and run packwerk update
or packwerk check
, neither of these will work for non-autoloaded packages.
Expected Behaviour
Dependencies and other packages that are not autoloaded should still have boundaries enforced.
Version Information
- Packwerk: v1.0.0
- Ruby: 2.7.1p83
@lastgabs and I discussed this on the pod hangout and I suggested she try adding the in-repo gems to the load_paths
in packwerk.yml
and see what happens. She’s going to do that shortly and report back.
(Maybe I should’ve suggested package_paths
instead. The distinction is not very clear to me.)
I investigated how to decouple from zeitwerk and documented the findings in Shopify/constant_resolver#26.
Seems actually like using Sorbet is the best bet, but that would be a major rewrite of packwerk. Might still make sense at some point.
This is an older issue but also wanted to link #218 which provides an implementation for and interesting discussion around allowing packwerk to work in any gems that use zeitwerk for autoloading!
Hey, I just wanna ask for any updates on this.
I face it during the research for trying to enforce boundaries of external gem with package.yml config.
I.e. Gemfile includes any external gem and this gem has package.yml
file with a public interface, and I want to enforce privacy violations for that external gem. I thought it possible via extension config, but it's not, and packwerk validate
getting failed due to relative paths checks, even if I put explicitly absolute path to main package.yml file:
dependencies:
- ../my_external_gems/my_gem
and packwerk update-todo
also cannot catch violations from external gem as well, even with Zeitwerk::Loader.eager_load_all
setup. So I think this issue is exactly about it (in terms of other dependencies
). Is it in the plans?