-
Notifications
You must be signed in to change notification settings - Fork 645
Run on-save tools for entire workspace #1023
Conversation
@vapourismo, |
We do need a flag to control current package vs whole workspace. In #830 we talked about a setting
With this, people who have set In the code, we can continue to honor either of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add the setting to control package vs workspace
Which value should you set, if you want it to be disabled? |
How about |
Okay, I added these options as
|
Nevermind, it is just the |
src/goCheck.ts
Outdated
|
||
if (buildWorkspace) { | ||
buildWorkDir = vscode.workspace.rootPath; | ||
args.push('./...'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the current file that is open is a test file, this will end up running go test -i ./...
which will run the tests in the workspace instead of trying to compile them
For compiling test files, we need to use go test -c
and -c
cannot be used on multi-package.
@rakyll @campoy @mattetti Do you know of a way to compile test files under a directory?
How about this? Original behavior with |
src/goCheck.ts
Outdated
* This ignores hidden directories and their sub-directories. | ||
* @param dirPath Directory in which to start searching | ||
*/ | ||
function findTestDirectories(dirPath: string): string[] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the work here. Consider this
- User with a very large workspace with deeply nested directories
- User with auto-save on
The directories check here is synchronous.
We later wait for all promises (build, lint, vet) to finish before showing diagnostics to the user.
So you can imagine for each save, this might delay results more than needed.
Note: We have #1015 tracking to find a way to optimize this.
Also, I'd much rather prefer a better way to compile test files from Go itself.
Until then, we can skip trying to compile the test files in the whole workspace.
if (buildOnSave is not 'off') {
if (buildWorkspace)
`go build -i -o ./...`
if (current file is test file)
`go test -i -c -o <import path>`
else if (!buildWorkspace)
`go build -i -o <import-path>`
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had the exact same thought, but I've come to the conclusion that it doesn't matter. If you set it to build the entire workspace, you should expect that to happen. In case somebody uses a big workspace, they can set it to build only the current package in the workspace-local settings.
Additionally, even though the directory traversal uses synchronous functions, it is way faster than the lint/vet/etc jobs. It appears that the extension accumulates the results of all "check"-Promises anyway, so delaying some for a couple milliseconds doesn't really hurt.
I understand and agree that this is not a particularly smart solution, but it should work for most use cases.
Also, I'd much rather prefer a better way to compile test files from Go itself.
Not sure, if that is going to happen. The only smart alternative is to run go test -run ! ./...
, which will check the test files, but won't run any since they don't match the pattern. Could you work with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
go test -run ! ./...
Lets give this a try. I was initially not in favor of this as the output is different (lots of "no test files" followed by a "build failed" on the pkg which has error) and we will have to write a different regex to do the problem matching.
But taking a closer look, there is also a line in there which matches our expectation and our current regex should work.
Interestingly, it also checks packages that do not contain tests. So theoretically |
Sets the current working directory to the workspace root when linting and vetting. Also appends the './...' argument which causes the tools to traverse the workspace recursively. Other tools are not affected. Additionally, this will utilize 'go vet' instead of 'go tool vet'.
Sets working directory for 'go build' command to workspace root. Also adds './...', so the entire workspace is traversed.
This modifies settings 'buildOnSave', 'lintOnSave' and 'vetOnSave'. The new options are 'workspace', 'package' or 'off' which will cause the respective on-save tools to run in the determined scope. Old values will still work as they did before.
'buildOnSave' compiles the test for the current package if the saved file is a test unit, no matter if it is set to 'workspace' or 'package'.
If 'buildOnSave' is set to 'workspace', the check function will traverse the workspace in order to find sub-packages that can be tested and subsequently compiles those tests.
Utilize 'go test' to check all tests in the workspace without actually running them.
Utilize 'go test -run=^$ ./...' when building entire workspace, 'go build' for current package and 'go test -c' for the current package when the current file is a test file.
Latest commit prevents duplicates. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the work!
Changes the default behavior from running lint/vet/build for the package of the current active file to running it for the entire workspace.
Potential downside is not having a flag which allows the behavior to be changed between
current package
andworkspace
(as with #830). Something for the future.