Clarification: Programmatically generating change files

[GiriB]

"How does beachball decide which changes to create change files for?"

Context

We have an automated dependency update service (a fork of dependabot-core) running on our repos. This service creates a PR whenever a dependency update is available. The only files that ever change are the package.json(s) and the lock files.

As a feature request from our customers, we plan to add support to generate beachball change files (along with package.json and lock file updates).

Problem

beachball uses git and remotes to figure out what changed. However, running "beachball change" is not an option for us since we do not git clone a repo when we run the updates (we just call ADO APIs to get the relevant package.json and lock files).

The other thing we could do is generate the change files programmatically by following steps below.

1. Get the list of files that changed. (We already have this. E.g ["packages/pkg1/package.json", "packages/pkg2/package.json", ...])
2. If the changed file is a package.json and is publishable, create a change file.

The change file will be a json like this

{
  "type": "patch",                           // customers agree that this can be set to "patch" always
  "comment": "Auto-updates",
  "packageName": **pkg.name**,
  "email": "[email protected]",
  "date": "2020-09-04T17:28:54.036Z"
}

Questions

Does the approach described above look good (in terms of completeness and correctness of how a change file should be)?

1. For checking whether we need to create change file for a package or not, I'll check for this condition. Are there other ways to define whether a package is publishable (via beachball.config.json or .rc files)?
2. dependentChangeType will never be set. Again, we believe that should be fine and default of "patch" will be used.

Thanks for taking a look!!

FYI @kenotron

[GiriB]

Taking another look, I see that it's possible to use the writeChangefiles to create the change files, the only blocker for me is that it expects a git repo to be in place (see this and this).

Would it be a good idea to separate "create change file" from "git-add change files"? That way it'd be much easier to programmatically create change file without doing hacks that may break if beachball decides to update it's change file format.

[codyzu]

Kinda late to the party, but for others that stumble on this. While investigating auto generating change files, I think I'm going to take the approach of using beachball itself:

beachball change --message "change file comment" --type "patch" --package "your/package"

I'm also considering the --no-commit and --dependent-change-type options as needed.

Finally, if you want to do this by code, use your preferred way to execute beachball :wink: :

child_process.execFileSync('npx', ['beachball', 'change', '--message', comment, '--type', 'patch', '--package', package])

Maybe not the most efficient way, but avoids the problems of needing to access what appears to be an API not intended to be called externally.