Conventional Commits & Changelogs

[lazd]

Todo

• Merge docs: create issue templates #282 into this branch so we have issue templates
• Create gulp releaseBundles task to release all bundles
• Update CONTRIBUTING and release docs to refer to new conventions and processes
• Make CHANGELOG template even prettier?
  • ❌ Consistently use "Changelog" (one word)
    • Blocked: Allow customization of CHANGELOG header lerna/lerna#2272
  • Include bold component name as scope so its listed out nicely for parseability

Description

This PR adds CHANGELOG.md generation based on conventional commits. In addition, we're now using yarn, bundles are no longer managed by lerna, and a new release process has been added for bundles.

Adopt Conventional Commits

Git hooks are now included that ensure commit messages conform to the conventional commits convention.

This gets us consistency and automatic releases that know exactly what version of a component to release based on the commit messages as well as automatic CHANGELOG generation.

Generate CHANGELOGs

This PR adds CHANGELOG generation for components based on conventional commits and is able to generate CHANGELOGs for bundles as well, linking out to the individual component's CHANGELOG for details.

Custom Spectrum CHANGELOG template

It's pretty and it knows how to link to documentation for bundles. I've asked design to weigh in to see if we can make it prettier.

New release process for bundles

Since the version number of a bundle needs to be in step with the components inside of it, a new gulp updateDeps task was added to analyze the current package.json vs all of the components in the monorepo, update their version numbers if available, and bump the version number of the bundle appropriately. That is, if a component included in the bundle has a patch, minor, or major version bump, the bundle should get one too.

Switch to yarn

It's faster and works based on package.json's workspaces field. Nice.

Codify use of peerDependencies

If a component relies on another component to render the example markup, it should be declared in both devDependencies and peerDependencies.

The release will error out if:

1. A package is specified in peerDependencies that does not appear in devDependencies
2. The version of a package is specified in devDependencies satisfy the range defined for that package in peerDependencies

Related Issues

• SDS-2239 - Implement support for Spectrum CSS releases and changelogs with conventional commits and commitlint
• SDS-2241 Update CONTRIBUTING.md, ISSUE_TEMPLATE.md, and PULL_REQUEST_TEMPLATE.md
• SDS-2240 Finalize dependency declaration strategy
• SDS-2252 Look into lerna link convert instead of lerna bootstrap

Motivation and Context

This helps us perform releases efficiently and document what has changed.

How Has This Been Tested?

Many fake releases.

Bundle changelog: https://git.corp.adobe.com/lawdavis/spectrum-css-lerna-test/blob/ccc/bundles/spectrum-css-compat/CHANGELOG.md

Component changelog: https://git.corp.adobe.com/lawdavis/spectrum-css-lerna-test/blob/ccc/components/calendar/CHANGELOG.md

Screenshots (if appropriate):

Bundle changelog:

Component changelog:

[lazd]

Not sure what to do about the fact that this was forked from https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular. We need to reach out to that project's owners and see if this needs to live in their monorepo...

In the mean time, then package is set to private, so we're good.

[lazd]

Not sure if I like the fact that patch releases get a smaller heading... Thoughts from others?

[jianliao]

I like small heading as it is more clear at the first glance.