init-project-cli

CLI utility for creating new projects from templates

Usage

Basic

Most trivial variant is directly copy all content of template directory. As example, some basic project that can be used as template for future project:

templates/basic
├── first.txt
└── second.tx

Create copy of it is easy as this:

mkdir my-project
cd my-project
init-project-cli ~/templates/basic

After that it create copy aff all files:

my-project
├── first.txt
└── second.tx

Templating

The basic option is no better than using cp. In most cases, new projects require minor substitutions in the template files. These substitutions may depend on the environment in which the utility is running or on user input. Let's look at both options.

For template preprocessing, you need add .init-project.yaml to template directory:

templates/context
├── .init-project.yaml
└── context-info.json

.init-project.yaml content:

templates:
  - context-info.json

This describes that instead of direct copying content-info.json, preprocessing with minijinja should be used. content-info.json look like this:

{
  "project_directory_name": "{{ context.project_directory_name }}",
  "project_directory_path": "{{ context.project_directory_path }}",
  "current_date": "{{ context.current_date }}",
  "current_time": "{{ context.current_time }}",
  "git_user_name": "{{ context.git_user_name }}",
  "git_user_email": "{{ context.git_user_email }}"
}

Creating new project is the same as basic variant:

mkdir my-project
cd my-project
init-project-cli ~/templates/context

As result my-project contains single file context-info.json (.init-project.yaml automatically ignored):

my-project
└── context-info.json

context-info.json content after preprocessing:

{
  "project_directory_name": "my-project",
  "project_directory_path": "/home/test/projects/my-project",
  "current_date": "2025-03-03",
  "current_time": "15:00",
  "git_user_name": "test",
  "git_user_email": "test@example.com"
}

Let's look on some other example with user defined parameters:

templates/parameters
├── .init-project.yaml
└── custom-parameters.json

.init-project.yaml contains additional parameters field:

templates:
  - custom-parameters.json

parameters:
  project_name:
    description: "Project Name"
    default: "{{ context.project_directory_name }}"
  version:
    description: "Project Version"
    default: "0.1.0"

And custom-parameters use it simple as is:

{
  "project_name": "{{ project_name }}",
  "version": "{{ version }}"
}

Next project initialization ask to user specific parameters:

mkdir my-project
cd my-project
init-project-cli ~/templates/parameters
# Project Name (default my-project): my-project
# Version (default 0.1.0): 0.1.0

After that custom-parameters contains user inputs:

{
  "project_name": "my-project",
  "version": "0.1.0"
}

Installation

cargo (stable)

cargo install init-project-cli

cargo (dev)

# make sure you have pkg-config
cargo install --git https://github.com/sysraccoon/init-project-cli.git

nix (dev)

nix profile install github:sysraccoon/init-project-cli

Change log

[0.1.1] 2025-12-21

• New flag --no-check-dir to allow project initialization in non-empty directories. When specified, the tool skips the default empty directory verification
• New parameter --on-conflict to control file conflict resolution strategy. This parameter accepts the following values:
  • abort (default) - stops the entire initialization process when any file conflict is detected
  • skip - skips existing files, only creating missing ones
  • overwrite - replaces existing files with template files of the same name
• Combined usage - the --on-conflict parameter is designed to work in conjunction with --no-check-dir for fine-grained control over file management in populated directories

[0.1.0] 2025-03-06

• Template configuration via .new-project.yaml file supporting:
  • File inclusion/exclusion patterns
  • Static file copying (direct file system copy)
  • Template processing using minijinja templating engine