This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
hello from GitHub! We are still in the early stages of utilizing packwerk but it has been brought up that it is fairly slow to run for every PR against our admittedly large monolith. What workflows do other organizations use for packwerk? Do you require all deprecated_references.yml files to be updated as part of the content of every PR? Or do you do something out of band? Or is the speed just not an issue?
We at gusto are looking into performance improvements. At the same time we don’t yet have check as a blocking check on CI. We did recently turn on validate as a blocking step! Slowly getting there
great to hear @stephan! I’m hacking on a branch to parallelize the run and I’m seeing about 3x perf improvement so far. I should have something pushed tomorrow. I’ll let you know if you are interested.
It’s an extremely rough proof of concept right now but the basic idea if to run file_processor.call in parallel processes. There is quite a lot of refactoring needed because the current implementations rely on mutating a reference_lister but I’m fairly confident that is not a necessary mutation and that work can be done on the parent process after the parallel execution is done https://github.com/Shopify/packwerk/compare/main...mclark:parallel-packwerk
oh that’s interesting! I briefly looked into what parser options there were but didn’t find a clear alternative that would work. I’d be interested to hear what you were considering. The parallel gem has been amazingly simple to leverage so I just kept ploughing forward with that for now.
hello from GitHub! We are still in the early stages of utilizing packwerk but it has been brought up that it is fairly slow to run for every PR against our admittedly large monolith. What workflows do other organizations use for packwerk? Do you require all 
