WindowsmacOSLinux

Where Does semantic-release Store Its Config?

semantic-release reads .releaserc, release.config.js, or the release key in package.json, with CLI flags winning.

Last updated

semantic-release accepts three config homes: a .releaserc file (yaml, json, js and friends), a release.config.js module, or a release key inside package.json. All three carry branches, plugins and tag format.

CLI flags beat files, files beat shareable configs, and plugin blocks cannot come from flags at all. Branches default wide (main, next, semver ranges), so an unexpected release usually means the defaults fired, not a bug.

Where semantic-release stores this, by platform

Windows
[RepoDir]\.releaserc

Branches, plugins, tagFormat. Plugin option objects only work here, never as CLI flags. extends pulls in shareable presets underneath local values.

macOS
[RepoDir]/.releaserc

Same candidates. release.config.js suits logic (computed branches); static setups read cleaner as .releaserc.json.

Linux
[RepoDir]/.releaserc

Same layout. Default branches include maintenance ranges, so lock branches explicitly unless every matching branch should really publish.

Frequently asked questions

My plugins ignore CLI options. Why?

Plugin options live only in files, never in CLI flags. Move the plugin list (with per-plugin option objects) into .releaserc or release.config.js and keep CLI to branches and dry runs.

package.json or .releaserc, which shape is right?

Drop the release wrapper: file based configs set branches directly, while package.json nests the same object under release. Mixing the shapes is the classic silent failure.

Notice an outdated path? Let us know.