Skip to content

Latest commit

 

History

History
63 lines (53 loc) · 2.22 KB

contributing.md

File metadata and controls

63 lines (53 loc) · 2.22 KB

Contributing

Linting and Formatting

Not standardized. Read (internal) Formatting & Linting.

Best Practices

Development Workflow

We use a modifed version of GitFlow.

  • "feature branches" have a specific prefix:
    • feat/ for features and updates
    • fix/ for bugfixes and hotfixes
    • refactor/ for large internal changes
    • style/ for code style changes (white-space, formatting, etc.)
    • chore/ for no-op changes
    • docs/ for documentation
    • perf/ for performance improvements
    • test/ for test case updates
    • or other "types" from Conventional Commits
  • "develop" branch is usually main,
    but can exist as a long-lived multi-feature branch prefixed with dev/
  • "release branches" (as needed) are prefixed with release/
  • "hotfix branches" are prefixed fix/
  • "master branch" is always main

Release Workflow

Only appointed team members may release versions.

  1. (one time) Login to npm via:
    npm login
  2. Create new branch for version bump.
  3. Verify build is up-to-date:
    npm run build:css
    Commit substantial unexpected changes via independent PR.
  4. Update CHANGELOG.md.
  5. Update version via:
    npm version vN.N.N
    (where N.N.N is the version tag)
  6. Build with new version:
    npm run build:css
  7. Commit, push, PR, review, merge.
  8. Publish to NPM via:
    npm publish --access public
    Project build will automatically occur before publish.
  9. Create release and tag on GitHub.
  10. Fetch the latest tags.
    git fetch --tags
  11. Check whether tag is annotated.
    git describe --always
    (expect vN.N.N i.e. the version tag)
  12. If tag is not annotated, then:
    1. Annotate Github's tag:
      bin/annotate-tag.sh vN.N.N
      (where N.N.N is the version tag)
    2. Overwrite remote tag with annotated one:
      git push --tags --force