vike
Set up

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

flagmeaning
--dir PATHscaffold here instead of the resolved <project>/user_data
--resetrestore the shipped examples that are missing or edited
--dry-runprint what would change, write nothing
-h, --helpthe 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

On this page