Version 0.4.0 marks a big step in the evolution of the soldeer codebase and implements many new features and improvements compared to previous releases. Below are the main points.
New code structure
The codebase has been split into 3 crates to enable integration of the soldeer core logic and CLI commands with other applications.
soldeer-core: the core functionality of soldeer. Things like reading and writing config files, lock files, interacting with the registry API and more. At the moment, logging is gated behind a cli feature flag.
soldeer-commands: high-level clap commands which can be used to implement a CLI tool. This is meant to be used by forge and the soldeer CLI.
soldeer: this is the standalone soldeer CLI application
In the future, I would like to further reduce the coupling between the soldeer-core crate and cliclack UI library, so that logging can be made agnostic of the (T)UI, but still be integrated nicely with it.
Version requirement specifiers
Dependencies were previously specified with at least a name and a version. Starting with this release, the version can be a version requirement specifier. The format follows the semver::VersionReq comparator specification, with the notable exception that the absence of an operator is considered to mean "exact" (similar to what solidity does).
Remappings format
In remappings, the default behavior is to include the version requirement string as a suffix to the left-hand side path. As an example, this enables the following:
Remappings customization is now also handled properly, meaning that the left-hand side part can be customized to anything, which won't get overwritten when commands are ran without the --regenerate-remappings option. The right part can likewise be customized to include additional path segments after the dependency's directory. Examples:
The UI now uses cliclack to display progress and prompt the user for information. This is a significantly nicer experience than previously.
Improved install command
The install command now avoids to perform useless work by checking already installed dependencies and skipping associated downloads. For git dependencies, most operations leverage available git commands to avoid unnecessary clones.
Each dependency is installed in parallel, with more pipelining and thus a shorter total install time even if all dependencies must be installed.
Improved update command
Previously the update command was not performing according to user expectations. Now, the command updates dependencies which satisfy these requirements:
HTTP dependencies without a custom URL (from soldeer.xyz)
If the version requirement allows for multiple versions (e.g. 5 or ^5.0.0 or >=5.0.0) and
If all registry versions for the dependency are semver-compatible
Git dependencies with a branch identifier or no identifier (default branch)
The lockfile stores the exact installed version so that installs are reproducible. When the update command is ran, the lockfile is updated with the new versions.
Improved init command
The init command is now smarter and does slightly more:
Prompt the user to chose a config location for the dependencies
Create the dependencies dir
Add and install the forge-std dependency
Remove the git submodules and lib folder
Create the lockfile
Create the remappings
Add the dependencies folder to the .gitignore.
New lockfile format
The new lockfile format has differentiated entries for Git vs HTTP dependencies, allowing for a more concise and explicit representation. For HTTP dependencies, the zip archive checksum is stored and checked upon downloading. If the hash is different, installation is aborted. Likewise, the unzipped dependency is hashed upon installation and checked to avoid re-installing an existing dependency.
New test suite
All tests have been rewritten to enable running them in parallel. All IO side effects are contained to special temporary folders thanks to testdir. API mocking is performed with mockito and environment variables are mocked with temp-env.
The new suite runs significantly faster than the old one and can be efficiently parallelized with cargo-nextest, which is the recommended way to run them.
All tests are now ran in CI on Linux, macOS and Windows.
Various fixes and performance improvements
Various bugfixes have been implemented during the refactor, either as a result of the change in architecture or because they showed up in unit/integration tests. Some functions have been refactored to improve performance and parallelism.
Version 0.4.0 marks a big step in the evolution of the soldeer codebase and implements many new features and improvements compared to previous releases. Below are the main points.
New code structure
The codebase has been split into 3 crates to enable integration of the soldeer core logic and CLI commands with other applications.
soldeer-core: the core functionality of soldeer. Things like reading and writing config files, lock files, interacting with the registry API and more. At the moment, logging is gated behind aclifeature flag.soldeer-commands: high-levelclapcommands which can be used to implement a CLI tool. This is meant to be used byforgeand thesoldeerCLI.soldeer: this is the standalone soldeer CLI applicationIn the future, I would like to further reduce the coupling between the
soldeer-corecrate andcliclackUI library, so that logging can be made agnostic of the (T)UI, but still be integrated nicely with it.Version requirement specifiers
Dependencies were previously specified with at least a name and a version. Starting with this release, the version can be a version requirement specifier. The format follows the semver::VersionReq comparator specification, with the notable exception that the absence of an operator is considered to mean "exact" (similar to what solidity does).
Remappings format
In remappings, the default behavior is to include the version requirement string as a suffix to the left-hand side path. As an example, this enables the following:
Remappings customization is now also handled properly, meaning that the left-hand side part can be customized to anything, which won't get overwritten when commands are ran without the
--regenerate-remappingsoption. The right part can likewise be customized to include additional path segments after the dependency's directory. Examples:New progress and prompts UI
The UI now uses
cliclackto display progress and prompt the user for information. This is a significantly nicer experience than previously.Improved install command
The install command now avoids to perform useless work by checking already installed dependencies and skipping associated downloads. For git dependencies, most operations leverage available git commands to avoid unnecessary clones.
Each dependency is installed in parallel, with more pipelining and thus a shorter total install time even if all dependencies must be installed.
Improved update command
Previously the update command was not performing according to user expectations. Now, the command updates dependencies which satisfy these requirements:
5or^5.0.0or>=5.0.0) andbranchidentifier or no identifier (default branch)The lockfile stores the exact installed version so that installs are reproducible. When the update command is ran, the lockfile is updated with the new versions.
Improved init command
The init command is now smarter and does slightly more:
dependenciesdirforge-stddependencylibfolder.gitignore.New lockfile format
The new lockfile format has differentiated entries for Git vs HTTP dependencies, allowing for a more concise and explicit representation. For HTTP dependencies, the zip archive checksum is stored and checked upon downloading. If the hash is different, installation is aborted. Likewise, the unzipped dependency is hashed upon installation and checked to avoid re-installing an existing dependency.
New test suite
All tests have been rewritten to enable running them in parallel. All IO side effects are contained to special temporary folders thanks to
testdir. API mocking is performed withmockitoand environment variables are mocked withtemp-env.The new suite runs significantly faster than the old one and can be efficiently parallelized with
cargo-nextest, which is the recommended way to run them.All tests are now ran in CI on Linux, macOS and Windows.
Various fixes and performance improvements
Various bugfixes have been implemented during the refactor, either as a result of the change in architecture or because they showed up in unit/integration tests. Some functions have been refactored to improve performance and parallelism.
Closes #188 Closes #182 Closes #181 Closes #156 Closes #155 Closes #153 Closes #152 Closes #144 Closes #138 Closes #134 Closes #120 Closes #108 Closes #46