-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
How to avoid shadowing builtins? #164
Comments
A few solutions to your problem:
This is not exactly a golang-standards issue, since if you call your package (*) Note that this is not the same as relative or "dot" imports. The relative/dot imports are bad, don't use them. This is just a convention adopted by most Go tools to resolve the packages. |
While attempting to follow this layout new to Go, I created a file named
cmd/api/main.go
.This lead to some quite unexpected behavior:
go build -a -v cmd/api/
produced a working binary that did nothing (and ignored my main method). I got the expected result by changing the build command to reference either of./cmd/api
orcmd/api/main.go
After doing some digging, it was suggested that I had accidentally referenced a (quasi-hidden?) standard package with a similar name: https://pkg.go.dev/cmd/api Hence, I was getting a "binary" that successfully built, but not for my code.
I hadn't expected that the standard project layout would choose a folder (
cmd
) that might allow collisions with stdlib/ existing packages. Perhaps this guide could be extended with advice on how to avoid (or detect) when this is happening?(I recognize that it's hard to be future proof, but this bit me in real usage on Day 1, while experimenting with Go on a boilerplate project with a friend)
The text was updated successfully, but these errors were encountered: