Add way to view pkg changes since latest release

[mcmire]

Description

When creating a new release, it can be helpful to be able to view the changes that have been made to a package since its most recent release. This commit adds a package script, since-latest-release, which can be used to accomplish this.

This script is simply a shortcut for a commit range, so you can plug any Git command that takes a commit range into it. For instance, to view the list of latest commits for @metamask/assets-controllers, you can use log:

yarn workspace @metamask/accounts-controller run since-latest-release log

Or to view all changes, you can use diff:

yarn workspace @metamask/accounts-controller run since-latest-release diff

Or you can leave an argument off to just get the names of commits:

yarn workspace @metamask/accounts-controller run since-latest-release

Testing

Try running the command above, using a package that has new changes. Try to break it.

Changes

(No user-facing changes; this is a developer-only change.)

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation for new or updated code as appropriate (note: this will usually be JSDoc)
• I've highlighted breaking changes using the "BREAKING" category above as appropriate

[mcmire]

Hint: if you stick this in your shell configuration:

yw() {
  local command="workspace"
  if [[ $1 == "focus" || $1 == "foreach" || $1 == "list" ]]; then
    command="workspaces"
  fi

  yarn $command "$@"
}

then you can shorten the above to, e.g.:

yw @metamask/accounts-controller since-latest-release

[mcmire]

This makes it so that if you're on a release branch, the list of changes you see don't include any of the commits in the release branch itself.

[mikesposito]

I tried to execute different types of commands, but I was initially confused by the results: it showed 45a2971 as oldest commit for @metamask/keyring-controller, which was released a while ago.

Apparently, for it to work correctly git fetch should be executed first. It makes sense, but perhaps since this is supposed to be a "batteries-included" script we could run it automatically before running the command so that results don't get stale?

This looks good regardless of the above optional suggestion

[mcmire]

@mikesposito Okay, thanks for the review. This command is designed to make creating releases easier, so that gets me thinking: Do you think this utility belongs in create-release-branch instead? Then we can assume that the user is running this from a release branch (which should be up to date) and not from, say, main (which may not be).

[mcmire]

I'll go ahead and merge this as I think this could be useful. I hesitate to run git pull automatically because I expect it to be run on a release branch, but if that changes then we can tweak it a bit further. Or if it ends up being useful we can consider adding it to create-release-branch.

[mcmire]

Resolved a lint failure.

[cryptodev-2s]

Looks good to me. The branch needs to be rebased. Additionally, there are some typos in the PR description: replace git-since-latest-release with since-latest-release for the diff and no argument commands.