Also retrieve file's package when fast-scanning for imports#209
Conversation
bufdev
left a comment
There was a problem hiding this comment.
I might move this to fastscan.Scan or something, but all good for me!
Sounds like a good idea, so I went ahead and did this. |
|
Something about this change broke the integration tests for the new workspaces - I think it is that some imports are no longer getting picked up: https://github.com/bufbuild/buf/commits/bufmod Thats all the info I have right now, but here is where it is called: https://github.com/bufbuild/buf/blob/a7de4fb19a7ea110e8ccecc992eaff4bfbb2d98c/private/bufpkg/bufmodule/module_set.go#L472 and here are the test files: https://github.com/bufbuild/buf/tree/a7de4fb19a7ea110e8ccecc992eaff4bfbb2d98c/private/buf/bufworkspace/testdata/basic https://github.com/bufbuild/buf/blob/a7de4fb19a7ea110e8ccecc992eaff4bfbb2d98c/private/buf/bufworkspace/workspace_test.go |
|
To close the loop on the issue brought up above: this turned out to be an error in the test source code that was being used. The change in this PR that tickled it was that this change made the parsing of imports a little bit more precise, which means it could fail in the face of certain kinds of syntax errors in the source. Fixing the syntax errors in the test source resolved the issue. See #214 for more updates to this package. When these kinds of syntax errors are identified, they will be returned to the caller. That PR also adds some tests, which caught an issue in this package with handling of public and weak imports. |
This augments the experimental fast-scanner
imports.ScanForImportsto also return the package for each scanned file.