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

Avoid panic on new stdlib packages #51

Open
varungandhi-src opened this issue Aug 15, 2023 · 0 comments
Open

Avoid panic on new stdlib packages #51

varungandhi-src opened this issue Aug 15, 2023 · 0 comments
Assignees

Comments

@varungandhi-src
Copy link
Contributor

varungandhi-src commented Aug 15, 2023

At the moment, we have a hard-coded map which is used to check if a package belongs to the Go stdlib or not. When new packages are added, we can end up hitting a panic as in #48

I propose the following design to avoid this problem in the future:

  1. If the Go toolchain (i.e. go command-line tool) is available:
  • If the Go toolchain is 1.21 or older, use a hard-coded map.
  • If the Go toolchain is 1.22 or newer, it is guaranteed that the toolchain version will be higher or equal to the minimal required Go version in go.mod or go.work. See https://tip.golang.org/doc/go1.21 -- Just invoke go list std and use that for checking whether a package is from the stdlib or not.
  1. If the go command-line tool is not available:
  • If the Go version as in go.mod or go.work is 1.21 or older, use the hard-coded map.
  • If it is newer, then have some graceful fallback behavior and log a warning instead of panicking.

Ideally, we'd have a tests here which test the various code paths. The tests could use smaller subfolders with their own tiny go.mod and/or go.work files, or mocking. We should have at least one test which uses files on disk to mimic real-world end-to-end usage.

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

1 participant