Ytukyg

I understand Go Modules are yet an experimental opt-in feature, and perhaps because of that, I cannot find clear guidance on how to name directories and packages.

In these Package names in Go Blog post and Package name in Effective Go, they talk about that the directory should match the package name - but I wasn't certain if Go Modules would follow the same pattern.

If I want to bundle my business logic in package business with many files, is it reasonable to create subdirectory validators/ and keep the same package name package business?

someDir

├── business

│   ├── businessA.go // package business

│   ├── businessB.go // package business

│   ├── businessC.go // package business

│   ├── go.mod      // module example.com/business

│   └── validators

│       ├── businessValidatorX.go // package business, or validators?

│       ├── businessValidatorY.go // package business, or validators?

│       └── businessValidatorZ.go // package business, or validators?

└── main.go

Approach 1.

If I were to go with the same package name:

// main.go

package main



import (

        "example.com/business"

        "example.com/business/validators"

)



// both imports would be combined to the same `business` package?

func main() {

        b := business.SomeLogic()

        business.ValidateX(b) // validator from the same package

}

This looks to be prone to export conflict - but it is simple.

Approach 2.

If the validators/ path maps to package validators, the consuming code would look like the below instead.

// main.go

package main



import (

        "example.com/business"

        "example.com/business/validators"

)



func main() {

        b := business.SomeLogic()

        validators.ValidateX(b) // validator from a separate package

}

How should I manage a package consisted of many files? Is the Approach 1. reasonable, although it somewhat contradicts from the blog post and doc above?

Or should I go with Approach 2., complying with the convention, and add an alias as necessary in main.go?

Approach 2 is correct.

Being a Go newbie, I had mistakenly thought that Approach 1 was one possible way, as Go does allow having package name different from directory name.

As Volker helped in the comments, Approach 1 is definitely not possible.

You will get a straight compilation error when trying to combine packages.

The introduction of Go Modules does not affect the best practices outlined in existing documents, such as:

• How to Write Go Code


• Effective Go

As a side note, I also came to know that package name should be singular form.

• Style guideline for Go packages

So that would leave me with the following structure along with Approach 2: