Migrating from other version managers

jrt import reads the version files a repository already has and writes the equivalent .jrt.toml pins. Your old files stay in place, so teammates on other tools are not affected.

Usage

shell

jrt import --dry-run   # show what would be pinned, change nothing
jrt import             # write .jrt.toml; existing pins are kept
jrt import --force     # replace existing pins that differ

example

$ cat .nvmrc
lts/iron
$ jrt import
$ cat .jrt.toml
[runtimes]
node = "20"

Recognised files

Source	Runtime
`.nvmrc`, `.node-version`, `package.json#volta.node`	node
`.python-version`	python
`.ruby-version`	ruby
`.go-version`	go
`.java-version`	java (plain or vendor-prefixed, e.g. `temurin-17`)
`.bun-version`, `.deno-version`	bun, deno
`rust-toolchain`, `rust-toolchain.toml`	rust
`global.json` (`sdk.version`)	dotnet (feature line unless `rollForward: disable`)
`mise.toml`, `.mise.toml` `[tools]`, asdf `.tool-versions`	any of the above

Rules

Dedicated single-runtime files (like .nvmrc) win over multi-runtime configs (like .tool-versions). Disagreements are reported, never silently merged.
Floating selectors — lts/*, stable, nightly, system — are skipped with a warning, because a pin must not change meaning over time.
nvm LTS codenames map to their fixed major: lts/hydrogen → 18, lts/iron → 20.
go.mod#go is treated as a requirement, not a pin.
jrt current hints when importable files exist but no .jrt.toml does.