2

Suppose I have a Go project which act as shared library in another Go project. How do I markup Go symbols (consts, structs, vars) that they are used outside this project?

I guess the underlying problem is that I have a hard time knowing which code uses said symbols.

Please note: This is not about semantic versioning, of which I am very well aware and which I use. I know Semver can help to identify breaking changes.

Instead, this is about finding out if I actually break one of my own projects (compared to: This symbol should be unexported or used outside the package). I am thinking of some sort of annotation which don't exist in Go.

As an aside, IntelliJ doesn't know either and marks those symbols as "Unnecessarily exported". Maybe an IntelliJ-centric solution could suffice.

To illustrate my problem:

package sharedlib

import "time"

// MyFavoriteTimeFormat is a blablabla...
const MyFavoriteTimeFormat = Time.RFC3339

package dependingproject

import "github.com/thething/sharedlib"
import "time"

func convertToString(timestamp time.Time) string {
    return timestamp.Format(sharedlib.MyFavoriteTimeFormat)
}

When I happily rename MyFavoriteTimeFormate and release it, the code will break in the depending project when it updates the dependency.

Philipp Pixel
  • 118
  • 8

1 Answers1

2

Don't export anything until some other package needs it. If another package needs something, then do export, and then you'll know that if something is exported, it is because it is used outside of the package. And do not do breaking changes on exported identifiers. If you really must, then increment major version. Using go modules, that won't break existing other packages, they will continue to use the old version.

If your module is broken down into multiple packages (because it is "big"), and you wish to export something solely for the other packages of your module, then use the internal package concept, so it will still be "unexported" (unimportable) to other modules. For details, see Can I develop a go package in multiple source directories?

icza
  • 389,944
  • 63
  • 907
  • 827
  • Thanks but this is not what I mean. Maybe I was not clear: The exported symbol is exported for a reason, namely that it is used in another package of the same project. If I happen to increment the major version for everything Exported I will no longer have a meaningful semantic versioning because then everything will be a breaking change. I don't quite get the internal package concept part, though. – Philipp Pixel Feb 19 '20 at 15:13
  • @PhilippPixel Please see edit about internal packages. – icza Feb 19 '20 at 15:13