Creations
A Creation object is what’s returned by each Block’s produce()
method.
It may contain any of the following properties:
- “Direct” creations that always cause changes to the repository:
- “Indirect” creations only made to be used by later blocks:
addons
: Composed Addons to merge in for other Blocks, if they existsuggestions
: Tips for the next steps to take
For example, a Block that adds pnpm package deduplication might choose to both run a script (scripts
) used in a GitHub Actions job in Addons to another Block:
Direct Creations
These Creation properties always cause changes to the output repository.
files
Files to create or modify on disk.
This is the primary, most common output from blocks.
Each object under files
describes a folder of files.
Properties whose values are strings are written as files on disk.
Properties whose values are objects represent a directory.
For example, this Block that generates a .github/CODE_OF_CONDUCT.md
file:
That would instruct the create
engine to create a .github/
directory if it doesn’t exist yet, then create a .github/CODE_OF_CONDUCT.md
file.
File Creations
Each property in a files
object may be one of the following:
false
orundefined
: Ignoredobject
: A directory, whose properties recursively are file creationsstring
: A file to be created[string, CreatedFileOptions]
: A file to be created withfsPromises.writeFile
options:mode
: Integer mode, such as0o777
to make executable
For example, this Block generates an executable .husky/pre-commit
file:
requests
Network requests to send after files are created.
This can be useful when repository settings or other APIs are necessary to align the created repository to what Blocks have produced.
Each request may be specified as an object with:
id
(string
): Unique ID to know how to deduplicate previous creations during mergingsend
(function): Asynchronous method that sends the request, which receives an object parameter containing:fetch
: Equivalent to the globalfetch
octokit
: GitHub Octokit that uses thefetch
internally
For example, this Block sets a GitHub repository’s default branch to main
:
scripts
Terminal commands to run after files are created.
This can be useful when shell scripts are necessary to apply changes to the repository to align the created repository to what Blocks have produced.
Each script may be specified as either a string or an object with:
commands
(string[]
): Shell scripts to run within the phase, in orderphase
(number
): What order, relative to any other command groups, to run in
Commands provided as strings are assumed to not be order-dependent. They are run all at the same time.
For example, this Block runs pnpm package installation:
For example, this Block runs pnpm package installation and duplication in series within a first phase:
A Prettier block might opt to run formatting in a subsequent phase, once any dependencies are done resolving:
Those two Blocks with phase-dependent script commands together would run the following commands in order:
pnpm install
pnpm dedupe
pnpm format --write
If multiple command groups specify the same phase
, then they will start executing their scripts at the same time.
The next phase will not be started until all scripts in that phase complete.
For example, given the following production of scripts:
Those commands would be run in the following order:
a
b
c
ande
d
(afterc
completes)f
(aftere
completes)
g
(afterd
andf
complete)
Indirect Creations
These Creation properties produce information meant to be used by subsequent Blocks.
See Context for how Blocks can read context from previous Blocks.
addons
Additional Addons to merge in for other Blocks, if those Blocks exist.
Blocks may specify additions to other, “downstream” Blocks. If the downstream Block is included in the running Preset, then the augmenting Addons will be merged into what that downstream Block receives.
For example, this blockESLintJSDoc
Block tells blockESLint
about using the ESLint plugin for JSONC files:
If blockESLint
is run in the same Preset, then it will receive those additional Addons.
suggestions
Tips for the next steps to take.
Some Blocks require additional setup that users will have to take action on.
These will be logged to users after running npx create
.
For example, this blockNpmPublish
Block directs the user to create an automation token: