So many configuration files Every company I've worked for had dozens of repositories written in the same tech stack (either due to a micro-services architecture, or just many different types of projects, think a few backend applications, a CLI app, an open source project, etc...). What repositories had in common was a project-level configuration that was the same. Some examples are: all of these almost A CI/CD configuration: 's , 's GitHub .github/workflows/... CircleCI .circleci/config.yaml An IDE configuration: 's or 's VSCode .vscode/ Intellij IDEA .idea/ A common linter/formatter configuration: , , , , ... .eslintrc .prettierrc .golangci.yaml .pylintrc scripts, , , package.json .github/dependabot.yaml .github/pull_request_template.md Makefile And the list goes on... Whenever I wanted to change such a configuration file, I had to open 10 or more pull requests in all of the different repositories, carefully copy-pasting the same changes, trying to stay focused (and sane) in the process to make sure I got everything changed correctly. If we wanted to make 5 changes in 5 configuration files across 10 repositories, that would require 250 changes to be made just to update a configuration change!!! Don't Repeat Yourself One of the first principles we learn as programmers is . Don't Repeat Yourself (DRY) So how come we let ourselves rewrite the same configuration again and again in all of our projects? Call me Sauron, but this drove me insane, and so I embarked on a quest to solve it. Existing solutions I'm not the first to tackle this problem and approach solving it. While looking for solutions, I found 2 interesting projects. Here are my opinionated thoughts on both of them: mrm A powerful tool that uses tasks written in javascript to intelligently maintain updates on shared config files. 👍🏼 Pros: Powerful Comes with predefined presets 👎🏼 Cons: Complex and implicit (I don't want to write code if I don't have to) Very oriented to the javascript ecosystem Doesn't support syncing multiple repositories simultaneously Doesn't support creating pull requests for the updates cruft A compatible tool that supports initializing and updating project boilerplate. Cookiecutter A is a tool that helps with creating new projects based on boilerplate templates. Cookie cutter 👍🏼 Pros: Builds on many good boilerplates (I personally don't like boilerplates, there usually isn't a one-size-fits-all and I like to get my hands dirty to make sure I understand the configuration) 👎🏼 Cons: Doesn't support syncing multiple repositories simultaneously Doesn't support creating pull requests for the updates Has to be based on a cookie-cutter template My requirements When starting to think about a solution that would fit my needs, I had a couple of requirements in mind: 🌵 Stay DRY - Write a configuration once, and have it synced across many projects. 🤤 - Treat configuration snippets as simple text, not assuming anything about structure. Keep It Simple Stupid (KISS) 🙆🏻‍♀️ Allow flexibility, but not too much - Allow syncing complete files, or parts of them (currently, line-based). 🤖 Automate all the things - After an initial configuration, I want the solution to handle the rest. Introducing Goplicate is a CLI tool that helps define common code or configuration snippets once and sync them to multiple projects. Goplicate It balances simplicity and flexibility by using comments to annotate blocks of configuration that we would like to sync. I've felt the 2 alternative solutions required too much of me to get started. Disclaimer: I'm the author of Goplicate Quick start in 4 simple steps In the following simplified example, we'll sync an configuration. eslint We'll end up having the following folder structure (full example ): here + shared-configs-repo/
+   .eslintrc.js
  repo-1/
    .eslintrc.js
+   .goplicate.yaml
  repo-2/
    .eslintrc.js
+   .goplicate.yaml
  ... Let's go! 1️⃣ Choose a config file that some of its contents are copied across multiple projects and add goplicate block comments for the section of your desire: common-rules : repo-1/.eslintrc.js module.exports = {
    "extends": "eslint:recommended",
    "rules": {
+       // goplicate-start:common-rules
        // enable additional rules
        "indent": ["error", 2],
        "linebreak-style": ["error", "unix"],
        "quotes": ["error", "double"],
        "semi": ["error", "always"],
+       // goplicate-end:common-rules

        // override configuration set by extending "eslint:recommended"
        "no-empty": "warn",
        "no-cond-assign": ["error", "always"],
    }
} 2️⃣ Create a separate, centralized repository to manage all of the shared config files. We'll name it . Then, add a file with the snippet that we want to sync: shared-configs-repo .eslintrc.js common-rules : shared-configs-repo/.eslint.js module.exports = {
     "rules": {
          // goplicate-start:common-rules
          // enable additional rules
          "indent": ["error", 4],
          "linebreak-style": ["error", "unix"],
          "quotes": ["error", "double"],
          "semi": ["error", "always"],
          // goplicate-end:common-rules
    }
} Goplicate snippets are simply the sections of the config file that we'd like to sync. In this example, we've also added the surrounding configuration to make it more readable, but it's not really needed. 3️⃣ Go back to the original project and create a file in your project root folder: .goplicate.yaml : repo-1/.goplicate.yaml targets:
  - path: .eslintrc.js
    source: ../shared-configs-repo/.eslintrc.js 4️⃣ Finally, run goplicate on the repository to sync any updates: This is only a simplified example. Let's see Goplicate's additional features. Other supported features A command to sync multiple repositories with a single command. goplicate sync Support for checking out a new git branch, committing the changes, and opening a GitHub pull request (assuming is installed and configured). GitHub CLI Template support using with dynamic parameters. Go Templates Support for automatically running post hooks to validate that the updates worked well before opening a pull request. Future Plans Support for syncing from a remote source (a GitHub repository, etc...) to incorporate as part of a CI flow. Support goplicating (😉) JSON files (they don't support comments so we'll have to do it another way). Adding a documentation website with quick start examples for various use cases. Adding CI integrations for the command to automate the opening of PRs for each update to the shared config repository. goplicate sync Your next suggested feature 😁. Goplicate is in the early stages of development - If you want to contribute, then feel free to open a PR or hit me up @ Ilai Fallach Conclusion If you're maintaining many different projects with similar config files or a single project with many such repositories, then try out - It literally takes 4 steps to integrate into your existing projects' setup! Goplicate What do you think about Goplicate? Leave a comment and share your feedback and thoughts 🙏 Want to connect? If  you liked this content, . consider signing up to my newsletter (it’s free) Originally published at https://buildstupidstuff.com

The One Config to Rule Them All

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Building Stupid Stuff

10 Indications That You Should Invest in Automation Via APIs

10 Commandments for AI-Assisted Social Media Marketers

11 Best Automation Testing Tools to Try in 2021

12 Use Cases of AI and Machine Learning In Finance

12 Ways You Can Use Email to Nurture Leads to Conversion

Building Stupid Stuff

10 Indications That You Should Invest in Automation Via APIs

10 Commandments for AI-Assisted Social Media Marketers

11 Best Automation Testing Tools to Try in 2021

12 Use Cases of AI and Machine Learning In Finance

12 Ways You Can Use Email to Nurture Leads to Conversion

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps