Support project level separation for monorepos

[miniscruff]

I was actually going to start using a monorepo for a side project so I am considering how it would work in changie and how you might want to export or control the generated changelog. After reading your comment and thinking a little I actually think this would be a good feature, just need to find out how.

( I have rewritten the below content at least three times now... so don't take it too seriously yet )

My current thought process is a new config called something like "projects", name not set in stone of course. Your configuration would look something like:

projects:
# label is the label used in prompts for our selection, defaults to key if none specified
- label: UI
  # key is used for file paths and version outputs
  key: ui
  # the changelog value here overrides the global value on a per project basis
  changelog: ui/CHANGELOG.md
- label: Email Sender
  key: email_sender
  changelog: services/email/CHANGELOG.md
projectsVersionSeparator: "/"

This configuration gives us the ability to create a changelog like stellar a fairly large monorepo with split changelogs. Internally the unreleased changes remain in the changes directory and release notes can also live there under the key per project. Like so

your_app/
├─ .changes/
│  ├─ unreleased/
│  │  ├─ whatever.yaml
│  ├─ email_sender/
│  │  ├─ v0.1.0.md
│  │  ├─ v0.2.0.md
│  ├─ ui/
│  │  ├─ v0.1.0.md

This would affect a few commands like you already mentioned with latest.

# new will stay the same and the first prompt will be the project
changie new
# but you can also include the project like with other values
changie new --project ui
# batch requires you to provide the project you are batching for
changie batch auto --project ui
changie batch auto # fails if projects are enabled, maybe in the future we can figure it out
# merge one project at a time
changie merge --project ui
# merging all projects is probably a safe action as well
changie merge
# latest and next both require a project
changie latest --project ui
changie next --project ui

The output of latest and next would be the following formula:
project key + project_version_separator + latest/next version
For example given the configuration above and versions in the example above the outputs would be:

$ changie latest --project email_sender
email_sender/v0.2.0
$ changie next patch --project ui
ui/v0.1.1

Let me know your thoughts or if you have any questions on the design.

Originally posted by @miniscruff in #502 (reply in thread)

Another comment from discussion.

I think it would be best to develop and release this feature in a preview mode until any issues can be worked out, I have not done that for Changie before as all new features have always required a config change anyway. I do want to make sure the config changes and flow work well and feel good which I will have a hard time testing myself.

A base idea I have for that is simply displaying a warning prompt when using changie new and changie batch if projects are configured that they are in "preview mode" and mention that in the release notes until it is stable and good to go.

Other then that, its just a timing thing to get the work done.

[sheldonhull]

The feature of using a seperator that’s configurable is key. Great catch. Go in a monorepo can be problematic with slashes if uses go install. In all other cases I use prefixes with a slash.

I’m excited to see this in action. As this solves a lot of versioning challenges with monorepos. Keep up the great work 🎉

[miniscruff]

If any projects are open to letting me use it as a preview project where I can create a PR with the new config and expected outputs let me know.

[sheldonhull]

I’m more than willing to try it out on some local stuff from your branch in some of my projects if you make it go installable (ie no slashes in branch name) I don’t have any public but I can provide active feedback in experience.

…

On Mon, Jul 31, 2023 at 9:25 PM Ronnie ***@***.***> wrote: If any projects are open to letting me use it as a preview project where I can create a PR with the new config and expected outputs let me know.

[sheldonhull]

Bump. I have some multi project repos I could start using internally with and see how it goes. Just make sure to mention me in the response so I see your update. Cheers

[miniscruff]

To anyone watching this issue, I am starting work on this soon now might take a few days before it is ready though.

[sheldonhull]

@miniscruff something to consider... if it's possible to ensure a different project can use a different output template. For instance, I have one project that needs to output to a certain markdown format, so I adjust the body output for this. The others I use my main.

Might be out of scope, but thought I'd mention since different projects might be nice to have my template/body be set. Don't let this hold it up though, if it's not really straight forward.

[miniscruff]

@miniscruff something to consider... if it's possible to ensure a different project can use a different output template. For instance, I have one project that needs to output to a certain markdown format, so I adjust the body output for this. The others I use my main.

Might be out of scope, but thought I'd mention since different projects might be nice to have my template/body be set. Don't let this hold it up though, if it's not really straight forward.

For now this is out of scope. The last time I tried getting that level of detail in the config it got very deep and very bloated in my opinion. Maybe something for a much bigger config change but it may just be out of scope entirely.

[TheSpyder]

This update was incredible and greatly simplified our switch to changie in TinyMCE 👍

tinymce/tinymce#9043

Merge all projects would be really nice to have, but the list of projects doesn't change so we can just script that up ourselves.

[miniscruff]

Merge all projects would be really nice to have, but the list of projects doesn't change so we can just script that up ourselves.

Do you think it would be ok to set the default behavior to merge all when using projects or do you think there should be a --all or similar argument? I feel like it would be ok to merge all by default and just remove the project option entirely. For any project without changes it would do nothing anyway. But I'm curious to know your thoughts.

[TheSpyder]

I haven't used changie in real development yet so it's hard to know for sure. I am happy to give you my opinions though.

I think merge all should be the default. That makes total sense to me.

I think the --project option is still useful even once merge all is available. Specifically, in our case one project (modules/tinymce) is the product, and every other project in the repo is a library that is published separately to NPM. Sometimes we need to publish pre-release library versions for use in other repos before the product release is ready.

Once the branch is merged our entire team of >10 developers will be using this, so I'll very quickly have solid feedback if there are any problems or concerns 😂

[miniscruff]

I haven't used changie in real development yet so it's hard to know for sure. I am happy to give you my opinions though.

I think merge all should be the default. That makes total sense to me.

I think the --project option is still useful even once merge all is available. Specifically, in our case one project (modules/tinymce) is the product, and every other project in the repo is a library that is published separately to NPM. Sometimes we need to publish pre-release library versions for use in other repos before the product release is ready.

Once the branch is merged our entire team of >10 developers will be using this, so I'll very quickly have solid feedback if there are any problems or concerns 😂

Yea that all sounds fair, because merge is done after the batch, it will only merge releases that were batched. So if the product is not yet ready, you would just hold off doing the batch. Doing a merge all or just a merge with that specific project won't do anything if there are no new releases.

[TheSpyder]

Ah, this is where my lack of changie knowledge starts to show. Yes, we are likely to not batch changes until the product is ready - so merge forcing all is totally fine.