npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2025 – Pkg Stats / Ryan Hefner

replicante

v1.3.0

Published

Replicante CLI: every project can be a template for a new one

Downloads

37

Readme

Replicante

License tests npm npm

Replicante is a project template processor, completely agnostic of technology stack. It can process any software project as a template for a new one, just with a little configuration.

The process is pretty straight forward. Replicante copies the application and applies some transformation rules to the source files and file tree structure.

Quick Tutorial

First thing, run npm install -g replicante to install replicante CLI globally.

You can also install it using Yarn by running yarn global add replicante.

Study case - a quick tutorial

Let's get to an example, and assume we are a freelancer. We've made a wonderful job for our last client, and a new job requires us to build a new site, very much like the last.

But our source folders contain the name of the last client, and it also appears in almost every file as an organizing namespace or package. So we will have to rename some folders and files, and apply some search and replace operations. But this is an error prone process, and must be a better way to do this operation.

Replicante makes this very easy. The only thing you must do is to identify what terms (or words) you want replaced, and add them to a simple recipe JSON file, as the following:

{
  "replicantName": "NewSuperProject",
  "fileNameReplacements": [
    { "from": "OldClientName", "to": "NewClientName" },
    { "from": "oldClientName", "to": "newClientName" } // it is case-sensitive
    // ... any other replacement your project needs
  ],
  "sourceCodeReplacements": [
    { "from": "OldClientName", "to": "NewClientName" },
    { "from": "oldClientName", "to": "newClientName" } // it is case-sensitive
    { "from": "some-other-term", "to": "new-term" }
    // ... any other replacement your project needs
  ]
}

This file is called a replication recipe, and it contains some important information:

  • The name of the "replicant" (the new project)
  • The list of replacements to apply to names of folders and files
  • The list of replacements to apply to the files' contents

It goes like this:

Replication workflow

With this recipe in hands, you just tell Replicante to do the job using the create command:

replicante create ./path-to-the-old-project ./path-to-the-recipe-above

By default, the new project will be created inside the folder <USER_HOME>/.replicante/<replicant-name> the your user folder, and the path is printed in the terminal at the end of the process.

You can override the path where the new project should be create with the --target parameter:

replicante create ./path-to-the-old-project ./path-to-the-recipe-above --target=./path-to-create-new-project

Advanced features

Replicante also allows you to further customize the replication behaviour. It does so through some features that we'll explore in the following sections.

Ignoring folders and files

When creating your new project, you probably will need to ignore some special folders, like .git or binaries.

You can do this by adding an ignoreArtifacts array to the recipe:

{
  "replicantName": "NewProjectName",
  "fileNameReplacements": [],
  "sourceCodeReplacements": [],
  "ignoreArtifacts": [".git", ".idea", "bin", "obj", "somefile.dll"]
}

Custom Variables

You can define custom variables to use in the replacements, and Replicante will automatically generate useful variations for you.

For example, you can define a custom variable named myVariable as follow:

{
  "replicantName": "NewProjectName",
  "customVariables": [
    { 
      "name": "myVariable",
      "value": "BigValue"
    }
  ],
  "fileNameReplacements": [],
  "sourceCodeReplacements": []
}

And then, Replicante will create the following variables that you can use in your recipes:

  • <<: myVariable :>> has the exact same value that you defined (e.g. BigValue)
  • <<: myVariable.toLowerCase() :>> has this name converted to lower case (e.g. bigvalue)
  • <<: myVariable.toUpperCase() :>> has this name converted to upper case (e.g. BIGVALUE)
  • <<: myVariable.toLowerDasherized() :>> has the name converted to lower case and separated by hyphens (e.g. big-value)
  • <<: myVariable.toUpperDasherized() :>> has the name converted to upper case and separated by hyphens (e.g. BIG-VALUE)
  • <<: myVariable.toLowerUnderscored() :>> has the name converted to lower case and separated by underscores (e.g. big_value)
  • <<: myVariable.toUpperUnderscored() :>> has the name converted to upper case and separated by underscores (e.g. BIG_VALUE)

Underscored

Following, you can see examples of all these variations:

{
  "replicantName": "BigProject",
  "customVariables": [
    { 
      "name": "myVariable",
      "value": "BigValue"
    }
  ],
  "fileNameReplacements": [
    { "from": "Sample", "to": "<<: myVariable :>>" }
    // ... any other replacement your project needs
  ],
  "sourceCodeReplacements": [
    { "from": "oldValue", "to": "<<: myVariable.toLowerCase() :>>" },
    { "from": "OLDVALUE", "to": "<<: myVariable.toUpperCase() :>>" },
    { "from": "old-value", "to": "<<: myVariable.toLowerDasherized() :>>" },
    { "from": "OLD-VALUE", "to": "<<: myVariable.toUpperDasherized() :>>" },
    { "from": "old_value", "to": "<<: myVariable.toLowerUnderscored() :>>" },
    { "from": "OLD_VALUE", "to": "<<: myVariable.toUpperUnderscored() :>>" }
    // ... any other replacement your project needs
  ]
}

And why not simply hard-code these values? You definitively can, but there are use cases where they come in handy. One such case is when the recipe is dinamically built by some other tool in a continuous integration pipeline.

Default variables

Even if you don't actually inform any custom variables, Replicante automatically creates one for you: replicantName and all its variations are available out of the box:

{
  "replicantName": "NewProjectModel",
  "fileNameReplacements": [
    { "from": "Sample", "to": "<<: replicantName :>>" }
    // ... any other replacement your project needs
  ],
  "sourceCodeReplacements": [
    { "from": "Sample", "to": "<<: replicantName :>>" }, 
    { "from": "sample", "to": "<<: replicantName.toLowerCase() :>>" }, 
    { "from": "SAMPLE", "to": "<<: replicantName.toUpperCase() :>>" }
    // ... any other replacement your project needs
  ]
}

Custom delimiters for variables

The default delimiters used for these variables are <<: and :>>. This is to prevent messing you real template files inside projects.

If you run into some problems with this kind of files, you can always customize de delimiters by adding the customDelimiters property. It should always contain a pair of delimiters, responsible for identifying the start and end of a variable:

{
  "replicantName": "NewProjectName",
  "fileNameReplacements": [],
  "sourceCodeReplacements": [],
  "customDelimiters": ["<<!", "!>>"]
}

Process Overview

If you are interested in the inner workings of this tool, you can always inspect the source files, but following is a brief summary of the overall process.

Replication workflow

NodeJS Compatibility

From version 1.0 onwards, Replicante supports Node 14+.

Roadmap

Our roadmap is publicly avaiable in a Trello board. Feel free to comment and suggest new features.