parallel: true broken for ale

[thewatts]

👋 First off - I'm so thankful for this gem and what it provides our team.

I'm in no way jumping in here to complain - I understand that most of what this app does is delegate out to rubocop, and what could be going on is likely a rubocop issue.

I did want to post something here though, in case someone ran into the same issue (I haven't found a related issue yet on this repo, or rubocop).

Important context - we use a custom .standard.yml file - which includes the options in the README, specifically parallel: true.

---

I use ale for linting/auto-fixing, and recently noticed that in between different projects, standard fixing was working on save, and in others - it wasn't.

Digging into this more specifically - I found that the jump from standard 1.13 to 1.14 causes Ale to fail to run its fix command.

Granted, the only changes here are upgrading rubocop to 1.32.0

To clarify here - listing does work, fixing does not.

In digging into the changes, it looks like changes were made to the rubocop parallel option

The current fix:

Setting parallel back to false fixes the problem - and ale works once again.

---

1.13

CleanShot.2023-02-27.at.16.42.11.mp4

1.14

CleanShot.2023-02-27.at.16.42.56.mp4

[searls]

Thanks for sharing. Indeed, the fact this breaks on a release that did nothing but bump rubocop has me assuming this is a Rubocop issue.

I think other than raising a hand in that issue (maybe @koic knows something?), I'd recommend as a next step testing Ale with the rubocop release before and after this change. If it works, then maybe the problem is with how Standard is invoking Rubocop's runner

[thewatts]

Thanks for the reply, @searls!

I'd recommend as a next step testing Ale with the rubocop release before and after this change.
Great idea here!

Since standard already installs rubocop - I just changed my ale config to leverage rubocop instead of standard.

Ale worked fine in this regard:

CleanShot.2023-03-06.at.16.53.39.mp4

[searls]

To confirm this is the same issue as #536, I verified ale is invoking standardrb with --stdin (as you'd expect) source

[searls]

Okay, this should be fixed in 1.25.1