Module versioning on local folder

[Reyhan Sofian Haqqi]

Hi,

I have a case where we developing inside a monorepo project where we distribute shared libs locally (without publishing) and we're using replace directive inside go.mod. What we fear is someone changes the shared libs logic, it might break other applications that use it because we can't have any version inside the shared libs module and the applications didn't aware of any changes inside the shared libs module. Is there any way to add versioning for this shared libs module? Is it work using pseudo-version?

For example, we have a module with pseudo-version v0.0.0-00010101000000-55b989e89570. And then Application A requires this module. If someone changes the shared libs logic and the pseudo-version changed to v0.0.0-00010101000000-c00dbbc9dadf. What will happen to Application A which uses module with pseudo-version v0.0.0-00010101000000-55b989e89570? Is it using the code from first pseudo-version or is it always using the latest code regardless of the pseudo-version?

Thanks!

[Shulhan]

> On 6 May 2020, at 11.11, Reyhan Sofian Haqqi <compute...@gmail.com> wrote:
>
> Hi,
>
> I have a case where we developing inside a monorepo project where we distribute shared libs locally (without publishing) and we're using replace directive inside go.mod. What we fear is someone changes the shared libs logic, it might break other applications that use it because we can't have any version inside the shared libs module and the applications didn't aware of any changes inside the shared libs module. Is there any way to add versioning for this shared libs module? Is it work using pseudo-version?

You can use the usual semver on shared libs, and yes it should work with pseudo-version too, as long as you use VCS to publish the changes,

The question is why you can't have any version inside the shared libs? How do you shared the libs locally?

>
> For example, we have a module with pseudo-version v0.0.0-00010101000000-55b989e89570. And then Application A requires this module. If someone changes the shared libs logic and the pseudo-version changed to v0.0.0-00010101000000-c00dbbc9dadf. What will happen to Application A which uses module with pseudo-version v0.0.0-00010101000000-55b989e89570? Is it using the code from first pseudo-version or is it always using the latest code regardless of the pseudo-version?
>

If the replace directive use local path then I am afraid it will use the latest pseudo version.

[Reyhan Sofian Haqqi]

The question is why you can't have any version inside the shared libs? How do you shared the libs locally? 

Because we use monorepo. Maybe git tag works since it's also pointing to a commit hash? but does it works if we use `replace` directive on go.mod file?

If the replace directive use local path then I am afraid it will use the latest pseudo version.

Yes. This what we use for now. Do you have any suggestions about this?

[Shulhan]

> On 8 May 2020, at 14.26, Reyhan Sofian Haqqi <compute...@gmail.com> wrote:
>
> The question is why you can't have any version inside the shared libs? How do you shared the libs locally?
>
> Because we use monorepo. Maybe git tag works since it's also pointing to a commit hash? but does it works if we use `replace` directive on go.mod file?

IMO, you should use replace directive only for VCS to VCS. For example, if you have a fork of module X, and you want to use your fork instead of upstream you can set in go.mod with,

replace remote/upstream/X => my/fork/X

Setting the right hand side of "replace" directive to filesystem path will make the go tools to use the code in that directory without version. See the wiki page on Modules for more information [1].

>
> If the replace directive use local path then I am afraid it will use the latest pseudo version.
>
> Yes. This what we use for now. Do you have any suggestions about this?
>

Treat your shared library as module or in another terms, as a normal project, commit, push changes, or add versioning into it.

Here is the steps that I usually do,

* Doing development on main module, uncomment the replace directive _only_ if you need to make some changes on your local shared lib.

replace your/share/lib => ../lib

* After the changes, and the test has passed, comment the replace directive back.

// replace your/share/lib => ../lib

* Commit the changes in your shared library and push it to the remote repository

* Back to main module, run

$ go get your/share/lib
$ go mod tidy

* You should get the latest pseudo-version. Commit it and push to remote repository.

In this way, all others developers will get and use the same version of shared lib. One of common mistake is to forgot to comment the "replace" directive back.

[1] https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive

[Reyhan Sofian Haqqi]

Thanks for your advice! I will try your suggestion right away. I found that your approach some kind of similar to https://github.com/rogpeppe/gohack. But it seems we can't use that library since we have our internal tool to handle the importing of our shared libs. Thanks!