cc-component-library v1.1.0
CC Component Library
This project uses Angular v.5.2.0, and was generated with Angular CLI version 1.7.0.
Quick Links
Getting started
After cloning the repository—and running npm install for the first time—the app can be started with the command npm start. Navigate to http://localhost:4200/. The app will automatically reload if you change any of the source files.
Useful Commands
| Command | Description |
|---|---|
npm start | Starts the sever at http://localhost:4200/. |
npm run build | Compiles the application in the dist/ directory |
npm test | Compiles the project and runs all Karma tests |
npm run lint | Checks the project for any linting errors in the TypeScript |
How to Contribute
Additions to the component library come in three flavors: features, patches, and hot fixes; each of which have their own branching strategy and purpose.
1) Features
If you would like to create a new component, or improve upon the functionality of an existing component, you’ll need to start by creating a feature branch off develop.
A feature branch with the name new-feature-branch can be created with:
git checkout -b feature/new-feature-branch developTo keep your branch up to date and free of merge conflicts, you should frequently pull the develop branch into your feature branch; this is different than other Git flows, where you frequently pull a branch like master to stay up to date.
NOTE: Avoid pulling the sandbox branch into your feature branch. sandbox is a testing environment—not a staging environment—so changes in sandbox are still volatile and unready for release.
Once the feature has been completed, it should be documented with a short, concise description in the unreleased section of the CHANGELOG.md file. Additions to the changelog provide clarity as to what changes have been made between versions, and makes it easier to review the code.
If npm test and npm lint both run without fail, a pull-request may be raised; first for sandbox, where the code may be tested in a “live” environment, and then develop, where the code will be integrated with the next planned release. Any code that has made it to develop but not master is in a pre-release stage, but for all intents and purposes the code can be considered released. Do not expect to be able to make large changes once a feature has been merged with develop.
2) Patches
Patches are essentially bug fixes, and represent small changes to existing, non-breaking features already in release. Unlike hot fixes, patches do not have any greater priority assigned to them and can therefore be created off of develop — similar to features.
To create a branch specifically for a patch, run:
git checkout -b feature/new-patch-branch developSimilar to features, patches should be documented with a short, concise description in the unreleased section of the CHANGELOG.md file.
3) Hot Fixes
If a bug fix is urgent, and needs to be released immediately, a hot fix should be created instead of a patch. Hot fixes are created off of master and merged back into master and develop, allowing them to be released immediately.
To create a hot fix branch, run:
git checkout -b hotfix/new-hotfix-branch masterAvailable features
| Feature | Notes | Docs |
|---|---|---|
| Buttons | View Code |