-
-
Notifications
You must be signed in to change notification settings - Fork 82
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
Ability to configure which warnings to use #208
Comments
even ideally, pass arbitrary buildifier flags would absolutely fit the bill |
Definitely love to have it and be able to disable certain lint errors (for example load on top) |
Some of the warnings are quite egregious and don't need to be seen all the time in normal development, for instance 'print'. Currently, the only way to disable this and still use the Bazel extension is to disable buildifier completely by passing in a fake executable to the Buildifier Executable setting, e.g. /bin/false |
Possibly even better would be to support the |
Unfortunately, this feature is not supported yet #!/usr/bin/bash
/usr/local/bin/buildifier $* --warnings=-module-docstring |
This PR adds the `buildifierConfigJsonPath` setting, which allows a custom path to be set to pull the json configuration file for `buildifier` (this is often `.buildifier.json`). If the `buildifierConfigJsonPath` path is set, when `buildifier` is run within this extension, the `--config <path>` CLI arguments will be passed to `buildifier`. While it could be said that this PR is now adding support for the `.buildifier.json` file -- it's only adding support for the customization of that file path. bazel-contrib#350 actually pulled out yet another drive-by fix (of bazel-contrib#208) by adding the working directory. In that PR, `cwd: vscode.workspace.workspaceFolders?.[0]?.uri?.fsPath` is setting the working directory for the `buildifier` execution local into the workspace. This means any local `.buildifier.json` file will automatically get pulled in and used. This PR is allowing further customization on top of that. The logic of this PR was tested by manually editing the js of my local extension installation with the equivalent changes (that's how I found that `cwd: ...` ended up working with a local `.buildifier.json`).
This PR adds the `buildifierConfigJsonPath` setting, which allows a custom path to be set to pull the json configuration file for `buildifier` (this is often `.buildifier.json`). If the `buildifierConfigJsonPath` path is set, when `buildifier` is run within this extension, the `--config <path>` CLI arguments will be passed to `buildifier`. While it could be said that this PR is now adding support for the `.buildifier.json` file -- it's only adding support for the customization of that file path. bazel-contrib#350 actually pulled out yet another drive-by fix (of bazel-contrib#208) by adding the working directory. In that PR, `cwd: vscode.workspace.workspaceFolders?.[0]?.uri?.fsPath` is setting the working directory for the `buildifier` execution local to be the workspace. This means any local `.buildifier.json` file will automatically get pulled in and used. This PR is allowing further customization on top of that. The logic of this PR was tested by manually editing the js of my local extension installation with the equivalent changes (that's how I found that `cwd: ...` ended up working with a local `.buildifier.json`).
This PR adds the `buildifierConfigJsonPath` setting, which allows a custom path to be set to pull the json configuration file for `buildifier` (this is often `.buildifier.json`). If the `buildifierConfigJsonPath` path is set, when `buildifier` is run within this extension, the `--config <path>` CLI arguments will be passed to `buildifier`. While it could be said that this PR is now adding support for the `.buildifier.json` file -- it's only adding support for the customization of that file path. bazel-contrib#350 actually pulled out yet another drive-by fix (of bazel-contrib#208) by adding the working directory. In that PR, `cwd: vscode.workspace.workspaceFolders?.[0]?.uri?.fsPath` is setting the working directory for the `buildifier` execution to be the local workspace. This means any local `.buildifier.json` file will automatically get pulled in and used. This PR is allowing further customization on top of that. The logic of this PR was tested by manually editing the js of my local extension installation with the equivalent changes (that's how I found that `cwd: ...` ended up working with a local `.buildifier.json`).
This PR adds the `buildifierConfigJsonPath` setting, which allows a custom path to be set to pull the json configuration file for `buildifier` (this is often `.buildifier.json`). If the `buildifierConfigJsonPath` path is set, when `buildifier` is run within this extension, the `--config <path>` CLI arguments will be passed to `buildifier`. While it could be said that this PR is now adding support for the `.buildifier.json` file -- it's only adding support for the customization of that file path. #350 actually pulled out yet another drive-by fix (of #208) by adding the working directory. In that PR, `cwd: vscode.workspace.workspaceFolders?.[0]?.uri?.fsPath` is setting the working directory for the `buildifier` execution to be the local workspace. This means any local `.buildifier.json` file will automatically get pulled in and used. This PR is allowing further customization on top of that. The logic of this PR was tested by manually editing the js of my local extension installation with the equivalent changes (that's how I found that `cwd: ...` ended up working with a local `.buildifier.json`). --------- Co-authored-by: Cameron Martin <cameronmartin123@gmail.com>
It would be great if the extension allowed configuration for which buildifier warnings to use (matching the
--warnings
flag to buildifier).The text was updated successfully, but these errors were encountered: