nicklockwood / SwiftFormat

A command-line tool and Xcode Extension for formatting Swift code
MIT License
7.63k stars 623 forks source link

--lint can no longer simply return an error code #1690

Closed jshier closed 1 month ago

jshier commented 2 months ago

For a few months I'd run a swiftformat linting as part of my build to see whether I needed to manually format code (in order to avoid Xcode issues I don't format during build). Worked great until --lint was changed to return error output that was visible in Xcode and broken the build. I added --lenient, but then linting doesn't fail at all. Is there some sort of middle ground to make the script work again?

if ! git --no-pager diff --name-only --line-prefix="${PWD}/" --diff-filter=ACMR --line-prefix="${PWD}/" -z origin | grep -z ".*\.swift$" | xargs -0 ${PODS_ROOT}/SwiftFormat/CommandLineTool/swiftformat --lint --quiet --lenient; then
  echo "warning: Changes need formatting, please run fastlane format."
fi

Removing lenient from the command makes the errors show up in Xcode. I only want the failure code.

jshier commented 2 months ago

Redirecting the error output with 2>/dev/null allows me to use --lint without producing errors in Xcode, but it would be nice if there was a way to do that natively.

nicklockwood commented 2 months ago

@jshier hmm, this isn't a use-case I'd considered. You could grep the stderr output from the lint command to see if it contained any warnings I suppose?

nicklockwood commented 2 months ago

@jshier btw, do you also use SwiftLint as part of your workflow? Does it handle this differently?

jshier commented 2 months ago

Yes, we run SwiftLint, but just as a linter. It can directly take in the changed files and produce the output we want, sort of the opposite of SwiftFormat.

I can redirect the error output to /dev/null (apparently Xcode interprets any error output from scripts as a build failure), like I said, and the script works fine, but it does seem strange that --lenient even exists, as it seems to negate --lint entirely. swiftformat --lint --lenient will always succeed, no?

For my script to work I just need the error code output.

nicklockwood commented 2 months ago

it does seem strange that --lenient even exists, as it seems to negate --lint entirely.

The intention of --lenient is to show warnings in Xcode without failing the build.

jshier commented 2 months ago

Huh, we never saw those. How are the warnings output? Does --quiet filter them? In any case, for my usage I just need to know if there would be any changes after formatting, we don't want them inline in Xcode.

nicklockwood commented 1 month ago

How are the warnings output?

They're just printed to stderr, but if you run SwiftFormat as a build phase script then they show up in the editor itself as warnings - same as for SwiftLint.

Did you manage to find a solution that works for you with the latest SwiftFormat changes? I'm loathe to revert this change because I consider it a correction to the previous wrong behaviour, but I also don't want to break your workflow.

jshier commented 1 month ago

Just redirecting the error output, which works fine.

nicklockwood commented 1 month ago

@jshier --lint --quiet should now work as before in 0.53.9