https://github.com/untool/untool
JavaScript tooling platform that focuses on universal React applications. Supports advanced features such as hot-reloading, static and dynamic server side rendering and code splitting.
https://github.com/untool/untool
code-splitting express framework hot-reloading react server-side-rendering webpack
Last synced: 4 days ago
JSON representation
JavaScript tooling platform that focuses on universal React applications. Supports advanced features such as hot-reloading, static and dynamic server side rendering and code splitting.
- Host: GitHub
- URL: https://github.com/untool/untool
- Owner: untool
- License: mit
- Archived: true
- Created: 2018-02-22T22:27:38.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2021-01-22T07:55:56.000Z (over 5 years ago)
- Last Synced: 2026-05-28T12:14:29.514Z (25 days ago)
- Topics: code-splitting, express, framework, hot-reloading, react, server-side-rendering, webpack
- Language: JavaScript
- Homepage: https://www.npmjs.com/package/untool
- Size: 19.2 MB
- Stars: 17
- Watchers: 1
- Forks: 2
- Open Issues: 27
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
- awesome-github-projects - untool - JavaScript tooling platform that focuses on universal React applications. Supports advanced features such as hot-reloading, static and dynamic server side rendering and code splitting. ⭐17 `JavaScript` (📦 Legacy & Inactive Projects)
README
`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
- [untool v2 documentation](https://github.com/untool/untool/tree/v2.x/DOCUMENTATION.md).
- [untool v1 documentation](https://github.com/untool/untool/tree/v1.x/DOCUMENTATION.md).
## Contribution
### Setup
We are using [git](https://git-scm.com), [lerna](https://lernajs.io) and [yarn](https://yarnpkg.com/en/) 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](https://help.github.com/articles/about-forks/) of its [repository](https://github.com/untool/untool/fork) using the GitHub UI and clone your fork into your local workspace:
```text
$ mkdir untool && cd $_
$ git clone git@github.com:/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](https://help.github.com/articles/creating-a-pull-request/). If you are planning to add a feature, please open an [issue](https://github.com/untool/untool/issues/new) first and discuss your plans.
All code in this repository is expected to be formatted using [prettier](https://prettier.io), and we will only merge valid [conventional commits](https://conventionalcommits.org) in order to enable automatic [versioning](https://semver.org).
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](https://github.com/lerna/lerna/tree/master/commands/version#--github-release) to a valid [GitHub access token](https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line) with the `public_repo` scope in order to publish the release notes to the [GitHub releases page](https://github.com/untool/untool/releases).
### 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.