tools: reduce the number of 3rd party tools the extension requires

[hyangah]

VS Code Go uses gopls for most of the language features, but there are a few features that still require 3rd party tools. We propose to migrate those features to gopls, reduce dependency on third party tools further, and improve security, reliability, usability and maintainability of the plugin.

This is a uber-issue to keep track of the progress and track glue work. Contribution/help is welcome!

Recently @marwan-at-work replaced use of gopkgs for the go.import.add command with custom commands implemented inside gopls. See the followings as inspiration:

• gopls: custom command implementation
• vscode-go: switching between gopls & gopkgs

https://github.com/golang/vscode-go/blob/master/src/goToolsInformation.ts has the full list of tools that can be used by the plugin.

• gopkgs: tools: replace use of 'gopkgs' with 'go list all'  #258

  • Function: implements go.browse.packages
  • gopkgs is used to retrieve all known packages and create a QuickPick list, from which the user can select a package to browse.
    • gopkgs -format '{{.Name}};{{.ImportPath}};{{.Dir}}'
  • Proposal: use gopls's gopls.list_known_packages

• go-outline: tools: replace go-outline with gopls #1020

  • Function: implements GoDocumentSymbolProvider used by the followings
    • References codelens (used to place the codelens to each function) - this can be replaced with gopls's DocumentSymbol
    • go.generate.tests (used to find the current function name at cursor) - this can be replaced with gopls's DocummentSymbol
    • Run Test / Debug Test codelens (getTestFunctions, getBenchmarkFunctions, getCodeLensForPackage)
      • Codelenses for standard tests can be replaced with gopls
      • Handling 3rd-party test framework needs gopls’s document symbol + list of imports (go list)
    • Proposal:
      • Step 1: Replace GoDocumentSymbolProvider implementation with a modified gopls documentSymbol, by amending the list of imports, and leave all the code untouched until gopls implements all the code lenses and go.generate.tests natively (x/tools/gopls: supply imported package names in documentSymbol results go#40514 (comment))
      • Step 2: Implement codelens and go.generate.tests from gopls natively and get rid of GoDocumentSymbolProvider.
    • Note: minimize conflicts with the outstanding TestAPI work.

• guru: x/tools/gopls: add codelens to show number of references to each symbol go#40862

  • Function: implements References codelens
  • Proposal: implement reference code lens from gopls
  • NOTE: we are removing the current guru-based feature in Remove the broken references codelens #2509

• gomodifytags: tools: merge gomodifytags functionality into gopls and use gopls #2002

  • Function: modify tags on structs (go.add.tags, go.remove.tags commands)
  • Proposal:
    • Option 1: do nothing and keep using fatih’s gomodifytags.
    • Option 2: implement from gopls
      - check if there is any reusable code if gomodifytags is refactored and discuss with fatih if so

• goplay

  • Function: publish the code in the current editor to the Go playground (go.playground command)
  • Proposal: implement from the extension or gopls. We can also consider adding the playground’s new go.mod file support.

• impl: x/tools/gopls: generate method stubs for a given interface go#37537

  • Function: generate stubs for interfaces. (go.impl.cursor command)
  • Actual Implementation: alternative implemented using code action
    *Proposal: implement from gopls - two new commands
    • gopls.list_known_interfaces
      • Similar to workspace symbol, but returns only interfaces (see Add Package/Interface Dropdowns to Generate Interface Stubs Command #1547 (comment)).
        • Q: ranking based on locality?
    • gopls.generate_interface_stubs
      • Input: current cursor, document URI, interface name, optional receiver type name
      • Output: text edit (snippet)

• gotests: tools: migrate test generation features to gopls #1594

  • Function: Generate unit tests (go.test.generate.package, go.test.generate.file, go.test.generate.function commands)
  • Proposal:
    • Implement from gopls (note: gopls can import the gotests package)
    • gopls.generate_tests
      • Input: package directory, optional function name, …
      • Output: text edit
  • Note: make sure to handle go.generateTestsFlags and env vars (GOTEST_TEMPLATE_DIR, GOTEST_TEMPLATE)

---

• Refactor/standardize the logic that determines whether gopls is active and gopls implements the feature.
• Update isImportant, replacedByGopls info in the tools list

[gopherbot]

Change https://go.dev/cl/538762 mentions this issue: src/goToolsInformation: delete legacy tools

[hyangah]

cc @h9jiang

[findleyr]

@h9jiang what remains on the gotests replacement? Is this now done? Thanks.

[h9jiang]

We still offer the user to trigger gotest through command panel. We need to collect feedback of the code action and eventually deprecate the gotest binary.

As suggested, maybe we can integrate telemetry in vscode-go extension to understand the usage of gotest

[findleyr]

CC @madelinekalil, who has been working on struct tags recently and could pick up migrating gomodifytags feature set to gopls.

@h9jiang I think your ideas for instrumenting telemetry are very much worthwhile.