Boss: an npm-style dependency manager for Delphi and Lazarus
Dependency Manager for Delphi and Lazarus
At a glance
- What is it?
- Boss is a Go rewrite of a Delphi package manager that installs dependencies declared in boss.json, adds PubPascal publishing, workspace management and SBOM generation. It is a work in progress with a clear split between legacy commands and newer ones.
- Who is it for?
- Boss suits Delphi and Lazarus developers who want npm-style dependency management with a manifest file, who need to publish to a package registry, and who face European Cyber Resilience Act paperwork.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Boss is a Go rewrite with a manifest file at the centre
Boss is an open source dependency manager inspired by npm for projects developed in Delphi and Lazarus, and it is written in Go. The Go part is not incidental to how it works. The repository is a Go module named github.com/hashload/boss requiring Go 1.26.0, with cobra providing the command line interface, go-git and go-billy handling the Git operations, Masterminds/semver for version comparison, and pterm and gogress for terminal output. A self-update mechanism is present through minio/selfupdate, which is how the upgrade command can replace the running binary. The manifest is boss.json, created by the init command in the current directory, and dependencies are installed from it or added to it by the install command. That is the whole idea in the npm analogy: declare what you need, run install, and the tool works out the graph. The older commands, which the README calls the legacy core inherited from the original Boss engine, are the ones that do this. Everything else in the newer command set is an addition on top of that core.
Installation is a downloaded binary on your PATH
Getting Boss onto a machine is deliberately manual. The README's installation section points at the setup download in the project's releases page, and the manual route is to download the latest version of Boss, extract the files to a folder, add the folder to the system path, and run the command boss in the terminal. The shorter description says to download the setup and just type boss in the terminal. There is also an optional Boss Delphi IDE complement at a separate repository, which is a plugin for the IDE rather than part of the CLI itself. The repository layout backs the idea that this is a distributable binary rather than a library. The Makefile builds the binary with go build and links version metadata into it through ldflags, pulling the version, the git commit and a dirty or clean marker from the repository at build time. Its TARGETS list covers linux on amd64, 386, arm, arm64, ppc64le and s390x, plus windows on amd64 and 386, and there is a .goreleaser.yaml at the root for release packaging. The project also ships a setup/ directory, which is where the platform installer that the release page offers is assembled.
config, dependencies, init and install cover the everyday loop
The legacy core is where the npm resemblance is clearest. The config command manages settings such as Delphi paths and Git client settings, and two of them are worth knowing by heart. On Windows the native Git client is recommended, and shallow cloning can be enabled for faster dependency checkout:
boss config git mode native
boss config git shallow true
The dependencies command lists all project dependencies in a tree format, with a verbose flag to show version information, and it accepts a package name to narrow the listing:
boss dependencies
boss dependencies -v
boss dependencies <package>
The init command creates a new, minimal project configuration in the current directory and writes a boss.json file, and it has a quiet mode that skips the interactive prompts, which is what you want in a script. The install command installs the dependencies defined in boss.json or adds a new dependency:
boss init
boss init --quiet # Skip interactive prompts
boss install
boss install github.com/HashLoad/horse
Two more complete the loop. The update command moves all installed dependencies to their latest compatible versions, and the uninstall command removes a dependency from the current project. Both have aliases, and the README lists them, so boss rm and boss un work as you would expect.
new, pkg and run add project scaffolding and script execution
The newer command set covers things a package manager for Delphi historically did not do. The new command generates a fully structured Delphi or Lazarus project skeleton in the current directory, and the flags let you choose the IDE and the artefact type:
boss new my_project
boss new my_project --ide lazarus
boss new my_package --type pkg --ide lazarus
The pkg command performs Delphi package manifest operations, and its spec subcommand scaffolds a starter pubpascal.json manifest for a package with an identifier and a version. The run command executes a custom shell script defined in the scripts section of your boss.json:
{
"scripts": {
"build": "msbuild MyProject.dproj /p:Config=Release",
"clean": "del /s *.dcu"
}
}
boss run build
boss run clean
That scripts block is worth noticing as a design decision. The same manifest that declares dependencies also carries build and cleanup commands, so a project has one file describing both what it needs and how it is built. The example is Windows-flavoured, with msbuild and a del command, which tells you the scripts run through the system shell rather than a portable interpreter. That is a limitation rather than an oversight, but it does mean a scripts section written for Windows will not run unchanged on a Linux build agent.
PubPascal support covers publishing, forking and multi-repo workspaces
A set of commands integrates with the PubPascal portal. The login command authenticates your local environment using a personal access token:
boss login --token <pat>
The contribute command automates forking a third-party package and creating a pull request. It forks the upstream package and configures your local git remotes, with origin pointing at your fork and upstream at the original, and once your commits are ready you push and submit a pull request back to the original repository with a title and body:
boss contribute github.com/HashLoad/horse
boss contribute github.com/HashLoad/horse --pr --title "Fix memory leak" --body "..."
The workspace command manages multi-repository PubPascal workspaces. Its clone subcommand clones a workspace and all its member repositories, checking out the reference each one is pinned to, with a codename option to check out a branch instead. The status subcommand shows Git status, ahead, behind and dirty, for every repository in the workspace, update fast-forwards each repository on its current branch, and push sends committed changes for each repository that has an upstream branch. The dependency list in go.mod explains why this is possible: go-github provides the GitHub API client, and go-git provides the local repository operations that workspace status, update and push need.
The cra and sbom commands exist because of the Cyber Resilience Act
One of the newest command groups is aimed at European regulation. The cra command checks your project's CRA compliance status or initialises the required files automatically. Running it bare scans the local project for the required signals, a Security Policy and an SBOM, and the documentation makes a point of the exit status: it exits with status 1 when a signal is missing, so it can be used as a CI gate. The init subcommand starts an interactive wizard to generate the SECURITY.md policy and the sbom.cdx.json file, and it accepts an email argument for silent, CI mode operation:
boss cra
boss cra init --email [email protected] # Silent/CI mode
The sbom command generates a standard CycloneDX or SPDX software bill of materials for a Delphi project, writing CycloneDX output to a directory named after the project:
boss sbom
This is a genuinely different kind of feature from the rest of Boss, and it is the clearest example of the project expanding beyond dependency management into compliance tooling. It is also the part most likely to be specific to a European context, since the Cyber Resilience Act applies to products with digital elements placed on the EU market. The README links an SBOM badge pointing at pubpascal.dev, so the SBOM story is connected to the registry side of the project rather than being a standalone add-on.
The Go build matrix and the test target show how releases are produced
The Makefile at the root is where the release engineering lives. It builds into a bin directory under the current directory, and the linker flags strip the binary with -w -s while embedding the version, the git commit and the metadata into the internal version package. The metadata value defaults to unreleased and is cleared when the build comes from an exact tag, which is a small but correct way to distinguish a release build from a development build. The install target runs go install, and the run target exists for executing a subcommand during development. The test target depends on the build and then runs the style check and the unit tests, with the race detector and verbose output enabled except on s390x, where the flags differ. A separate tool directive in go.mod pins golangci-lint as a project tool, and the repository has a .golangci.yml configuration along with a .pre-commit-config.yaml and a .vscode/ directory, so the linting is enforced at several points in the workflow rather than by convention. Releases are frequent: v3.0.17 on 2026-08-22, v3.0.16 on 2026-08-17 and v3.0.15 on 2026-08-03, with the last push to the repository on 2026-10-19. The project also publishes a Telegram channel and links a Getting Started article written in Portuguese, which tells you something about the community it serves.
Editorial conclusion
Boss suits Delphi and Lazarus developers who want npm-style dependency management with a manifest file, who need to publish to a package registry, and who face European Cyber Resilience Act paperwork. It is the wrong choice if your dependencies are managed by Delphi's own tooling, if you need Windows-only tooling you cannot run headless, or if you want a package manager with a long track record, since the project states its older command set is inherited from an earlier engine and the newer commands are still settling. Verify first that your compiler and version manager combination is supported, that the manifest format suits your project layout, and that the SBOM and CRA output your compliance process expects is what the sbom and cra commands actually produce.
Frequently asked questions
How do I install the Boss dependency manager for Delphi?
The README points at the setup download in the project's releases page, or you can download the latest version, extract the files to a folder, add that folder to the system path and run boss in the terminal. An optional Boss Delphi IDE complement is available as a separate project.
What file does Boss use to track project dependencies?
The boss.json file in the project directory. The init command creates it, the install command installs what it declares or adds a new dependency to it, and the run command can also read a scripts section from it.
How does Boss help with Cyber Resilience Act compliance?
The cra command scans the project for the required signals, a Security Policy and an SBOM, and exits with status 1 when one is missing so it can act as a CI gate, while cra init generates SECURITY.md and sbom.cdx.json through a wizard or in silent mode with an email argument.
Which platforms does Boss build for?
The Makefile TARGETS list covers linux on amd64, 386, arm, arm64, ppc64le and s390x, plus windows on amd64 and 386, and releases are packaged with .goreleaser.yaml.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hashload-boss)Was this useful?