untool/mixinable

A functional JavaScript mixin library that is at the core of untool's core. Supports synchronous and asynchronous mixin method implementations.

 

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.
• untool v1 documentation.

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.

mixinable's Issues

Action Required: Fix Renovate Configuration

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Location: package.json
Error type: The renovate configuration file contains some invalid settings
Message: Invalid configuration option: author, Invalid configuration option: ava, Invalid configuration option: bugs, Invalid configuration option: commitlint, Invalid configuration option: config, Invalid configuration option: eslintConfig, Invalid configuration option: homepage, Invalid configuration option: husky, Invalid configuration option: license, Invalid configuration option: lint-staged, Invalid configuration option: main, Invalid configuration option: module, Invalid configuration option: name, Invalid configuration option: packageRules[0].@commitlint/cli, Invalid configuration option: packageRules[0].@commitlint/config-conventional, Invalid configuration option: packageRules[0].@commitlint/travis-cli, Invalid configuration option: packageRules[0].@untool/eslint-config, Invalid configuration option: packageRules[0].@untool/prettier-config, Invalid configuration option: packageRules[0].ava, Invalid configuration option: packageRules[0].cz-conventional-changelog, Invalid configuration option: packageRules[0].eslint, Invalid configuration option: packageRules[0].esm, Invalid configuration option: packageRules[0].husky, Invalid configuration option: packageRules[0].lint-staged, Invalid configuration option: packageRules[0].microbundle, Invalid configuration option: packageRules[0].prettier, Invalid configuration option: packageRules[0].standard-version, Invalid configuration option: prettier, Invalid configuration option: publishConfig, Invalid configuration option: renovate, Invalid configuration option: scripts, Invalid configuration option: source, Invalid configuration option: umd:main, Invalid configuration option: version

Idea: Expose a "callable" strategy

Sometimes we want to create a hook just so that other mixins may call it.
In most of these cases we use override (either sync or async).
Would it make sense to create another strategy, similar to override (but without the actual overriding part), and call it callable or something similar to indicate that this method is intended to be called from other mixins?