Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Go: Support workspaces #6012

Open
1 task done
johanneswuerbach opened this issue Nov 1, 2022 · 5 comments
Open
1 task done

Go: Support workspaces #6012

johanneswuerbach opened this issue Nov 1, 2022 · 5 comments
Labels
F: monorepo 📦 Issues related to bumping a dep in manifests from multiple apps Keep Exempt this from being marked by stalebot L: go:modules Golang modules T: feature-request Requests for new features

Comments

@johanneswuerbach
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Feature description

Golang 1.18 introduced the support for workspaces to simplify the management of multiple modules in one repository.

Dependabot could use the go.work file to:

  • automatically discover all referenced sub-modules
  • bump dependencies consistently across them

Something similar is already supported in the JS world with lerna #197 and yarn.

@jeffwidman
Copy link
Member

Can you clarify the scenarios where this would be useful?

I typically refrain from checking a go.work file into git, and most other gophers I know do the same. There's even an issue discussing whether to formalize that recommendation:

If it's not actually checked into VCS, then Dependabot won't be able to bump it...

@johanneswuerbach
Copy link
Author

We have several repositories, which contain multiple modules, were we commit go.work files so editor code completion etc. just works.

In those cases dependabot should auto-discover all modules based on the go.work file and ideally also keep dependency versions in-sync.

@Drache93
Copy link

Like the original issue mentioned, Lerna and Yarn already do this for JS. As discussed in that Go proposal @jeffwidman mentioned, the use case where go.work is checked in, is monorepos (not to duplicate that discussion here). In my case, we have multiple applications and their shared libraries in a monorepo.

@jeffwidman jeffwidman added the F: monorepo 📦 Issues related to bumping a dep in manifests from multiple apps label Mar 1, 2023
@lucacome
Copy link

lucacome commented Apr 7, 2023

I'm interested in this as well. Any plans to implement it?

@grzesuav
Copy link

Actually it would be super useful to have it also running go work sync to update all references. Regarding go.work being committed to VCS - this is one way how it implement monorepo in golang

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: monorepo 📦 Issues related to bumping a dep in manifests from multiple apps Keep Exempt this from being marked by stalebot L: go:modules Golang modules T: feature-request Requests for new features
Projects
None yet
Development

No branches or pull requests

6 participants