Automating open source project configuration with Mrm
Watch my talk with the same name at React Open Source meetup.
We use many tools, like linters, test runners and continuous integration, to make our life as developers easier. But maintaining configuration for these tools is far from easy, especially if you want up-to-date configs in all your projects. Mrm tries to solve this problem.
The only thing that many times was preventing me from extracting some generic function to a separate package is a need to copy and modify a dozen of config files — all that .somethingrcs — just to publish a 50-line function.
These support files are usually only slightly different in all your projects. For example, a .gitignore file has node_modules and editor artifacts that you want to share between all your projects, but some projects have extra lines there that you don’t want in other projects. We need a way to keep in sync the common parts but allow per-project customizations.
Template-based tools, like Yeoman, are good for initial project bootstrapping but don’t work well for updates: they would overwrite a file with a new version and you’ll lose your customizations.
Mrm takes a different approach. It works like codemods: instead of a template that would overwrite everything, you’re describing in code how to modify or create files to achieve the desired state of the file.
It has minimal required configuration: it’ll use values from the project itself or from the environment, like reading your name and email from your Git or npm configs.
Mrm has utilities to work with popular config file formats: JSON, YAML, INI and new line separated text files; install npm packages; and file operations.
This allows you to create smart tasks, so the result depends on your project needs.
Mrm has many tasks out of the box: Codecov, EditorConfig, ESLint, .gitignore, Jest, lint-staged, Prettier, semantic-release, React Styleguidist, stylelint, Travis CI, TypeScript, package.json, contributing guidelines, license and readme file. You can create your own task or combine multiple tasks using aliases.
If you have many projects with a similar stack or a big multi-repository project, Mrm may be a good way to manage their configuration and could save your time.
Start with default tasks and then write your own or create a preset for your project or organization.
The project is still young — let me know what you think in comments or GitHub issues.