untool is a JavaScript tool designed to streamline configuration and usage of other JavaScript tools. By default, it comes with a basic development and runtime environment for universal React applications. This environment is highly modular. Every one of its default modules is configurable and extensible - and entirely optional.
Docs
Contribution
Setup
We are using git, lerna and yarn for building untool. To be able to help us out effectively, you have to have git and yarn globally available on your machine.
If you want to contribute to untool, create a fork of its repository using the GitHub UI and clone your fork into your local workspace:
$ mkdir untool && cd $_
$ git clone [email protected]:<USER>/untool.git .
$ yarn install
Adding a new feature or fixing a bug
When you are finished implementing your contribution, go ahead and create a pull request. If you are planning to add a feature, please open an issue first and discuss your plans.
All code in this repository is expected to be formatted using prettier, and we will only merge valid conventional commits in order to enable automatic versioning.
We will not usually accept pull requests introducing breaking changes unless we are preparing a major release: untool strives to be a solid and robust base for others to build upon.
Releasing a new version
Releasing untool requires the environment variable GH_TOKEN to be set to a valid GitHub access token with the public_repo scope in order to publish the release notes to the GitHub releases page.
Branching in untool
We are using the master branch as our staging branch and we have a maximum of two active release branches at a time. The release branches follow the naming convention of vN.x (where N is the major version number of that release).
All PRs (except for PRs generated by renovate or release PRs) must be made against master and include in their description, and through a label, for which release they are intended.
We have appointed branch maintainers for each of the release branches, who will take care of cherry-picking the required changes.
During preparation of a new release the branch maintainer for that release will cherry-pick the required commits from master into a PR targeting the release branch.
If conflicts arise during cherry-picking or if a backport needs to be re-created, the branch maintainer may contact the original author to resolve these issues (ie. the original author will resolve the conflicts or re-create a path for an older release branch).
Once the release preparation PR is merged into the release branch, the branch maintainer will release the packages to the npm registry.