Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support reading from stdin #155

Open
ThanePatrol opened this issue Aug 14, 2024 · 4 comments
Open

Feature Request: Support reading from stdin #155

ThanePatrol opened this issue Aug 14, 2024 · 4 comments

Comments

@ThanePatrol
Copy link

Support a flag to allow reading from stdin then applying fixes and output to sysout.
Sometimes I'm not concerned about the messages from wsl and just want it to pass automated MR checks at work 😅

@bombsimon
Copy link
Owner

Thanks for the issue!

I don't see how this would be possible. wsl, like many other static analysis tools, are built on top of the analysis package. This package handles everything related to finding and reading files and does the analysis on package level.

If you have any idea how to approach this please let me know!

Also if you wan't to elaborate on how you use this tool feel free to do so. I'm not sure I follow what problem reading from stdin and outputting to stdout fixes. Is it the non zero exit code from the linter? Or is it the output of the disgnostics even though they're fixed? In what scenario is your code coming from stdin and how is it used in stdout?

@ThanePatrol
Copy link
Author

Thanks for the explanation!
I can see why this would be difficult given the design.

At work we use it in pipelines to indicate formatting issues and make the codebase more homogeneous. Currently it can create a lot of work as old code never used formatting/linters. Running it on an entire module would create a large PR. It would be preferable to slowly update file by file with new formatting guidelines.
Re. stdin I find it works better for editing a buffer of text in an editor than waiting for a file lock.

@bombsimon
Copy link
Owner

Gotcha!

Yeah I don't have much for the fix or workflow, as far as I know this is not doable with the analysis package. This isn't even close to using stdin/out and would likely be even worse for your buffer but the best quick workaround would be to run this outside your editor and thus sadly not on save if you want to fix a single file for CI purposes.

function wsl_one {
  if [ -z "${1:-}" ]; then
      return
  fi

  if ! git stash save | grep "No local changes to save" > /dev/null; then
    should_pop=1
  fi

  file="$1"
  package_of_file=$(dirname "$file")
  wsl --fix "$package_of_file" > /dev/null 2>&1
  git add "$file"
  git checkout -- "$package_of_file"

  if [ -n "$should_pop" ]; then
    git stash pop
  fi
}

It would work something like this:

# Two Go files in the package
› ls *.go
a.go  b.go

# Both have wsl violations
› wsl .
/home/simon/tmp/x/a.go:5:11: block should not start with a whitespace
/home/simon/tmp/x/b.go:5:11: block should not start with a whitespace

# We use alias to save potential state and re-format just `a.go`
› wsl_one a.go

# We now only have diff on `a.go` - `b.go` is untouched
› git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   a.go

If you know any other linter that formats a single file like you want I can have a look. Sadly I've seen similar asks many times in repos like golangci-lint where the same situation applies; linting is done on package level and the tool is not designed to be ran on a single file.

@ThanePatrol
Copy link
Author

Thanks for the script! Definitely useful for this purpose! Could probably just add this to our makefile.
Gofumpt has the option to read a single file from stdin. It doesn't seem to use the analysis package.
Without any knowledge on the subject I would guess the analysis is not as complex compared to wsl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants