Clarification: Programmatically generating change files

"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": "myaccount@microsoft.com",
  "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

Start with src/changefile/getChangedPackages.ts and src/bump/gatherBumpInfo.ts, then review the referenced beachball.config.json and .rc configuration paths and the change-file JSON format. Determine whether programmatic generation is supported by the existing rules, including publishability and dependentChangeType defaults; done means the complete behavior is documented or an agreed implementation scope is defined.