Baker – language-agnostic project scaffolder with hooks (Rust)

• Architecture Overview
• Installation
• Project template example
  • baker.yaml File
  • Files with .baker.j2 extension
  • Templated File Names
  • .bakerignore File
  • Importing Jinja templates and macros
  • Loop Templates and Delimiters
• Recipes
  • Passing Default Answers
  • Non-Interactive Mode
  • Conditional Questions
  • Debugging Templates
• Hooks
  • Customizing Hook Filenames
  • Customizing Hook Runners
  • Available Platform Variables
• Questions
  • Single-Input
  • Yes / No
  • Single Choice
  • Multiple Choice
  • JSON Complex Type
  • YAML Complex Type
  • Validation
    • Required Field Validation
    • Numeric Value Validation
    • Pattern Matching with Regular Expressions
  • Conditional questions
• Built-in Filters
• Comparing Baker to other project generators
• Community Templates

Looking for an end-to-end view of the codebase? See docs/architecture.md for a tour of the CLI runner, configuration loader, prompt layer, template processor, and supporting modules.

You can install Baker using one of the following methods:

Prebuilt binaries for all supported platforms are available on the releases page.

To get started, you can use the examples/demo template, which demonstrates the core features of Baker:

Note: By default Baker preserves symbolic links. To copy the contents the link points to (dereference), set follow_symlinks: true in baker.yaml:

If a symlink points to a file it will be duplicated as a regular file. Symlinks to directories are currently recreated as symlinks (not recursively copied).

As a quick start, you can run the following command to generate a project:

Each component of this template is described in detail below.

The baker.yaml file defines the directory as a template. It contains template settings and questions to be prompted to the user:

The values of the help and default keys can include templates for value substitution. Each subsequent question has access to the answers of the previous ones as demonstrated in project_author and project_slug.

In addition to YAML, Baker also supports JSON due to its backward compatibility with JSON. If multiple configuration files exist in the template directory, Baker will load them in the following order of priority: baker.json, baker.yaml, and baker.yml.

The content of files with the .baker.j2 extension will be processed by the templating engine and written to the target directory. The resulting files in the target directory will not include the .baker.j2 extension in their names.

The content of such files can include the questions keys, which will be replaced by the corresponding user-provided answers during processing. Baker uses the MiniJinja this purpose. For more details on the syntax and capabilities of the templating engine, please refer to the MiniJinja documentation.

Example:

Content of CONTRIBUTING.md.baker.j2

Processed file in target directory: CONTRIBUTING.md

Note: The template suffix (default: .baker.j2) is fully configurable in your baker.yaml file using the template_suffix option. You can set it to any value, as long as it starts with a . and has at least one character after the dot (e.g., .tpl, .jinja, .tmpl). This allows you to use custom extensions for your template files.

Example:

With this configuration, files ending with .tpl will be processed as templates instead of .baker.j2.

File and directory names can be templated to dynamically adjust based on user input.

Example:

This will create a directory named according to the value of the project_slug provided by the user.

File and directory names can include conditions that control their creation. If a condition evaluates to false, the corresponding file or directory will not be created. This feature is especially useful with Yes / No type questions, allowing you to dynamically include or exclude specific files and directories based on user responses.

Example:

In this example, if the user answers "no" the tests directory will not be created.

The .bakerignore file in the template root is used to exclude files and directories from being copied from the template. Bakerignore uses Globset syntax.

By default, Baker ignores the following files and patterns:

You can specify multiple patterns for files to be included in the template engine. Then you can include templates or import macros in your templates.

This will include all files ending with .tpl and .jinja in the template engine, allowing you to use them in your templates.

Baker supports loop templates using MiniJinja for-loop blocks in template filenames. This allows you to generate multiple files based on a list of items in your answers.

For example, a template file named:

will generate a file for each item in the items array, with the filename rendered from item.name.

When rendering loop templates, Baker uses two configuration options to split and organize the generated content:

• loop_separator: A string used to separate each file's content in the rendered output. This allows Baker to distinguish between multiple files generated from a single loop template. Default value is <--SPLIT-->.
• loop_content_separator: A string used to separate the filename from the file content within each split section. This enables Baker to extract the correct filename and its corresponding content. Default value is <<CONTENT>>.

Example Usage:

Suppose your template renders the following output:

Here, <<CONTENT>> is the loop_content_separator and <--SPLIT--> is the loop_separator. Baker will split the output on <--SPLIT-->, then split each part on <<CONTENT>> to get the filename and content for each file.

You can configure these separators in your Baker settings or pass them to the processor:

This mechanism allows flexible generation of multiple files from a single template, especially useful for code generation, documentation, or any batch file creation scenario.

Passing default answers can be useful when the answers are already known, such as in a CI/CD pipeline.

Default answers can be provided using the --answers option.

Example

The provided answer will be used as the default in the user prompt:

For fully automated workflows like CI/CD pipelines, you can combine --answers with the --non-interactive flag to completely skip all prompts:

In --non-interactive mode, Baker determines whether to skip user prompts based on two factors:

1. The --non-interactive flag itself
2. The template's ask_if conditions (if defined)

When a prompt is skipped, Baker uses the following strategy to determine the answer:

1. If an answer was already provided via the --answers parameter, use that value
2. If a default value (default) exists in the template configuration, use that
3. If neither exists, Baker will still prompt the user interactively for that question

For example, if your template contains:

And you run:

Baker will automatically use "Example" for project_name, "Anonymous" for project_author (from the default value), and true for use_tests (from the default value).

This is especially useful for CI/CD environments where interactive input isn't possible.

To skip the prompt entirely, you can use the ask_if attribute:

A detailed description of the ask_if key can be found in the Conditional Questions section.

Since Baker uses MiniJinja, it benefits from all MiniJinja features, including debugging. You can use the debug() function to inspect the current context.

Example

When you run the template, the debug() function will output the current context:

This output provides a detailed view of the current context, including defined variables, their values, and available functions, helping you troubleshoot and debug your templates effectively.

Hooks are useful for performing routine tasks before (pre-hook) or after (post-hook) project generation.

Baker executes hooks as separate processes, which makes them language-independent.

For a hook to be executed, it must meet two requirements:

1. It must be located in the template directory template_root/hooks/ and named according to the pre_hook_filename or post_hook_filename specified in the configuration.
2. It must be an executable file (chmod +x template_root/hooks/<hook_filename>).

When generating a project containing a hook, Baker will issue a warning:

This warning can be omitted by using the --skip-confirms=hooks parameter.

The pre hook can generate answers and pass them to baker through stdout:

The post hook can consume the answers, which will be passed by baker to the stdin of the post hook. The answers can be parsed as follows:

The diagram below illustrates this process in more detail

By default, Baker looks for hook scripts named pre and post in the hooks directory of your template. You can customize these filenames using the pre_hook_filename and post_hook_filename configuration options in your baker.yaml file:

With this configuration, Baker will:

1. Look for a pre-hook script at template_root/hooks/setup-environment
2. Look for a post-hook script at template_root/hooks/finalize-project

Hook filenames also support template strings, which can be used to create platform-specific hooks:

This configuration allows you to organize hooks by platform. For example:

Baker will automatically select the appropriate hook based on the current platform.

You can declare how Baker should execute hook scripts by specifying a runner for each hook. Runners are defined as arrays of strings (similar to Docker's ENTRYPOINT syntax), allowing you to include the command and its arguments.

• If a runner is provided, Baker runs the hook using the supplied command and passes the rendered hook path as the final argument.
• If omitted (default), Baker executes the hook path directly, matching the existing behaviour on Unix systems with executable scripts.
• Runner tokens are rendered through the template engine, so you can use variables from baker.yaml if needed.

This feature is especially helpful on Windows where scripts such as .ps1 cannot be launched directly, and on Unix when you want to force a specific interpreter (e.g., Python, Node.js, Bash).

Baker provides these platform variables that can be used in templates and hook filenames:

• platform.os - Operating system name (e.g., "linux", "macos", "windows")
• platform.family - OS family (e.g., "unix", "windows")
• platform.arch - CPU architecture (e.g., "x86_64", "aarch64")

You can use these variables in any template, including hook filenames, questions, help text, defaults, etc.

Baker supports various question components, which are described below.

Single Input prompts the user to enter a text value.

• type: Must be str.
• help: Should be a string, optionally containing a minijinja template.
• default: Should be a string, optionally containing a minijinja template.

• type: Must be bool.
• help: Should be a string, optionally containing a minijinja template.
• default: Should be a boolean value, defaulting to false.

• type: Must be str.
• help: Should be a string, optionally containing a minijinja template.
• choices: Should be a list of strings.
• default: Should be a string, optionally containing a minijinja template.

• type: Must be str.
• help: Should be a string, optionally containing a minijinja template.
• multiselect: Must be true to enable multiple choice.
• default: Should be a list of strings.
• choices: Should be a list of strings.

The JSON type allows you to collect structured data from the user in JSON format. This is useful for configuration files, environment settings, and other structured data.

• type: Must be json.
• help: Should be a string, optionally containing a minijinja template.
• schema: Optional JSON Schema for validation. Follows the JSON Schema standard.
• default: JSON object, can be provided as a string or native YAML object.

When prompted for JSON input, the user is given multiple options:

1. Open in external text editor
2. Enter multi-line input in console

JSON data can be accessed in templates like any other nested structure:

The YAML type works similarly to the JSON type but uses YAML syntax, which is more readable and less verbose.

• type: Must be yaml.
• help: Should be a string, optionally containing a minijinja template.
• schema: Optional JSON Schema for validation (same format as for JSON type).
• default: YAML data, can be provided as a string or native YAML object.

Similar to JSON input, the user is prompted to choose an input method. YAML is particularly useful for configuration data due to its readability:

Template usage:

Baker supports answer validation using the validation attribute. The condition attribute uses MiniJinja's expression language to validate user input, while error_message provides feedback when validation fails.

Ensure a field is not empty:

Check if a numeric value meets certain criteria:

The error message can include template variables to provide context about the invalid input.

Complex validation combining regex pattern matching with numeric validation and detailed error messages:

This example demonstrates:

1. Required field validation using age
2. Pattern matching using regex('[0-9]') to ensure numeric input
3. Numeric value validation ensuring age is at least 18
4. Conditional error messages that provide specific feedback based on the validation failure

If validation fails, Baker will:

1. Display the appropriate error message
2. Clear the invalid answer
3. Prompt the user to try again

The ask_if attribute is used to control the display of a question, using expression language from MiniJinja. It enables conditional logic to determine whether a question should be prompted based on user input or other contextual factors. In the following example, the py_framework question is only prompted if the user selects Python as the programming language in the language question:

Baker provides a set of built-in filters and functions to enhance the flexibility of your templates. These are powered by the MiniJinja templating engine and additional custom filters.

This comparison was made based on available documentation. If you notice any inaccuracies or outdated information, please create an issue — I'll be happy to update the table accordingly.

See here for a list of community maintained templates built with baker.