Welcome to the Citizens Advice Design System. A tool that we hope will ease the building and styling of digital services and products throughout the organisation. We've tried to make the process one that's simple and efficient enough to get started building, but one that isn't prescriptive. We welcome discussions for new components, bugs and platform improvements, check out the how to contribute section for this information.
Our platform uses the "mono-repo" concept, where all aspects of the Design System can live together. This provides better management rather than splitting each out into their respective repositories. Currently we have:
- the packages which are the framework itself,
- the documentation website.
We're making use of Lerna and Yarn workspaces to help with the dependency management, meaning we can publish each component individually. This gives a consumer of the framework the power to pull in only what they require.
We also make use of Docker to make sure we avoid the "it works on my machine" statement. We detail the instructions for setting this up in each section, but make sure you've installed Docker beforehand.
$ npm install @citizensadvice/cads
If you check in your node_modules
directory you should now have a @citizensadvice/
directory that contains all the packages required to get up and running.
node_modules/
└── @citizensadvice/
├── buttons/
│ ├── build/
│ ├── lib/
│ ├── index.scss
│ ├── package.json
│ └── README.md
├── utilities/
│ ├── build/
│ ├── lib/
│ ├── index.scss
│ ├── package.json
│ └── README.md
└── ...
For completeness, we've included an output .css
file for each component. This serves a couple purposes, firstly we can test to see whether our components build correctly without errors. Secondly, should you not be able to use sass
in your pipeline, we've still got you covered.
This directory contains the source files that can be compiled using sass
during your build process.
Now that you've npm install
the packages into your node_modules
, link to them like you would any other scss
file.
@import "@citizensadvice/cads";
...
> Be sure to add `node_modules` to your included-paths for the above to work correctly.
### Releasing packages
We make use of [Lerna](https://lernajs.io/) in order to make the package releasing process a lot easier to manage. We're making use of the single release version for **ALL** packages, meaning that if one is updated to `v1.0.5` then they all are.
To release a new version of the framework:
- Create a new branch in the form `release/v0.0.0` (inputting the new version number).
- Run `$ yarn publish:packages` and follow the in terminal commands.
- With that done, you should have a bunch of file changes that need committing in your packages directories.
- You'll now need to update the version of the framework displayed on the website in file `./website/_config.yml`.
- Final task would be to commit and create a PR ready to be merged to `master`.
Once the PR has been confirmed and merged, you can then release a new version of the website by running:
```shell
$ yarn publish:website
So you'd like to get the documentation up and running on your machine? There are a few things we need to take care of first. Once you're confident you have your environment setup, move onto the Setup Documentation section.
You need to have the following installed on your machine:
- Docker (direct download available through the release notes https://docs.docker.com/docker-for-mac/release-notes/)
- Git (we recommend using Homebrew)
Navigate to the repo and clone
it by running either (it depends on how your security is setup).
$ git clone [email protected]:citizensadvice/cads.git
$ git clone https://github.com/citizensadvice/cads.git
Great you have the repository on your machine now.
cd
into the cads
directory (the root
), and build the Docker image:
$ make build
Running the next command will start the Docker container and automatically attach to it.
Remember to pass the output pwd
command to this command so it know's where to look for your cads
directory when sharing with the VM.
$ make start LOC=~/root/path/to/cads/directory
If the above was successful, you'll now be inside the VM and can install all dependencies required with the below:
$ yarn fresh
We run the documentation site on the Jekyll platform, but all that dependency management was handled with the above command
When all the above is complete, we can get the docs up and going by running:
$ yarn start:website
This will start Jekyll and compile the stylesheets / scripts.
Now if you open a browser window at http://localhost:4000
you should see the homepage.
We do have a few extra scripts that can be run when developing the framework and the documentation. Open up the root
package.json
to see these.
Anybody and everybody is welcome to get involved in contributing to the framework, but in order to stop it from becoming bloated, we usually only consider adding new components to the framework when one is being used on more than one application, site or service.
- Create a new branch making sure you adhere to the git style guidelines.
- If you're fixing the
framework
, make sure to makeCSS
changes in thepackages/
directory as these are the framework source files. - If it's the website you're changing, make those updates in the
website/
directory. - Next create a pull request where upon some discussion around the PR will happen.
If the changes to the framework have been successful, you'll need to publish these new changes/additions to the NPM registry.
Start out by increasing the version number of your packages, this does it for ALL.
$ yarn packages:publish
Follow the instructions, we're following semantic versioning conventions.
You will also need to update the website with the new version of the framework. This can be done in
./website/_config.yml
by changing the string next to the keyframework_version
, after this, follow the details for "Releasing a new version of the site".
Simply run
$ yarn build:packages
This section may sound rather prescriptive, but in order to keep things easy to manage, let's try to stick to some conventions around branch names, and commit messages
$ git checkout -b [issue-type]/[issue-number]-[issue-title]
an example...
$ git checkout -b docs/71-refactor-readme-content
Another developer can see exactly what this is from the branch name, which issue / PR it relates to and the type of change it is, all without having to look at the log.
[issue-type] [issue-number]: Brief description of commit
A longer description, perhaps also listing out the solution(s) or
any other relevant detail for this specific commit
[issue-number]
Again, an example would be...
Docs #71: Refactor repo README
Rewrite the repo README to include setup information around the framework.
[#71]
You'll make many different types of change to the codebase over time but most changes can be categorised under one of the following types. Make use of one of these when writing your commit messages.
Issue type | Description |
---|---|
feat |
a new feature |
fix |
a bug fix |
docs |
changes to documentation |
style |
formatting, missing semi colons, etc; no code change |
refactor |
refactoring production code |
test |
adding tests, refactoring test; no production code change |
chore |
updating build tasks, package manager configs, etc; no production code change |
While this might feel overkill to dictate how to write commit messages, doing so also means when reviewing Pull Requests, we can quickly see which commit belongs to which ticket without having to match up commit messages to ticket titles.