Bob is a tool used to generate boilerplate code.
It was first made to avoid loosing too much time writing redundant code and allow developers to focus and dedicate more time on interesting parts of their projects.
The main idea is to write boilerplate once for all and let bob do the code generation for you.
Though, even if boilerplate represents redundant code, it could be slightly different from one file to another. Variables can change, blocks of code can exist in one but not in the other, this kind of things.
This is why Bob addresses this issue by using a particular syntax called Actions
to perform some modifications from your template to your final code.
Download the latest release, unzip and put the binary somewhere on your PATH.
- golang 1.13.x or later
$> go get -u github.com/jcalmat/bob
$> bob
OR
$> git clone git@github.com:jcalmat/bob.git
$> make install
$> bob
Bob is asking you to do 2 things in order to work:
- Create template(s) of code
- Registering those templates to a config file written in yaml or json in your root directory. This file shall be named .bobconfig.yaml/.bobconfig.yml/.bobconfig.json
To generate your first config file, run bob
and select Init
.
A bobconfig file looks like this:
commands:
test:
description: "what this command will do"
path: "/path/to/example.js"
#OR
git: "git@github.com/username/my-template.git"
vars:
- name: "my_variable"
type: "string"
ask: "Override the question Bob will ask in order to replace this value"
# If you need to clone your template from a private git repository
# please provide a ssh key here
config:
git:
ssh:
privateKeyFile: # your private ssh key, ex: "/home/user/.ssh/id_rsa"
privateKeyPassword: "" # password of this key if needed
bobconfig files are splitted into 1 required category + 1 optional one.
Commands represents all the commands that will register to bob in order to clone a template. It contains the path (local or remote with git) of your template and all the vars
you want to replace.
Actions can be a variable you want to replace, a boolean value representing the fact that a block of code will be in the final code or not, this kind of things. Actions are blocks that contain the following fields:
- name: the name of your action in the template
- type: the type of your variable. In can be one of
string
orbool
. Basically a string will be displayed as an input field and a bool will be displayed as a checkbox - format: allows you to override the question bob will ask to you in order to replace the action
Exemple:
The config file:
vars:
- name: "use_database"
type: "bool"
format: "Do you want to use a database?"
Your template:
{{if .use_database}}
// init your db, perform operations, etc
{{end}}
Config allows you to input a ssh key (+ password if needed) to clone projects from a private repository.
If you don't want to bloat your main bobconfig file, you can embed part of it directly in your template.
Ex:
# ~/.bobconfig.yaml
commands:
example:
path: "/path/to/my/template"
# /path/to/my/template/.bobconfig.yaml
vars:
- name: "my_variable"
type: "string"
skip:
- ".bobconfig.yml" #this is recommended to avoid having the bobconfig file in your final code
Bob uses the go templates
syntax to parse and replace variables, here is what go template documentation can say about it:
The input text for a template is UTF-8-encoded text in any format.
"Actions"--data evaluations or control structures--are delimited by "{{" and "}}"; all text outside actions is copied to the output unchanged. Except for raw strings, actions may not span newlines, although comments can.
For more information about the format, here is a cheat sheet.
If it doesn't make a lot of sense at first glance, it will quickly, don't worry.
Given the file example.js
with the following line of code:
var {{.my_variable}}
Given the following .bobconfig.yaml
:
commands:
test:
path: "/path/to/example.js"
actions:
- name: "my_variable"
type: "string"
When you run bob, it will automatically offer you to replace "my_variable" by any string and ask you where to put your newly created boiler file.
Since bob uses go template to perform the variable replacement, it has some interesting specificities. You can, for instance, perform conditional operations.
Ex:
{{if .my_variable}}
// do something only if .my_variable is defined
{{end}}
Bob also ships with homemade functions to ease string formatting
{{short .my_variable [X]}}
will only keep the X first characters of your variable{{upcase .my_variable}}
will capitalize your variable{{title .my_variable}}
will return a copy of the string s with all Unicode letters that begin words mapped to their Unicode title case
Ex:
{{title .my_variable}}
// .my_variable = test -> Test
{{short .my_variable 1}}
// .my_variable = test -> t
{{upcase .my_variable}}
// .my_variable = test -> TEST
You can even combine multiple functions.
Ex:
{{short .my_variable 3 | upcase}}
// my_variable = test -> TES
Once again, if you want to know what you can do, check out the cheat sheet.
Here is a small demo with one of my templates: creation of an entire compilable microservice.