Go Monorepo / module dependency handling

[malins]

Hello,

I have a monorepo with "deployable" modules and library modules. Since I have no external users of my library modules, I'm not making releases for them. I'm using replace(...) in my go.mod's to depend on the latest version of library modules. I think that's a good approach to reduce complexity in my build process, and generally you do not release everything in a monorepo.

However, when making changing to a library module, I need to make releases of all "deployable" modules depending on those changed libraries.

The easiest solution for my problem would be to define a path in the configuration file, and changes within this path trigger releases of all defined modules.

Second option would be to make it possible to configure multiple path for each monorepo project, and all of them are inspected for changes.

Third option would be to introduce a hook for such "advanced" scenarios where you can plug-in custom logic to determine whether release should be forced or not.

I would be willing to implement this, but I don't want to fork (if possible), so which variant would you prefer?

Thank you,
Manuel

[s0ders]

Hey,

First of all, thanks for considering using this project, I'm glad that it might suit your needs.

As for your issue, I believe the most simple solution would be to map the various library path to your deployable module in such as:

monorepo:
  - name: deployable-A
    path: 
       - ./deployable-/A
       - ./library-A/
       - ./library-B/
       # And so on

Doing so would require a refactor of the configuration in such a way that a monorepo configuration could support various path which sounds like a doable refactor. Let me know if this would work for you.

Any way, I think I'll go ahead and implement support for multiple path for a single monorepo since this sounds like a not-so-rare use case.

Regarding your proposals:

• First option and second option: sounds like what I'm proposing, and I'm ok with this. Pros: easy to implement, cons: might have a verbose configuration file.
• Third option: hooks might sound like a good idea but then again I'm not sure it would fit the UNIX philosophy I'm trying to achieve with this program. If you want to hook this program to an other tool, I'd suggest piping the JSON output so a tool such as jq and then do some bash scripting.

[malins]

Hello,

may I propose a more backward-compatible configuration for this use case:

monorepo:
  - name: service-a
    path: /services/a
    depends-on: [library-x, library-y]
  - name: service-b
    path: /services/b
    depends-on: [library-y]
  - name: library-x
    path: /libs/x
    release: no
  - name: library-y
    path: /libs/y
    release: no

Still one path per "module" and a more structured definition of inter-module dependencies. This way you could even model libraries depending on other libraries, and correctly propagate commits up.

Kind regards,
Manuel

[s0ders]

I understand the need for some modules to be released if their dependencies are upgraded though I wouldn't want to bloat the configuration file with too many keywords.

The depends-on instruction makes it clear that the paths given are not part of actual module but rather dependencies yet I am not sure whether this would apply to various languages (for context, I mostly develop in Go and I don't know if other languages dependencies system offers such as thing as the replace instruction on which your build process depends).

I am not strongly opposed to this new keyword since, as stated above, it's clearer than adding various dependencies paths in a "paths" instruction in the configuration file.

As for the release: no/yes parameter, I don't understand why, even if your library has no external clients, you wouldn't want it versioned even though you are always using the latest version?