Where Does Changie Store Config and Fragments?
Changie keeps kind and format rules in .changie.yaml, with pending fragments in .changes/ and output in CHANGELOG.md.
Last updated
Changie separates config from content. .changie.yaml defines change kinds (with auto bump levels), formats and paths; the .changes/ directory collects one fragment file per change until batch assembles a release.
That fragment-per-change design is the whole point: contributors add files without touching a shared changelog, so concurrent PRs never conflict. The bot that files fragments for dependency PRs leans on exactly this property.
Where Changie stores this, by platform
[RepoDir]\.changie.yaml
Kinds, formats, changesDir, header and changelog paths. Fragments live in .changes/ (unreleased/ inside); batch consumes them into CHANGELOG.md.
[RepoDir]/.changie.yaml
Same layout. Custom fields (like issue numbers) extend fragments; replacements blocks can bump versions inside package.json on release.
[RepoDir]/.changie.yaml
Same files. Keep .changie.yaml committed and let fragments churn; the config is the contract, fragments are the queue.
Frequently asked questions
How do I set up Changie in a repo?
Run changie init. It writes .changie.yaml plus the changes dir, header template and an empty changelog, matching Keep a Changelog and semver defaults.
Can releases run without hand-editing the changelog?
Yes: changie batch auto bumps from kind rules, then changie merge folds the version into CHANGELOG.md. Fragments stay out of merge conflicts because each change is its own file.
Notice an outdated path? Let us know.