Improving Packwerk Speed for Efficient Editor/IDE Linting

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Message originally sent by slack user U717FXJ8HWK

I really wish Packwerk was fast enough so that you could comfortably run it as a linter in your editor/IDE. :smile: There’s an extension for VS Code, but it would be a thousand times better if it could provide results instantly.

Yeah definitely would be great if it were instant! The rubocop community has a solution to run a rubocop server process which the extension can hit for faster results, since it skips all of the loading and configuration that would be otherwise required. Packwerk could do the same thing, since a lot of the time spent when running on just a single file is the boot up time. Also – are you using spring? That speeds it up a lot.

Message originally sent by slack user U717FXJ8HWK

Nice, I didn’t realize you could use Spring with Packwerk. :+1: However, after being burned by Spring too many times, I’ve added DISABLE_SPRING=1 to my environment variables globally. :smile:

You may be able to do DISABLE_SPRING= bin/packwerk check as your executable command for the extension.

To have it turned on just for the extension

Message originally sent by slack user U70TIGAX94P

Two thoughts, one looking back and one looking forward :smile:

• Packwerk was first developed with a focus on fast execution on single files specifically for editor integration. Not many people used the editor integration though so we made different tradeoffs later. We were able to drastically simplify configuration by trading off on startup time.
• Going forward, I can see two promising avenues to make editor integration faster:
â—¦ Use a persistent process similar to Rubocop Server (https://docs.rubocop.org/rubocop/usage/server.html)
â—¦ Integrate with the Ruby LSP, which will apparently get a plugin mechanism
Both of those options have the potential to be faster than just the spring integration AFAICT

Message originally sent by slack user U717FXJ8HWK

DISABLE_SPRING= works :+1:

Message originally sent by slack user U70TIGAX94P

Does it feel fast enough?

Another thing I’ve been thinking Philip is that at least at Gusto, we don’t actually need to boot up the Rails app to use packwerk. We know all of the load paths in advance because we use packs-rails . We used to only boot up the app during validate (changed in major version 2) to skip adding load paths to packwerk.yml, but I wonder how much startup time we can save by optionally inferring load paths (or just allowing them to be specified in config with globs).

Message originally sent by slack user U717FXJ8HWK

Now it takes around 6 seconds for linter messages to appear after saving a file. A Spring server boots up if it’s not already running, so I assume Spring is working fine. The same command takes around 2 seconds when ran in a terminal though.

Message originally sent by slack user U70TIGAX94P

Strange - shouldn’t be taking 6 seconds. 2 are still slow but much more acceptable

Message originally sent by slack user U70TIGAX94P

Alex, we need inflections too I think - maybe time for a separate thread