You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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:
go
command-line tool) is available:go.mod
orgo.work
. See https://tip.golang.org/doc/go1.21 -- Just invokego list std
and use that for checking whether a package is from the stdlib or not.go
command-line tool is not available:go.mod
orgo.work
is 1.21 or older, use the hard-coded map.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/orgo.work
files, or mocking. We should have at least one test which uses files on disk to mimic real-world end-to-end usage.The text was updated successfully, but these errors were encountered: