Multiple paths for package in manifest release

[patoncrispy]

Is it possible to have multiple paths trigger a release for a package in the release-please-config.json?

I'm using Turborepo, which has apps and packages directories which contain apps and libraries, respectively. I would like it if updates to a specific package triggered a release for an app.

Can this be achieved, currently?

[chingor13]

I'm unfamiliar with Turborepo, but we have a concept of workspace plugins that are meant to trigger dependency version bumps between dependent components in a monorepo. These plugins build a dependency tree of interrelated libraries and if a library is updated, we try and bump the version in any other libraries that depend on that library. You may be interested in the node-workspace plugin if your components all have package.json files

[hspitzley-czi]

@chingor13 I am in need of this feature as well. Are there any workspace plugins that work for Go projects?

[hspitzley-czi]

I was envisioning something like this is the config:

{
  ...
  "packages": {
    "app": {
      "package-name": "app"
      "dependencies": ["shared"]
    },
    "shared": {
      "package-name": "shared"
    }
  },
}

So that if anything in my shared directory changes it would trigger a release of my app with a major/minor/patch bump that matches what type of bump was done on shared

[patoncrispy]

@hspitzley-czi I think that's what the node-workspace plugin is supposed to do. Unfortunately, I haven't had the time to try it out. It's on our backlog though.

[hspitzley-czi]

@hspitzley-czi I think that's what the node-workspace plugin is supposed to do. Unfortunately, I haven't had the time to try it out. It's on our backlog though.

My understanding was that that plugin was specific to nodejs so I was hoping for a language agnostic solution that would allow me to define dependencies in my Go monorepo

[michael-land]

@hspitzley-czi I think that's what the node-workspace plugin is supposed to do. Unfortunately, I haven't had the time to try it out. It's on our backlog though.

I just tried this out, it does not as expected yet.

@app/scheduler and @shopify/worker are apps that depends on @shopify/queue

@shopify/queue is package

when only change files in @shopify/queue, it bumped the version in PR, but not included in the released output

---

[toddbaert]

We make great use of Release-Please in the OpenFeature project. We're interested in implementing something like this... either a generic plugin or an enhancement to the existing manifest-releaser to support "local" dependencies. Something like the "linked version" behavior, but not bidirectional: so if pkg/web has a dependency declared on pkg/shared, and pkg/shared has a major version update, it would result in a major version update in pkg/web. The behavior would be similar to the node-workspace plugin but language agnostic and require a bit more manual configuration in the release config.

@chingor13 does this strike you as a reasonable proposal?

[chingor13]

The behavior would be similar to the node-workspace plugin but language agnostic and require a bit more manual configuration in the release config.

This does seem very similar to what the workspace plugins are doing, but with a different versioning strategy -- where the semver bump type is matched. It might be possible to modify the workspace plugins to accept a versioning strategy configuration where it knows the version type change of the source artifact and it matches that version type change when it bumps the dependee artifact.

A language-independent plugin is hard because it needs to know which files to update, unless you are going to only rely on the configuring generic updaters (Generic, GenericXml, etc.)

[toddbaert]

@chingor13

A language-independent plugin is hard because it needs to know which files to update, unless you are going to only rely on the configuring generic updaters (Generic, GenericXml, etc.)

We rely on the inline comment markers like this ( (which I guess are powered by the generic updaters?). We find these work nicely. We use them heavily for updating documentation, etc, so it's no issue for us.

[kinyoklion]

I would appreciate something like this for managing a monorepo containing a number of C++ projects. Language specific version updates are not of great interest in this case either. Though it does seem like using the extra-files config of the manifest could be used to customize version number information.

A simple way to model that X package incorporates extra code from specific paths, and conventional commits to those paths affect the version number as if they where in the directory of X package would greatly simplify shared code scenarios.

[toddbaert]

@chingor13 Are you in favor of having an implementation for this? I will happily do it if it's something I know isn't a dead-end.

[AlbertHernandez]

Any news related to this? I think it would be super useful to have this feature 🙏