Contributing to Pattern Lab Node
If you'd like to contribute to Pattern Lab Node, please do so! There is always a lot of ground to cover and something for your wheelhouse.
nvm install <<version>> nvm use <<version>>
The best way to make changes to the Pattern Lab Node core and test them is through an edition.
- Fork this repository on Github.
npm install && npm run bootstrap
- Create a new branch in your fork and push your changes in that fork.
- Test your changes with the edition's api
Cold start testing
To ensure that developers can bootstrap the repo from a fresh clone, do this in your working copy:
git reset --hard && git clean -dfx && npm install && npm run bootstrap
This ensures that any changes you've made will still result in a clean and functional developer experience. Note: be sure you've committed any outstanding work before doing this -- it will blow away whatever's still outstanding, including anything staged but not commited.
- ALWAYS submit pull requests against the dev branch. If this does not occur, I will first, try to redirect you gently, second, attempt to redirect the target branch myself, thirdly, port over your contribution manually if time allows, and/or lastly, close your pull request. If you have a major feature to stabilize over time, talk to @bmuenzenmeyer via an issue about making a dedicated
- Keep your pull requests concise and limited to ONE substantive change at a time. This makes reviewing and testing so much easier.
- Commits should reference the issue you are adressing. For any Pull Request that you send, use the template provided.
- Commits are best formatted using the conventional commits pattern.
- If you can, add some unit tests using the existing patterns in the
- Large enhancements should begin with opening an issue. This will result in a more systematic way for us to review your contribution and determine if a specifcation discussion needs to occur.
- Mention the issue number in commits, so anyone can see to which issue your changes belong to. For instance:
fix(get): Resolve patterns correctly
feat(version): Add ability to ask for version statically
Formatting is automated via Prettier, setup to run on precommit. We suggest editor integration for this and for eslint. Prettier is further configured within
.prettierrc. Eslint validates syntax and usage that Prettier doesn't handle. Configuration for both is found within the
.editorconfig controls spaces / tabs within supported editors. Check out their site.
Add unit and integration tests if you can. It's always nice if our code coverage improves bit by bit (literally!). We are using Node Tap as test framework and Rewire for mocking things like file system access.
- master contains the latext stable, released version
- dev: for development. Target pull requests against this branch.
- feature-branches for larger changes. Allows merging all changes into both
- long running branches for changes that involve major changes to the code, architecture and take a lot of time (i.e. making Pattern Lab async)
New features are typically cut off of
dev branch. When
dev is stable cut releases by merging
master and creating a release tag.
If you have any questions or you would like to help, feel free to ask on our Gitter.im channel