---
# System prepended metadata

title: chroma-lite processes

---

# chroma-lite processes

## What's involved adding a core brand - via brand attributes

The `chroma-brand-attributes` repo contains the TailwindCSS config objects for all IAG brands, so adding a new brand is simply a case of creating a new brand attributes object. 

For example adding `CUA` the developer would pull down the latest code from the repo, create `brands/cua.js`, import the global colours:

`import { status, grey } from '../global'`

Next create the brand object with primary, secondary, tertiary colour sets etc.:

```
const cua = {
  colors: {
    primary: {
      'lighten-90': '#e5e7f3',
      DEFAULT: '#000E82
      ... etc.
    },
    grey: {
      ...grey
    },
    status: {
      ...status
    }
  }
}
export default cua
```

Once complete this file should also be imported/exported in the `/brands/index.js` as per the other brands.

Finally update the version number in `package.json`, create a PR to `main` with the latest code change before the code is merged into master and published to npm.

Once the npm package is available on npm this can be imported into your TailwindCSS project using code such as:

```
const brandAttributes = require('@iag-packages/chroma-brand-attributes').default
const nrma = brandAttributes.nrma
module.exports = {
  theme: {
    extend: {
      colors: {
        ...nrma.colors
      }
    }
  }
}
```


## What's involved adding a partner brand?

The power of the `chroma-lite` setup is that any project has the power to take control of their own brand attributes and potentially share these attributes in an open source way similar to the chroma core brand attributes setup. If for instance 10 partner brands were starting their own separate apps at the same time, they can simply use our chroma-lite starter repo and create their brand attributes directly in the `src/config` dir similar to above (but without importing anything from chroma-brand-attributes) and run the build scripts in the app to generate the brand specific classes without any intervention from the Chroma team. The starter repo is framework agnostic so each brand can create their own component libraries and/or use chroma defined components as necessary in whichever framework they want to use.

## Where do the brand attributes get defined?

All brand attributes should be defined in Figma and then passed on to Development teams to implement.

## How are assets controlled in chroma-lite?

It is assumed that the apps would control their own assets when using chroma-lite, for instance images can either be included in an application bundle or possibly hosted on a CDN such as Cloudinary, Cloudflare etc. and referenced within the code. Again this gives the development teams full control and not having to rely on updates from the Chroma team.

## What about Chroma created reusable components?

As chroma-lite is designed to be framework agnostic the initial starter repo will include a number of component examples in html markup only, these can then be used to form the basis of a Vue, Angular or React component library.

We are thinking that it would be useful to create a default set of React components that are self contained and individually installable via [bit.dev](https://bit.dev) and potentially these can be open sourced as each component can be worked on and versioned in isolation.

## How a Single Page App  (SPA) can live inside our cloned starter app?

It is possible to run a React app for example as a subdirectory of the chroma-lite starter repo, simple create the subdir and setup your app as you would normally as all you need to create the brand specific app is to include the generated Tailwind css file which references the brand attributes. As part of the starter repo we include a file called `webpack.mix.js` which can be used to copy the compiled tailwind css into your other directories, such as `/react/css` or `/vue/css`.

## Why aren't border-radius and other brand specific settings in the brand config?

TailwindCSS is such a complete platform that it seems unnecessary to set a default value when there are already so many options. Taking the `border-radius` as an example there are 9 sizes to choose from (https://tailwindcss.com/docs/border-radius) therefore if a developer was to setup a brand knowing that the border-radius in Figma is set to `0.375rem` the `rounded-md` class is applied whereas another brand that uses `0.75rem` radius sets a `rounded-xl` class. 

## X brand has different breakpoints how will that work?

Using chroma-core this isn't really possible but with tailwind breakpoints can be set per application very easily in the config file:

```
module.exports = {
  theme: {
    screens: {
      sm: '640px',
      md: '768px',
      lg: '1024px',
      xl: '1180px'
    },
  }
}
```