vike-cli init
Scaffold the user-content directory with runnable examples in every folder, print the map, and never overwrite something you edited.
init creates <project>/user_data — the half of the project a program must never author — fills
every folder with runnable examples, and prints the map. Printing the map is not a flourish: the
answer to what is all this? arrives before you open a file manager, rather than after you go
looking for a README.
Flags
| flag | meaning |
|---|---|
--dir PATH | scaffold here instead of the resolved <project>/user_data |
--reset | restore the shipped examples that are missing or edited |
--dry-run | print what would change, write nothing |
-h, --help | the usage text, on stdout, exit 0 |
--reset and --dry-run are bare booleans and reject an inline value (--reset=yes is a usage
error). --dir takes both forms.
Re-running is the ordinary case
A new version ships new examples, so the default writes only what is absent. A file you edited is
never touched, never diffed and never backed up, because the command has no business having an
opinion about it. Each shipped file is reported as one of three actions — Created (was absent),
Restored (existed, differed, and --reset was given), or Kept (identical, or edited and
protected) — so the output is a record of what the command did, never a claim about what it
intended. An existing file that cannot be read is treated as different rather than as a failure:
the question being asked is "does this match the sample?", and a file that cannot be read is not the
sample.
--reset is narrow, and cannot reach a strategy you wrote
--reset overwrites the entries in crates/vike-cli/src/cmd/init/mod.rs's files table and nothing
else — that table is simultaneously the shipped set and the exhaustive list of what --reset can
possibly destroy. A strategy you authored is not in it, so no combination of flags here deletes your
work. What --reset can destroy is edits to a shipped example, which is exactly what it is for.
--dry-run performs every comparison and writes nothing, so its report is the report the real run
would produce.
Where it writes
--dir wins; otherwise the directory the dispatcher already resolved (VIKE_USER_DATA_DIR, else the
project walk). With neither, this is an error, not a fallback to the working directory —
scattering a user_data/ tree into whatever directory somebody happened to be standing in is not a
recoverable mistake, and --dir says what they meant in one word.
The command writes only under the resolved user_data/. It creates no file in settings/ and reads
no credential; crates/vike-model/src/state_path.rs's PROJECT_USER_DATA_DIR argues the split, and
the point of it is that a tool inviting people to drop files somewhere never operates in the
directory holding live venue keys.
The map
user_data/ your work — nothing here is ever overwritten once you have edited it
strategies/rhai/ interpreted strategies: edit, save, backtest. No toolchain needed.
strategies/rust/ compiled strategies. SOURCE CHECKOUT ONLY — a release binary cannot build them.
indicators/ your own indicators, one <name>.rhai each. Callable from any strategy.
profiles/ run profiles: which data, which costs, which strategy
backtest_results/ saved reports. One sample ships, so the notebooks work before your first run.
notebooks/ analysis over the results above
logs/ compile.log — every strategy load, pass and fail. Look here first.Every folder arrives populated, deliberately: a feature nobody can see is a feature nobody uses, and
an empty strategies/rhai/ reads as setup somebody abandoned. logs/ is the one exception — it ships
a README and no sample, because a sample log would be fiction. The Rhai folder ships three strategies
chosen one per shape (sma_cross, rsi_meanrev, ema_trend) rather than one per indicator,
since the host binds the whole catalog and three files could not sample it; each comes with its own
preset TOMLs. indicators/ ships donchian_high.rhai and streak.rhai, strategies/rust/ a
my_experiment template, profiles/ the backtest, sweep and walk-forward profiles, and
backtest_results/ one sample report so the notebook works before your first run.
What it prints next
The report ends with the sequence a new user actually needs, because init writes strategies and
profiles and writes no market data — the shipped profile names a slice an empty store does not
hold, which would otherwise be a run that completes with no trades and no explanation. So the report
names backtest --seed-demo for the synthetic demo tape, then --fetch-starter for a published
dataset that needs no venue, then --fetch binance:BTCUSDT:1h --days 180 straight from the venue.
The store is not seeded from this command on purpose: writing a history store needs DataFusion, and
this binary is DataFusion-free by construction.
Your indicators are installed before any verb runs
crates/vike-cli/src/lib.rs's install_user_indicators loads user_data/indicators/*.rhai and
installs them process-wide before dispatch, so a script run by any subcommand can call them. Every
rejected file is reported on stderr and a bad one never fails the command — one half-edited
indicator blocking every invocation, including the init that scaffolds the examples, would be
worse than the report.
See also
- Writing a strategy and writing an indicator
- Loading indicators — how the directory is scanned
vike-cli indicators— what a script can actually call- The
backtestbinary — what--seed-demoand--fetchbelong to
Set up
Scaffold a project, read its settings, hold its secrets, and attach a box to a running node — the four verbs you run before any of the others.
config
Two verbs over one settings directory: show discloses every setting and where its value came from, check judges the same tree and makes the exit code the product.