proto v0.20 - New shims and binaries management
In this release, we're reworking how shims and binaries work.
Shims and Binaries (breaking)
Since proto's inception, we've used shims as a way to execute installed tools. This allowed us to wrap the underlying tool binary to provide additional functionality, such as automatic version detection, runtime hooks, and more. However, this approach has some limitations, such as:
- Shims are forced onto you and there's no way to use proto without shims.
- Shims are slower than executing the native binary, upwards of 10x slower. While this equates in milliseconds, it can be noticeable dependending on the tool.
- For Windows, our shim files are
.cmd
and not.exe
. This causes a lot of weird and unexpected problems when an environment expects a real executable, or uses a hard-coded.exe
extension.
To remedy this, we're introducing both a shim and non-shim approach, which has resulted in a pretty
big breaking change. Shims are now generated in ~/.proto/shims
(instead of ~/.proto/bin
), while
~/.proto/bin
will now store symlinks to native binaries. To migrate to this new pattern, we're
introducing a new proto migrate
command (this only needs to be ran once).
$ proto upgrade
$ proto migrate v0.20 --log debug
How it works
When installing proto for the first time, or running the proto migrate
command, we prepend PATH
with $PROTO_HOME/shims:$PROTO_HOME/bin
. This allows shims to be executed first and fallthrough
to native binaries if a shim does not exist (for example, .exe
on Windows).
Furthermore, if you'd prefer to only use shims, or only use binaries, you can update PATH
and
remove the unwanted directory path.
And lastly, if shims are causing problems, you can now easily reference the native binaries directly. This was rather complicated before.
Comparison
Shims | Binaries | |
---|---|---|
Location | ~/.proto/shims | ~/.proto/bin |
Created as | Scripts that run proto run | Symlinks to the native binary |
Version executed | Detects version at runtime | Last version that was installed + pinned |
Supported for | All tools | Only tools that support native execution (may not work for .js files) |
Additional files | Creates extra files (like bunx , node-gyp , etc) | Only links the primary binary |
Support for minisign checksums
When proto installs a tool, it runs a process known as checksum verification, where we ensure the download hasn't been modified maliciously in anyway. Historically we only supported SHA256 checksums, but now, we also support the new minisign tool, used by popular tools like Zig.
If you're building a plugin for a tool that uses minisign, you can use the new
checksum_public_key
(WASM) or
install.checksum-public-key
(TOML) field
to provide the public key for use in verification.
When the checksum URL ends in a .minisig
extension, proto will automatically use minisign for
checksum verification!
[install]
checksum-url = "https://domain.com/some/path/to/checksum.minisig"
checksum-public-key = "untrusted comment: ..."
Other changes
View the official release for a full list of changes.
- Updated
proto use
to install tools in parallel. - Updated
proto plugins
andproto tools
to load plugins in parallel. - Updated
proto run
to error when the tool attempts to self-upgrade outside of proto. - Rust plugin
- Will now attempt to install
rustup
if it does not exist on the current machine. - Will now respect the
RUSTUP_HOME
environment variable when locating the.rustup
store.
- Will now attempt to install
- Schema plugin
- Added
install.checksum_public_key
for defining the public key used to verify checksums. - Added
metadata.self_upgrade_commands
for defining which sub-commands should be blocked for self-upgrades.
- Added