@dylankelly/design-system-rebrand NPM

Design System Rebrand

The contents of this repository have been produced by The University of Melbourne for internal use and must not be distributed without the express permission of The University of Melbourne.

Set-up

The design system requires Node.js v6.11.2, and the latest version of yarn. To set it up, run:

git clone https://github.com/unimelb/design-system-rebrand.git
cd design-system-rebrand
cp .env.example .env
yarn

Development

Storybook is the main development environment.

yarn start - http://localhost:7002/
yarn run build to build the documentation site to /.out/docs. Environment variable LOAD_EXTERNAL_ASSETS controls whether the documentation site is to load the library assets locally (false) or from the CDN (true).

Targets

Library - `targets/lib`

The main library for use in the CMS. The target provides a local development environment for testing purposes.

yarn run start:lib - http://localhost:7003/.
yarn run build:lib to compile the library to .out/lib/<version>. Environment variable LOAD_EXTERNAL_ASSETS controls whether the library is to load its assets locally (false) or from the CDN (true).

Linting

CSS files are linted on the fly with stylelint. The configuration file, .stylelintrc, extends two shared configuration: stylelint-config-standard and stylelint-config-property-sort-order-smacss.

JS files and single-file Vue components are linted on the fly with ESLint. The configuration file, .eslintrc, extends two shared configurations: eslint-config-airbnb and plugin:vue/recommended

For your own sanity, make sure to install your code editor's ESLint and stylelint extensions. The following commands are available for on-demand linting and fixing:

yarn run lint
yarn run lint:fix
yarn run lint:css
yarn run lint:css --fix
yarn run lint:js
yarn run lint:js --fix

Generator

Components

New components can be scaffolded by running:

yarn generate component

You will then be asked for the name of the component, this will be used to create a new folder with a minimal component layout and story.

Stories

New stories can be scaffolded too by running:

yarn generate story

You will need to select the component from the list of folders, then confirm the selection by selecting choose this directory. You will then be asked to give the story a name.

Note This requires some special comments are added in the stories/index.js file. If it doesn't work make sure the comments are the same as in the template directory

Release process

At the start of a new release sprint:

Create a ZenHub release called next-release.

Throughout the release sprint:

Assign the appropriate pr- label to every new PR: pr-major if it contains a breaking change, pr-minor if it adds a new feature, pr-patch in all other cases.
Assign issues and PRs to next-release as they are resolved/merged.

At the end of the release sprint:

Look at all the PRs that were assigned to next-release throughout the sprint and identify the highest-level of change (major, minor or patch). Deduce the next release's version number and rename the ZenHub release accordingly.
Create a new release notes draft based on the following template: .github/RELEASE_NOTES_TEMPLATE.md.
Write the release notes by going through all the issues and PRs assigned to the ZenHub release.
Deploy to production (cf. next section).
Once the library and documentation sites are deployed, publish the release notes and close the ZenHub release.
Share the ZenHub release report with stakeholders.

Deployment

To deploy to production:

Bump the version number in package.json (cf. note below).
Commit the version change to the dev branch.
Create a pull request to merge the dev branch into master - e.g. "Deploy v1.0.1".
Wait for the mandatory checks to pass then select "Rebase and merge" (cf. note below).

Semaphore then automatically builds the library and syncs the output files to S3. If the version you're deploying had been previously deployed, you'll need to invalidate the files on the CDN (AWS Cloudfront) or wait a day or so for this to happen automatically. Once the library is deployed, follow the release process below.

Note on versioning: the version number follows the semver convention MAJOR.MINOR.PATCH, where: MAJOR corresponds to a breaking change (e.g. a change in a component's markup), MINOR to a new feature (e.g. a new component, a new feature for an existing component, etc.), and PATCH to a bug fix or under-the-hood change (e.g. code clean-up, performance improvement, etc.)
Note on rebase: rebasing dev onto master avoids creating a merge commit that would require merging master back into dev.