Add changelog generator script

[felixarntz]

Fixes #41

This PR takes over the code from Gutenberg's changelog generator script to this repository, with a few adjustments for our purposes. Overall, our implementation can be a bit simpler than theirs since we don't have as many labels and complex requirements to our changelog - at least not yet 🙂

In order to test this PR, pull the branch and run the following command (make sure to update dependencies first):

npm run changelog -- -m "Initial plugin release"

You can provide any milestone title as argument, but the above is the only one we have so far (see https://github.com/WordPress/performance/milestones).

The above should give an output like the following (which can later be directly copied/pasted into the readme.txt file):

= Initial plugin release =

**Features**

* Images: Add WebP for uploads module. ([32](https://github.com/WordPress/performance/pull/32))
* Infrastructure: Add settings screen to toggle modules. ([30](https://github.com/WordPress/performance/pull/30))

**Documentation**

* Infrastructure: Add contribution documentation. ([47](https://github.com/WordPress/performance/pull/47))
* Infrastructure: Define module specification in documentation. ([26](https://github.com/WordPress/performance/pull/26))

Our milestones will eventually be named with actual versions, i.e. instead of = Initial plugin release = the output would start with something like = 1.0.0 =.

More in-depth overview of the changes:

• Add bin/plugin folder with cli.js entrypoint to the plugin's CLI framework.
  • Mostly copied from Gutenberg, with a few simplifications.
• Add bin/plugin/commands/changelog.js with the implementation of the changelog command. That is going to be the only command we need for now.
  • Mostly copied from Gutenberg, with a few simplifications.
  • Passing a --milestone or -m argument is required in our case.
  • The changelog is generated based on the specification in Define changelog approach / tooling #41 (comment).
    • It gets all closed pull-requests for the given milestone.
    • It groups them by their [Type] xyz label.
    • It then uses the pull-request title and prefixes it with the focus (from [Focus] xyz label) or the word "Infrastructure" (from Infrastructure label).
    • The output format is different than the one from the Gutenberg script because the changelog we generate needs to be compatible with the wordpress.org readme.txt format (which Gutenberg is not using for its changelog, it uses regular Markdown instead).
• Add bin/plugin/lib folder with some common utility functions.
  • Pretty much an exact copy of the same Gutenberg files.
• Add npm run changelog script that calls the above changelog command via the new CLI tool.
• Add ESLint configuration via @wordpress/scripts package, with format-js and lint-js commands.
  • This is only added in a very simple way to have basic linting and formatting for the new JS files in the bin folder, which at this point are the only JS files in the entire project.
  • Any enhancements to the configuration and a GitHub action to enforce linting can be added in a follow-up issue.
• Add relevant packages for all the above as devDependencies to package.json.

[JustinyAhin]

Implementation wise, this looks fine to me @felixarntz. Tested and it worked as expected.

I was wondering, when the npm run changelog -- -m "Initial plugin release" command is run, would it make sense to paste the output in the clipboard, or even paste it in the README.txt file directly? We can anticipate that with time, the generated changelog will be bigger and bigger, and at least the first option will come handy.

[felixarntz]

@JustinyAhin

I was wondering, when the npm run changelog -- -m "Initial plugin release" command is run, would it make sense to paste the output in the clipboard, or even paste it in the README.txt file directly? We can anticipate that with time, the generated changelog will be bigger and bigger, and at least the first option will come handy.

Great idea! I think we could eventually add this, but since we don't have the readme.txt yet, I think it would be helpful to do that separately once it's there. Maybe another command like npm run update-changelog or npm run readme-changelog that would rely on the above npm run changelog command and then inject the output into the readme.txt. That way we'd have both commands and they could be run individually, since sometimes it may also be useful to only see the "current" changelog output, e.g. to double-check.

Maybe worth a follow-up issue (which would depend on both #40 and #41 to be completed)?

[JustinyAhin]

Maybe worth a follow-up issue (which would depend on both #40 and #41 to be completed)?

Yes definitely. Let's merge this one first when it's ready, and move forward.