GitHub All Releases

ffizer is a files and folders initializer / generator. It creates or updates any kind (or part) of project from template(s).

keywords: file generator, project template, project scaffolding, quick start, project bootstrap, project skeleton

Features

Create or update files and folder from one (or several) template(s).
A native executable (cli)
- Install via download a standalone single file on system (no requirements like python, ruby, nodejs, java, …).
- Run as fast enough project generator.
- Run with dry mode (useful to test).
- Support self-upgrade.
A rust library
- Can be included into other tool
Templates Authoring
- Can be used for any file & folder generation (no specialization to one ecosystem).
- Can start as simple as a folder to copy “as is”.
- Can use the Handlebars template syntax for file content, extended with functions:
  - To transform strings (toUpperCase, toLowerCase, Capitalize,…)
  - To retrieve content via http get (like .gitignore from gitignore.io, license from spdx)
  - …
- Can replace variables part in file and folder’s name
- Can be composed of other templates (applied as layer)
- Can ignore file / folder under conditions
- Can store the content at the root of the folder or under the sub-folder template
Templates Hosting
- On a local folder
- On a hosted git repository (public / private, github / bitbucket/ gitlab / …)
  - At the root of the repository
  - In a sub-folder of the repository
  - In any revision (branch, tag, commit)

Suggestions are welcomes ;-)

A list of alternatives is available on the wiki, feel free to complete / correct.

Few templates

Any git repositories (in this case ffizer is like git clone ... && cd ... && rm -Rf .git)
Any local folder (in this case ffizer is like cp -R ... ...)
Parametrized (with variables) templates:
- ffizer/templates_default: the default collections of templates for ffizer (WIP)
- davidB31 / cg-starter-multi-rust · GitLab Project template for Multi-Bot in Rust on CodinGame.
- davidB/templates: repository to host the my collections of templates to used with ffizer.
- github repo tagged ffizer-template
- samples (used for test, demo) templates_default)
  - ffizer/template_sample: a simple template for ffizer used for demo and test
  - ffizer/tests/data at master · ffizer/ffizer

Build

cargo install cargo-make --force
cargo make ci-flow

Update CHANGELOG.md

cargo make update-changelog
git add CHANGELOG.md
git commit -m ':memo: (CHANGELOG) update'

Release a new version by bump patch (or minoror major)

cargo make publish patch # dry-run
cargo make publish --execute patch

Templates Authoring

The documentation is a Work In Progress, feel free to ask details, missing info or to submit content (via Pull Request).

Some templates

An empty dir, but it generates an empty dir ;-)
Any git repositories (in this case ffizer is like git clone ... && cd ... && rm -Rf .git)
Any local folder (in this case ffizer is like cp -R ... ...)
Parametrized (with variables) templates:
- ffizer/templates_default: the default collections of templates for ffizer (WIP)
- davidB31 / cg-starter-multi-rust · GitLab Project template for Multi-Bot in Rust on CodinGame.
- davidB/templates: repository to host the my collections of templates to used with ffizer.
- github repo tagged ffizer-template
- samples (used for test, demo) templates_default)
  - ffizer/template_sample: a simple template for ffizer used for demo and test
  - ffizer/tests/data at master · ffizer/ffizer

Tutorial: How to create a template for ffizer

Begin with a existing sample

Create the folder for the template by copying the existing folder (project) that you would like to generate with the future template.

cp -R my-existing-project my-template
cd my-template

If you don’t have an existing sample you can start with the following code, just to have something 😉.

mkdir my-template
cd my-template

cat >README.md <<EOF
Hello World
EOF

Clean the content of `my-templates` folder

remove files and folder that you don’t want to be part of the template
maybe add missing files and folder

At this point you have a valid template but it’s also a sample of what the template can produce. Use it to create a sample that can show a possible output, and a test to validate what ffizer + my-template can generate.

# create the folder for samples (the name of folder should be `.ffizer.samples.d`)
mkdir .ffizer.samples.d

# copy the current of my-template as a sample named `my-sample`
# except .ffizer.samples.d (its why we use `rsync` instead of `cp -R`)
rsync -rv --exclude=.ffizer.samples.d . .ffizer.samples.d/my-sample.expected

# test that ffizer is able to generate every samples under `.ffizer.samples.d`
# from `my-templates`
ffizer test-samples --source .

Enable git versionning

git init

A new folder .git was created and it should not be part of the template. To ignore this folder, you need to add a configuration for ffizer with this information.

cat >.ffizer.yaml <<EOF
ignores:
  - .git # exclude .git of the template host

EOF

An other alternatives would be to move the template, but not the sample under a template folder and to configure use_template_dir: true

Now you can test again, and commit.

ffizer test-samples --source .
git add .
git commit -m ":tada: initialize the template"

Publish on remote git repository

ffizer support templates hosted on local file system or on remote git repositories (accessible via ssh or https). To share your template you can create and push your local repository to your favorite host (github, gitlab, bitbucket,…) following the same workflow than for any git repository (instructions are provided by the hosting service).

# adapt the following parameters for your case
git remote add origin git@github.com:xxxx/my_template.git
git push -u origin main

# you can also test a remote template
ffizer test-samples --source git@github.com:xxxx/my_template.git

Parametrize the template with variables

The interest of a template is to be more than a cp -R, or a git clone. The first expected feature is to be able to render some parametrized content. ffizer renders only files with .ffizer.hbs as part of the filename (it could be at end or before final extension), the part .ffizer.hbs will be removed from the final name after rendering. Handlebars syntax is used for template string.

# adapt to your case
mv README.md README.ffizer.hbs.md
cat >README.ffizer.hbs.md <<EOF
Hello {{env_var "USERNAME"}}
EOF

At render time, the content between {{ and }} is evaluated, the sample bellow it call the function env_var with the parameter "USERNAME", this function is built-in into ffizer.

If you run the test, an error should be raised, because the rendered content doesn’t match the sample.

> ffizer test-samples --source .

Configure variables



Plan to execute

   - make dir        my-sample
   - add file         └─README.md
Nov 08 17:54:38.837 WARN check failed Differences: [
    EntryDiff {
        expect_base_path: "/home/david/tmp/my-template/.ffizer.samples.d/my-sample.expected",
        actual_base_path: "/tmp/.tmpROuSyU/my-sample",
        relative_path: "README.md",
        difference: StringContent {
            expect: "Hello World\n",
            actual: "Hello david\n",
        },
    },
], sample: my-sample, sub-cmd: test-samples
Nov 08 17:54:38.837 ERRO cmd: CliOpts {
    verbose: 0,
    cmd: TestSamples(
        TestSamplesOpts {
            src: SourceLoc {
                uri: SourceUri {
                    raw: ".",
                    path: ".",
                    host: None,
                },
                rev: "master",
                subfolder: None,
            },
            offline: false,
        },
    ),
}
Nov 08 17:54:38.837 ERRO failed: TestSamplesFailed

To fix this issue the better is to define a variable with a value that could be provided by the template user and with the default value define like previously.

cat >.ffizer.yaml <<EOF
variables:
  - name: author_name
    default_value: '{{ env_var "USERNAME" }}'

ignores:
  - .git # exclude .git of the template host

EOF

cat >README.ffizer.hbs.md <<EOF
Hello {{ author_name }}
EOF

At this point if we rerun the test, we will have the same result, because test run ffizer apply with the option --no-interaction that imply using the default value of a variable. So we need to modify the test to force the value of the variable like a user will do by providing a response to the interactive ask of the value for author_name or by using the option --variables.

# setup a configuration for the test sample `my-sample`
cat >.ffizer.samples.d/my-sample.cfg.yaml <<EOF
apply_args:
  - --variables
  - author_name=World

EOF

ffizer test-samples --source .

Test is back to OK, with your parametrized template.

File with .ffizer.hbs are not the only place where you can use handlebars rendering. It can also be used in file or foldername (see How to…) and into some part of the configuration file .ffizer.yaml (see Configuration).

Compose with an external template

To Avoid to duplicate content and configuration between template, you can import the content of one or several other templates into your template. In this tutorial, you will add a template that generate .gitignore files from .gitignore.io (now branded as part of topcal).

To that you should add a section imports:

cat >.ffizer.yaml <<EOF
variables:
  - name: author_name
    default_value: '{{ env_var "USERNAME" }}'

ignores:
  - .git # exclude .git of the template host

imports:
  - uri: "https://github.com/ffizer/templates_default.git"
    rev: "master"
    subfolder: "gitignore_io"

EOF

The gitignore_io template is not hosted at a root level the git repository so you should specify the subfolder (like from the options of ffizer apply).
The uri can in the format git@github.... or https://github.com/...

If you run ffizer test-samples --source ., you will have an error because the file .gitignore does not exist in the expected of my-sample. If you would like to see the generated file, the simplest way is to apply the template on a local folder (because test-samples remove files and folders created during the test). It is also the opportunity to try your template like a final user.

ffizer apply -s . -d ../my-template-t1

You can notice the following points:

the imported template ask for variable’s value
the ask is after your template’s variables
the ask is not the variable name but a sentence

because the .ffizer.yaml of the gitignore_io template includes

variables:
  - name: gitignore_what
    default_value: git,visualstudiocode
    ask: Create useful .gitignore (via gitignore.io) for

In this tutorial, you will override the default value of gitignore_what to be only git

cat >.ffizer.yaml <<EOF
variables:
  - name: author_name
    default_value: '{{ env_var "USERNAME" }}'
  - name: gitignore_what
    default_value: git
    ask: Create useful .gitignore (via gitignore.io) for

ignores:
  - .git # exclude .git of the template host

imports:
  - uri: "https://github.com/ffizer/templates_default.git"
    rev: "master"
    subfolder: "gitignore_io"

EOF

And you will also update the my-sample.expected.

ffizer apply -s . -d ../my-template-t2
cp ../my-template-t2/.gitignore .ffizer.samples.d/my-sample.expected
ffizer test-samples --source .

You can now remove the result of your previous manual run.

rm -Rf ../my-template-t*

It’s the end of this tutorial but I hope not the end of your journey with ffizer. Now you know the basics to create, to test, to parametrize and to publish a template. You can take a look to existing templates and you can continue to read the ffizer’s book, you could learn how to customize ask of value for variable, how to display selection, how to display a message, how to run command, how to read value of variable from existing file in the project,…

I forgot you can also continue to work with your current template:

publish / share the new revision of your template
add parameters
extract template from your template or other stuff
compose with other existing templates
improve the user experience on update
…

How to…

How to name a folder as a package name of the project ?

Define a package_name variable with a sensible value (eg snake case of the project name).

variables:
  - name: project_name
    default_value: "{{ file_name ffizer_dst_folder }}"
  - name: package_name
    default_value: "{{ to_snake_case project_name }}"

And use it as name of the folder.

mkdir 'src/{{ package_name }}`

How to display a message after files’generation ?

in .ffizer.yaml

scripts:
  - message: |
      Thanks for using my awesome template.

How to run a set of commands after files’generation ?

in .ffizer.yaml

scripts:
  - cmd: |
      {{#if (eq (env_var "OS") "windows") }}
      echo Hello {{ who }}> file2.txt
      del file_to_delete.txt
      {{else}}
      echo "Hello {{ who }}" > file2.txt
      rm file_to_delete.txt
      {{/if}}

Having several entries under scripts with cmd is allowed.
Empty cmd after template rendering are ignored.
Each cmd block is displayed to the user to confirm if (s)he accepts to run it or not.

How to import a sibling template ?

If your git repository host several templates, one template can import a sibling template by specifying the absolute value or by using built-in variables

imports:
  - uri: "{{ ffizer_src_uri }}"
    rev: "{{ ffizer_src_rev }}"
    subfolder: "template_2"

How to update existing json/yaml/toml content ?

How to retrieve value from existing json/yaml/toml content ?

How to made “ignore files” conditional ?

How to include a `.git` folder as part of the template ?

How to test my template ?

How to host template on github ?

Configuration

The configuration is:

optional
stored into a yaml file named .ffizer.yaml at the root of the template.
sections (top level entry) of the yaml are optionals

variables:
  - name: project
    default_value: my-project

ignores:
  - .git # exclude .git of the template host

Sections

variables

List the variables usable into the .ffizer.hbs template file. Variables are defined by:

name: (required) the name of the variable.
default_value: a suggested value, the value is a string and support hbs templating.
ask: the sentence use to prompt user to set the value of the variable.
hidden: the variable is not shown to the user, the value is set to default_value. Could be useful to cache shared (structured) value. (default to false)
select_in_values: for non-empty list, ask the user to select a value in the list. The list can be a regular yaml list or a string (evaluated as a yaml list of string). default_value could be combined to pre-select a value in the list. After selection a second variable with same name plus suffix __idx is set with the index of the selected value in the list.
```
        variables:
          - name: k2
            select_in_values:
              - vk21
              - vk22
          - name: k1
            select_in_values: [ "vk11", "vk12" ]
          - name: k3
            select_in_values: '[ "vk31", "vk32" ]'
          - name: k4
            select_in_values: '{{ do_stuff }}'
```

Variables definition are prompt in the order of the list, and with the prompt defined by ask (if defined, else name)

variables:
  - name: project_name
    default_value: "{{ file_name ffizer_dst_folder }}"

Every variables are mandatory, to allow empty value default_value should be an empty string.

  - name: foo
    default_value: ""

ignores

List patterns of file path (relative to root of the template) that should be ignored when search for file to be copied or rendered from the template into the destination.

To ignore .git folder from the template (useful for template hosted on root of a git repository)

ignores:
  - .git/*
  - .git # exclude .git of the template host

imports

It is possible to imports templates into a template. It is useful to reuse templates or to compose template from other template.

The imports section is a list of templates:

imports:
  - uri: "git@github.com:ffizer/templates_default.git"
    rev: "master"
    subfolder: "gitignore_io"

The order in the list define:

the order to ask variables (and to find variables definition): first the variable of the root template, then the variables of the first import, the second import,… then the variables of the first import of the first imports.
the order of files: first the file of the root template, then the files from the first import,… (same as variable)

The first variable definition found (following the order) is keep. So a higher level variables definition override the lower level. In the example below, the askand the default_value override the definition of gitignore_what into the imported template.

variables:
  - name: gitignore_what
    default_value: rust,git,visualstudiocode
    ask: Create useful .gitignore (via gitignore.io) for

imports:
  - uri: "git@github.com:ffizer/templates_default.git"
    rev: "master"
    subfolder: "gitignore_io"

use_template_dir

By default, content of the template is mixed with its optional metadata (.ffizer.yaml, …). So it means that if you have a README.md both as the template description and as template content (a README.md to generate), you have to follow this layout:

+- README.md.ffizer.hbs (or README.md.ffizer.raw)
+- README.md
+- .ffizer.yaml

And to add into .ffizer.yaml

ignores:
  - README.md

Or you can choose to move the template content under a template folder:

+- template
|  +- README.md.ffizer.hbs (or README.md)
+- README.md
+- .ffizer.yaml

And to add into .ffizer.yaml

use_template_dir: true

The Schema of .ffizer.yaml

The json schema of the .ffizer.yaml is defined in ffizer.schema.json. The schema could be used for validation and auto completion into your editor.

The schema is registered at JSON Schema Store.

The schema is also available via cli.

ffizer show-json-schema

The predefined variables

Some variables are predefined and they can be used into .ffizer.yaml into by example the imports section or default_value via handlebars expression.

variable	value of
`ffizer_dst_folder`	cli arg `--destination` as string
`ffizer_src_rev`	cli arg `--rev` as string (could be null)
`ffizer_src_uri`	cli arg `--source` as string
`ffizer_src_subfolder`	cli arg `--source-subfolder` as string (could be null)
`ffizer_version`	the current version of ffizer as string

The following sample combine a helper function file_name with ffizer_dst_folder.

variables:
  - name: project_name
    default_value: "{{ file_name ffizer_dst_folder }}"

Template Helpers / Functions

Helpers extend the template to generate or to transform content.

The helpers from handlebars_misc_helpers are included. This page is a copy of handlebars_misc_helpers/README.md at master · davidB/handlebars_misc_helpers, and it can be can be out-of-date.

Few helpers are included, but if you need more helpers, ask via an issue or a PR.

To use an helper:

// arguments are space separated
{{ helper_name arguments}}

To chain helpers, use parenthesis:

{{ to_upper_case (to_singular "Hello foo-bars") }}
// -> BAR

{{ first_non_empty (unquote (json_str_query "package.edition" (read_to_str "Cargo.toml") format="toml")) (env_var "MY_VERSION") "foo" }}
// -> 2018

see Handlebars templating language

String transformation

helper signature	usage sample	sample out
`replace s:String from:String to:String`	`replace "Hello old" "old" "new"`	`"Hello new"`
`to_lower_case s:String`	`to_lower_case "Hello foo-bars"`	`"hello foo-bars"`
`to_upper_case s:String`	`to_upper_case "Hello foo-bars"`	`"HELLO FOO-BARS"`
`to_camel_case s:String`	`to_camel_case "Hello foo-bars"`	`"helloFooBars"`
`to_pascal_case s:String`	`to_pascal_case "Hello foo-bars"`	`"HelloFooBars"`
`to_snake_case s:String`	`to_snake_case "Hello foo-bars"`	`"hello_foo_bars"`
`to_screaming_snake_case s:String`	`to_screaming_snake_case "Hello foo-bars"`	`"HELLO_FOO_BARS"`
`to_kebab_case s:String`	`to_kebab_case "Hello foo-bars"`	`"hello-foo-bars"`
`to_train_case s:String`	`to_train_case "Hello foo-bars"`	`"Hello-Foo-Bars"`
`to_sentence_case s:String`	`to_sentence_case "Hello foo-bars"`	`"Hello foo" bars`
`to_title_case s:String`	`to_title_case "Hello foo-bars"`	`"Hello Foo Bars"`
`to_class_case s:String`	`to_class_case "Hello foo-bars"`	`"HelloFooBar"`
`to_table_case s:String`	`to_table_case "Hello foo-bars"`	`"hello_foo_bars"`
`to_plural s:String`	`to_plural "Hello foo-bars"`	`"bars"`
`to_singular s:String`	`to_singular "Hello foo-bars"`	`"bar"`
`trim s:String`	`trim " foo "`	`"foo"`
`trim_start s:String`	`trim_start " foo "`	`"foo "`
`trim_end s:String`	`trim_end " foo "`	`" foo"`
`unquote s:String`	`unquote "\"foo\""`	`"foo"`
`enquote symbol:String s:String`	`enquote "" "foo"`	`"\"foo\""`
`first_non_empty s:String+`	`first_non_empty "" null "foo" "bar"`	`"foo"`

Http content

Helper able to render body response from an http request.

helper signature	usage sample
`http_get url:String`	`http_get "http://hello/..."`
`gitignore_io templates:String`	`gitignore_io "rust,visualstudiocode"`

Path extraction

Helper able to extract (or transform) path (defined as string).

for the same input: "/hello/bar/foo.txt"

helper_name	sample output
file_name	`"foo.txt"`
parent	`"/hello/bar"`
extension	`"txt"`

File

Helper to read file content.

usage	output
`{{ read_to_str "/foo/bar" }}`	content of file `/foo/bar`
`{{ read_to_str "file/does/not/exist" }}`	empty string

Environment variable

Helper able to get environment variables.

helper_name	usage
env_var	`env_var "HOME"`

Specials environment variables are predefined (some of them come from std::env::consts - Rust):

variable	possible values
`"ARCH"`	x86 x86_64 arm aarch64 mips mips64 powerpc powerpc64 s390x sparc64
`"DLL_EXTENSION"`	so dylib dll
`"DLL_PREFIX"`	lib "" (an empty string)
`"DLL_SUFFIX"`	.so .dylib .dll
`"EXE_EXTENSION"`	exe "" (an empty string)
`"EXE_SUFFIX"`	.exe .nexe .pexe "" (an empty string)
`"FAMILY"`	unix windows
`"OS"`	linux macos ios freebsd dragonfly netbsd openbsd solaris android windows
`"USERNAME"`	try to find the current username, in the order: environment variable `"USERNAME"` environment variable `"username"` environment variable `"USER"` environment variable `"user"`

JSON & YAML & TOML

Helpers

json_query query:String data:Json: Helper able to extract information from json using JMESPath syntax for query.
json_str_query query:String data:String: Helper able to extract information from json using JMESPath syntax for query, data follows the requested format.
json_to_str data:Json: convert a json data into a string following the requested format.
str_to_json data:String: convert(parse) a string into a json following the requested format.

The optional requested format, is the format of the string with data:

"json" (default if omitted)
"json_pretty" json with indentation,…
"yaml"
"toml"
"toml_pretty"

usage	output
`{{ json_query "foo" {} }}`	``
`{{ json_to_str ( json_query "foo" {"foo":{"bar":{"baz":true}}} ) }}`	`{"bar":{"baz":true}}`
`{{ json_to_str ( json_query "foo" (str_to_json "{\"foo\":{\"bar\":{\"baz\":true}}}" ) ) }}`	`{"bar":{"baz":true}}`
`{{ json_str_query "foo" "{\"foo\":{\"bar\":{\"baz\":true}}}" }}`	`{"bar":{"baz":true}}`
`{{ json_str_query "foo.bar.baz" "{\"foo\":{\"bar\":{\"baz\":true}}}" }}`	`true`
`{{ json_str_query "foo" "foo:\n bar:\n baz: true\n" format="yaml"}}`	`bar:\n baz: true\n`
`{{ json_to_str ( str_to_json "{\"foo\":{\"bar\":{\"baz\":true}}}" format="json") format="yaml"}}`	`foo:\n bar:\n baz: true\n`

Blocks

`{{#from_json format="toml"}} {"foo": {"hello":"1.2.3", "bar":{"baz":true} } } {{/from_json}}`	`[foo] hello = "1.2.3"` `[foo.bar] baz = true`
`{{#to_json format="toml"}} [foo] bar = { baz = true } hello = "1.2.3" {{/to_json}}`	`{ "foo": { "bar": { "baz": true }, "hello": "1.2.3" } }`
`{{#from_json format="toml"}} {"foo":{"bar":{"baz":true}}} {{/from_json}}`	`foo: bar: baz: true`
`{{#to_json format="yaml"}} foo: bar: baz: true {{/to_json}}`	`{ "foo": { "bar": { "baz": true } } }`

Note: YAML & TOML content are used as input and output format for json data. So capabilities are limited to what json support (eg. no date-time type like in TOML).

Edition via jsonnet

For more advanced edition of json, you can use jsonnet.

A data templating language for app and tool developers

See the doc of jsonnet for more samples, syntax info,…
This block can be combined with conversion helper/block for YAML & TOML to provide edition capabilities for those format
the output should a valid json, except if string_output = false is set as parameter of the block.

{{#jsonnet}}
local v = {"foo":{"bar":{"baz":false}}};
v {
  "foo" +: {
      "bar" +: {
          "baz2": true
      }
  }
}
{{/jsonnet}}

{
  "foo": {
      "bar": {
          "baz": false,
          "baz2": true
      }
  }
}

Assign

Helper able to assign (to set) a variable to use later in the template.

usage	output
`{{ assign "foo" "{}" }}`	``
`{{ assign "foo" "{}" }}{{ foo }}`	`{}`
`{{ assign "foo" "hello world" }}{{ foo }}`	`hello world`
`{{ assign "foo" {} }}{{ foo }}`	`[object]`
`{{ assign "foo" {"bar": 33} }}{{ foo }}`	`[object]`

IDE/Editor setup’ suggestions

Use your favorite IDE/Editor.

Editing `.ffizer.yaml`

add support for yaml files
if possible configure to use schemastore json to validate, to provide “auto completion” and tool tips
if your yaml plugin is not compatible with schemastore but it accepts json schema to validate yaml you can configure it to use the online schema
```
  "yaml.schemas": {
    ...
    "https://ffizer.github.io/ffizer/ffizer.schema.json": [".ffizer.yaml"],
  },
```
or to use a local file that can be generated by
```
ffizer show-json-schema
```

By example, for Visual Studio Code, you can use the following extension/plugin:

Name: YAML
Id: redhat.vscode-yaml
Description: YAML Language Support by Red Hat, with built-in Kubernetes syntax support
Publisher: redhat
VS Marketplace Link: https://open-vsx.org/vscode/item?itemName=redhat.vscode-yaml

Changelog

👽 update to use the clap 4 api
⬆️ Bump clap from 3.2.22 to 4.0.18
⬆️ Bump regex from 1.6.0 to 1.7.0
⬆️ Bump assert_cmd from 2.0.4 to 2.0.7
⬆️ Bump openssl from 0.10.42 to 0.10.44
⬆️ Bump serde from 1.0.145 to 1.0.151
⬆️ Bump serde_json from 1.0.85 to 1.0.89
⬆️ Bump libc from 0.2.134 to 0.2.137
⬆️ Bump serde_yaml from 0.9.13 to 0.9.14
⬆️ Bump tracing from 0.1.36 to 0.1.37
⬆️ Bump tracing-subscriber from 0.3.15 to 0.3.16
⬆️ Bump handlebars from 4.3.4 to 4.3.5
⬆️ Bump libc from 0.2.133 to 0.2.134
⬆️ Bump openssl from 0.10.41 to 0.10.42
⬆️ Bump console from 0.15.1 to 0.15.2
⬆️ Bump schemars from 0.8.10 to 0.8.11
⬆️ Bump thiserror from 1.0.36 to 1.0.37
⬆️ bump dependencies
⬆️ Bump libc from 0.2.132 to 0.2.133
⬆️ Bump self_update from 0.31.0 to 0.32.0
⬆️ Bump serde_yaml from 0.9.11 to 0.9.13
⬆️ Bump clap from 3.2.20 to 3.2.22
⬆️ Bump thiserror from 1.0.34 to 1.0.35

Fixed

🐛 use the value of CARGO_PKG_NAME at compile time for the cache