Armstrong is a React component library made by Rocketmakers written in Typescript and SCSS.

By default, Armstrong doesn't pre-compile its SCSS into CSS, allowing consuming projects to make use of its various SCSS variables and mixins.

JIRA board (for internal use)

Armstrong is installed using npm.

# This repo is currently @rocketmakers/armstrong-edge, writing docs as if deployed as main armstrong package
npm install @rocketmakers/armstrong
# or
yarn add @rocketmakers/armstrong

Then to use a component in your project

import { Button } from "@rocketmakers/armstrong";

const MyComponent: React.FC = () => {
  return (
    <div>
      <Button>I'm a button</Button>
    </div>
  );
};

See Storybook for a list of all available components

For details on how to import Armstrong's styling, see SCSS

For details on using Armstrong forms, see Forms

If you're internal to Rocketmakers, post in the #armstrong channel and raise an issue here

Otherwise, raise an issue in Github and follow the issue template

First cd into the root of the repo and run

npm install

There are two options for working on Armstrong.

• We have a playground, which is just a really simple react app with no linting, which has the Armstrong module linked in using npm link
• We have a Storybook implementation which will pick up any files with the pattern *.stories.tsx

For the playground, run

npm start

# then in separate window from /module run
npm run start-sass

then go to localhost:3001

For Storybook, run

npm run storybook

# then in separate window from /module run
npm run start-sass

then go to localhost:6006

npm run start-sass will spin up a watcher which will watch all SASS files and rebuild them

For more information on using SASS, see SASS Concatenation in [SCSS](STORYBOOK LINK TODO)

Armstrong uses eslint, style-lint, and prettier for linting.

Packages for these are managed as dev dependencies in NPM, and configuration files can be found in module/

We recommend using the vscode plugins stylelint, eslint, and prettier to make errors show in vscode, and to allow auto fixing functionality.

Please work in feature branches named feature/* branched from main

When your work is ready, submit a merge request and (if you're internal) post a link to your merge request in the #armstrong-dev slack channel for someone to review.

There will be a CI which will run to check if your work passes linting and if Storybook can still build.

One day we will talk about testing...

Armstrong uses Semantic release https://semantic-release.gitbook.io/semantic-release/ for automatic versioning and publishing based on comittizen formatted messages. The type of release will be worked out from all of the commit messages in your merge. So the highest of the following will dictate the version

fix: will be a patch 0.0.X
feat: will be minor 0.X.0
breaking: will be major X.0.0
chore: won't trigger a release

So basically do your work on a branch feature/ or bugfix/, make sure all of your commit messages go through comittizen and when your happy do a PR onto main.

When it gets approved and merged in the release type will automatically be worked out based on the highest (breaking > feat > fix) of all the commits that are part of that merge and a tag and version will be published to npm automatically.