Campfire is a design language. It creates consistent user experiences within our products. Campfire's UI styles, patterns, components, and other assets are all reusable. By creating these pre-produced elements, we can put more emphasis on use cases and business needs. Campfire is flexible and is meant to help transform into a custom solution.
 IE / Edge |
 Firefox |
 Chrome |
 Safari |
 iOS Safari |
 Samsung |
 Opera |
|---|---|---|---|---|---|---|
| IE11, Edge | last 2 versions | last 2 versions | last 2 versions | last 2 versions | last 2 versions | last 2 versions |
Install the component library.
$ npm install usi-campfireImport the component modules you want to use into your app.module.ts file and feature modules. Campfire uses
secondary entry points for all of its components and omits a primary entry point, meaning each component will need to be imported from its respective folder.
+ import { UsiAvatarModule } from 'usi-campfire/avatar';
+ import { UsiButtonModule } from 'usi-campfire/button';
@NgModule({
imports: [
+ UsiAvatarModule,
+ UsiButtonModule
],
})
export class AppModule {
}To pull in Campfire's global CSS variables we need to import the stylesheet into our angular.json.
{
"styles": [
+ "node_modules/usi-campfire/campfire.css"
]
}After cloning usi-campfire and running npm install to install its dependencies, you may also run the following commands:
npm startruns the Campfire test app locally.npm run storybookruns the Storybook app athttp://localhost:9009npm run lintchecks the code style.npm testruns the complete test suite.npm run test:watch [name]runs some test files and monitors for changes.npm run build_libcreates a build of Campfire under publish directory.
Before submitting a pull request, please make sure to follow the steps below:
- If you have fixed a bug or added a feature that should be tested, please add test cases!
- Make sure the test suite passes (
npm run test). - Make sure your code lints (
npm run lint). - Make sure to rebase your code to keep the history clean.
- Make sure your commit message meet the requirements presented below
After the steps above have been completed please follow the list below.
- Fork the repository of
usi-campfire. The latter steps must be done on the forked repository - On main:
git remote add upstream https://github.com/AustinWildgrube/campfire-design-system.git - On main:
git pull upstream main - Checkout to the feature branch (for example, if the branch is called docs-fix):
git checkout docs-fix - On docs-fix rebase on main:
git rebase origin/main - On docs-fix resolve codes and commit:
git commit -a, you need to follow the commit message guidelines - Then, push up:
git push(might need -f, just be sure you understand force pushing before you do it) - Submit a Pull Request on the GitHub
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the Campfire change log.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and the scope of the header is optional.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
Footer should contain a closing reference to an issue if any.
Samples:
docs(changelog): update change log to beta.5
fix(button): change padding from 8px to 12px
The designers were wanting the padding to match their new style and figured it was time to change it
in the component library.
fix(release): need to depend on latest rxjs and zone.js
The version in our package.json gets copied to the one we publish, and users need the latest of these.
If the commit introduces a breaking change, it should include a ! in the header after the scope. The commit must also include a body describing the breaking
change and what needs to be fixed to accommodate it.
feat(button)!: add secondary entry point
The button component needed a secondary entry point to reduce the size of the module. Instead of the button being
imported from the shared module, it will now be imported from the button folder.
If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
Must be one of the following:
- build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
- docs: Documentation only changes
- feat: A new feature
- fix: A bug fix
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- test: Adding missing tests or correcting existing tests
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.
Perform the following steps to release a new version:
- Bump the version in
package.json - Update the change log
- Merge release branch into
origin/main - Release the new version in the usi-campfire repo.