Hacker News Reader

Comment by harikb | Hacker News Reader

It would be great if go.mod file’s replace directive also supported a replace that applies to all downstream users (url to url , not just url to local path) This would allow us to maintain simple forks (ones where you are only fixing a few lines and awaiting PR approval to upstream) but still don’t want to wait for the whole cycle to finish for your own internal company dependencies. I feel this is better than changing all imports.

If you are truly forking with no intention to merge back, isn’t the manual find-and-replace by IDE just fine?

View on HN

The replace directive does allow you to use a different import path, not just a local path. Unless there's something I'm missing about your use case?

https://golang.org/ref/mod#go-mod-file-replace

It's important to note that it still doesn't apply to downstream users (those adding your package to their go.mod), only to those building your package directly. I think this decision makes sense, so this is not a complaint.

Can you elaborate? We use `replace` everywhere in our codebase for modules that we've forked + modified.

Assume module A depends on module B, and module B has a dependency on module github.com/C, and a replace rule for github.com/C => company.internal/C.

When you build module A, it will pull module B and module github.com/C, instead of B and company.internal/C, unless A has its own replace directive for C.

Oh I never knew! Thanks. That does simplify a lot

The problem I had was that I was forking a monorepo package, so I had to update its internal dependencies to point to the new place. It's possible I missed something, but I don't think I was able to do this with go.mod.

And yes, manually doing the rename "is fine", but I don't think that has any reason to be stated in a discussion about a refactoring tool.

> I don't think that has any reason to be stated in a discussion about a refactoring tool.

Find and replace is the baseline, and for many refactorings is insufficient and fragile, however in replacing a stable, unique, and isomorphic token it is basically as good as it gets, so I think it is relevant. Its probably the least useful thing a refactoring tool could do.

I am not sure. You want to make sure that you are only modifying import statements and those can’t necessarily be identified from just a single line (else you might change an errant URL in a string literal), and you also need to move the files themselves, and update the package line in the files. So sure, you can do it yourself, but why are we building a refactoring tool at all?

Not to mention if the package name itself changes...

Reply on news.ycombinator.com