go-library

The go-library is a monorepo of golang packages designed for reusability within CLI and daemon applications.

Adding to go-library

Packages added to go-library should follow these guidelines:

1. The package API is fairly stable.
2. It is already demonstrating reusability within other repositories. a. There is an benefit to the SDLC of both the package and its current location by adding it to go-library
3. The package can be open sourced and meet the LICENSE.

Conventions

A package should be self contained within its own folder off the root of the repository.

If a package grows rapidly or versioning complexity arises due to frequent package changes, you may want to add a go.mod file to make it a separate Go module that is versioned and tagged separately.

Further, as module complexity or test execution time increases, you may also want to consider moving modules to a separate repo as needed.

For example:

pkg1/
    pkg/
    internal/
pkg2/
    cool.go
mod2/
    pkg/
    internal/
    go.mod

Packages may be organized following golang standards. Use a model that best fits the requirements and complexity of the individual package. Below are some guidelines to consider:

• All packages MUST define flat .go files in the package directory with the exported interfaces and functions. Complex packages MAY also have a pkg directory to organize exported sub-packages.
• Packages MAY have an internal directory to organize interfaces and functions not meant for external use
• Packages MUST NOT expose a main function
• Packages MAY have their own go.mod. It may need its own go.mod if
  • The package needs an isolated release cycle
  • The number of dependencies is causing a negative impact for other packages in the monorepo.

Release

The monorepo should be released following semantic versioning and golang standards. e.g. v0.1.0

If a package is a module (contains its own go.mod) it MUST follow an individual release cycle using the module path and version.

For example:

1. mod1/v0.1.0
2. mod2/v0.1.0