landg-dls v1.6.3

Legal and General design system

Welcome to the L&G DLS, satifying all of your digital pattern needs since 2018. This is a single point of reference for all the patterns we use in Legal and General's projects, so that anyone can refer to them. Teams can install the DLS NPM package and use any of the components and styles in their project. The DLS website is a reference tool and a guide for the DLS.

Quick Start

Make sure you are up to date with the latest version of node and npm.

To get up and running: 1. Clone the repository 2. Change to the repository directory on your machine 3. Run npm install to install dependencies 4. Run npm run start to start the application

Linting

SCSS files can be linted with:

`npm run linter`

This is also running every time you run npm run start.

How to run tests

SCSS unit tests

`npm run sass:test`

Accessibility automated tests (Pa11y)

`npm run access:test`

Screenshot comparison tool (Wraith)

The comparison tool spins up a server with your current changes and compares it with the production environment.

Setup of Wraith

1. First you will have to add a .gemrc at the user root unless you already have it. Then run:

   $ gem sources -r https://rubygems.org/
   $ gem sources -a http://rubygems.org/

2. Make sure you are in the project directory and then run:

   $ gem install bundler
   $ bundle install

3. Install Homebrew from https://brew.sh/.

4. Run brew install imagemagick.

Run Wraith

npm run wraith:test

Versioning

It's very important to keep a meaningful version history in the DLS. It allows designers and developers to stagger the roll-out of updates across projects and teams, and keeps track of changes over time. For instance; a scrum team may choose to install a specific version of the DLS via NPM if they are not ready to adopt new features yet.

The DLS version is tied to the Git tag history, and it is displayed in the DLS website within a table: http://landg-dls.s3-website.eu-west-2.amazonaws.com/#version-history

Tagging

For each new version of the DLS, use the NPM Version command, for example:

`npm version v1.8.1 -m "A concise and meaningful tag message"`

This will do the following:

1. Run the linter, SASS tests and accessibility tests - stopping the process if any fail.
2. Update the version property in package.json.
3. Create a new annoated Git tag, setting the message as per the -m option.

When ready, you will then just need to push your tag to the remote repository:

`git push origin <tag_name>`

Guidelines

• The tag name/version number should follow the Semantic Versioning pattern. E.g. v1.6.0 - "major, minor, patch".
• The message should be a relevant, concise and meaningful, e.g "New component: Date Picker" or "Redesign all button styles in line with new VI".

How the tags are displayed in the DLS website

The build scripts use the following following command:

`npm run git-tags`

This runs the Node script configs/git-tag.js, which reads the Git tags from the working directory and then outputs them as a JSON file: src/data/tags.json. This file is included in the Handlebars compilation step, where it is combined with the content in src/data/data.json, and then used to render the version history table template. See src\layout\partials\section-templates\section-version-history.hbs. Note that in the DLS Pipeline, tags.json is regenerated based on the tags that exist on the remote repository.

Other Commands

Check the package.json for other commands you can run.

How to contribute

If you wish to make changes and/or add new components to the code base please branch off development. When the code is ready create a PR including Elena Garrone and/or Paul Bennett plus any other person that might be interested.
When committing remember to follow our git commit standards.

When merging into the development branch the code will go through the Jenkins pipeline, create reports for npm audit and wraith (you can add yourself to the dls-jenks-dev-alerts channel in Slack to be notified) and publish to the landg-dls-dev environment.
This is the environment where testers should test the styles before merging the code into the master branch.

When merging development into master the code will again go through the pipeline, create the reports mentioned above and publish into landg-dls which is our production environment.

How to update the DLS

For instructions on how to update and modify the DLS please read the how to update the dls.

Using the DLS

For instructions on how to use the DLS in your project please read the usage of DLS as a dependency.