|
|
|
|
|
by cube2222
1682 days ago
|
|
> (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward) If I understand your point correctly, then that's a non-issue since modules are here. In the go.mod file you have the current module name, and all imports of yourself will use the current repository, instead of calling the original. So you fork the repository, but keep the original name in the go.mod file, then you don't have to modify any imports. |
|
https://golang.org/doc/modules/managing-dependencies#unpubli...
I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/)