Stricli, a type safe CLI framework from Bloomberg with no runtime dependencies

A CLI framework whose selling point is what it does not bring

Stricli is described in one line: build complex CLIs with type safety and no dependencies. The subject is a framework, the primary language is TypeScript, and the two qualifiers in that sentence pull in opposite directions. Type safety suggests a compiler checking your command definitions. No dependencies suggests a package whose consumers do not inherit a transitive tree.

That second half is a real constraint on a CLI framework, because the obvious way to build one is to take a parser, an argument validation library, a help generator and a colour library, and let them all be dependencies. A published CLI tool ships those to every user who installs it. Stricli takes the position that the framework itself should not add to that bill, and the repository is a monorepo with a packages directory, where the core package is the one the installation section names.

The audience is engineers building something substantial enough to have a command tree, several subcommands and the help output to go with it. A one command script does not need a framework, and nothing in the project suggests otherwise.

The origin matters for expectations. This framework was developed by Bloomberg, and the homepage is a documentation site under the bloomberg.github.io domain rather than a personal project page. That implies a framework with a stated position on how a CLI should be built, and it explains the emphasis on written principles rather than on features.

Alternatives evaluated and principles published, before the API

The rationale section is unusual enough to be the most informative part of the project description. It says the framework was developed after evaluating the available alternatives and developing a set of guiding principles, and it links both: a page for the alternatives and a page for the principles.

Publishing the alternatives you rejected is a stronger claim than listing the ones you chose. It means a reader can see the design space the framework was drawn from, and the reasoning is visible rather than implicit in the code. For a framework whose central decision is to have no dependencies, that comparison is where you would expect the argument to live.

The principle pages also change how you read the API. A framework guided by written principles will make choices that look arbitrary until you read the reasoning, and the type of choice here, how commands are declared and how help is produced, tends to be the kind that only surfaces after you have written your first non-trivial command.

The practical advice is narrow and concrete. Read the alternatives page and the principles page before you write code, not after. If your expectations of what a CLI framework should look like differ from what those pages argue, that is the moment to notice, rather than after your command tree is built on a shape you did not choose.

The documentation site is the same site the README points to for all framework documentation, so these pages and the quick start live together.

Installing the core package, and generating an application

The core framework is published on npmjs.com and the installation section gives one command.

npm i --save-prod @stricli/core

The save-prod flag matters here, because the point of the package is that it is a runtime dependency of the CLI you ship, not a build time tool. Nothing else is needed to install it.

The next step is not a command. The quick start link in the project description is where you learn how to generate a new Stricli application, which tells you that the framework expects a project to be scaffolded rather than bolted onto an existing one. The generation step and the shape of the generated project are documented on the site, not in the repository, so the README alone is not enough to start work.

That is the practical boundary of the repository's own documentation. The README is a short map: rationale, quick start, building, installation, and the contribution and policy sections. Everything a developer needs beyond the install command is on the documentation site.

The repository does carry example projects, in an examples directory with separate folders for bun, deno and node, which is a faster way to see a working layout than generating one and guessing.

Three runtime examples: node, deno and bun

The examples directory holds three subdirectories, one per runtime, and that structure says more than a paragraph of description would.

A framework that only ever runs on one runtime can assume things about module resolution, process signals and how the entry point is invoked. One that ships examples for node, deno and bun is making a different claim: that the framework is portable across them, or at least that the author wanted to see whether it could be.

The distinction between node, deno and bun is mostly about how the program starts and how dependencies are loaded. Each example shows how the same command tree is wired for its own runtime, so the three differ in how the program starts. The repository root also carries a package-lock.json and a workspaces configuration, so the node example is a conventional npm project while the other two run in their own runtimes.

For an adopter, these examples are the reference for the questions the README leaves open. How the entry point is wired, how a command file is registered, how the binary is invoked, and what the package's bin entry looks like are all questions the example projects answer by existing, and all questions you would otherwise have to ask the documentation site.

The framework's own requirement is stated in the root package.json, which is a private workspace root rather than the published package.

A workspace built with Nx and tested with vitest

The repository is a monorepo. The root package.json is marked private, declares workspaces for docs and for every package under packages, and pins the package manager to [email protected] with an engines requirement of node >=24.5.0. That node floor is high, and it is the sort of detail that decides whether a framework fits your project before you write a line of code.

Development follows Nx. The development section says to run npm ci to initialise the repository, and then to use Nx to manage tasks so that all packages can be built at once.

npm ci
npx nx@latest run-many -t build

The build script and the vendor build are separate concerns in a mature package, and the monorepo layout with a packages directory is what makes a per package build possible at all.

Testing and linting are equally modern. The devDependencies include vitest with the v8 coverage provider, eslint 8 with the flat config tooling on top, typescript-eslint and prettier, and the root has a vitest.config.ts and an eslint.config.mjs. The formatting scripts are scoped to markdown, json and mjs files at the root, which is a small sign of how the repository treats formatting.

The practical consequence for a consumer is that none of this is installed in your project. The toolchain is for the framework's own development, and your dependency is the single @stricli/core package.

The documentation site ships llms.txt for coding assistants

One section of the project description has no counterpart in most framework repositories. The documentation site publishes an llms.txt index and a full-content llms-full.txt file, following the llms.txt convention, and the project says to point a coding assistant at one of those URLs to give it accurate and up to date context about Stricli. The suggested places to put the link are a chat, or your project's agent instructions such as AGENTS.md, CLAUDE.md or a .cursor/rules file.

This is a pragmatic response to a real problem. A framework with a command tree, a configuration model and a set of naming conventions is exactly the kind of thing a model will guess at rather than look up, and the failure mode is code that looks plausible and does not match the framework's actual shapes. Serving the documentation as plain text removes the guesswork.

The full-content variant matters for a large documentation set, since an index file alone would still send the assistant hunting. Publishing both means a tool can be given a map or the whole thing.

The same documentation site hosts the quick start, the principles and the alternatives pages, so the machine readable form and the human readable form are one site rather than two, which is the only arrangement that keeps them in step as the framework changes.

Apache-2.0, a trademark file, and a published security policy

The licence is Apache-2.0, and the repository carries a LICENSE file the project description asks you to read. The practical effect for an adopter is a permissive licence with an explicit patent grant, which is a common requirement in corporate procurement and a reason many teams prefer it over MIT.

Next to the licence is TRADEMARK.txt, a file that is not part of most open source projects. Its presence tells you the name and marks are separate from the code, and that using the framework in your own product does not hand you the right to call it Stricli. For a framework published by a company whose own product suite is commercial, that separation is deliberate and sensible.

The governance files are equally conventional and equally worth reading. There is a code of conduct, with a contact address at Bloomberg for concerns about the code or behaviour, and a security policy that the project points to for reporting vulnerabilities. A security policy is a signal about how a project handles disclosure, and for a framework that ends up inside tools people run with their own permissions, it is a reasonable thing to check before you adopt it.

Contributions are handled in the open, with issue templates, contribution guidelines in the .github directory and pull requests requested only after reading them. The recent releases are v1.3.0 on 2026-07-16, v1.2.9 on 2026-07-02 and v1.2.8 on 2026-06-18, the repository is not archived, and the last push was on 2026-09-09.

Editorial conclusion

Adopt Stricli if you are writing a command line tool in TypeScript and want typed command definitions without pulling a dependency tree into your published package, and if you can work against Node >=24.5.0. Do not adopt it as a general purpose argument parser for a script of twenty lines, and do not expect the framework to document itself in the repository, since the reference lives on the documentation site. Before you commit, read the alternatives and principles pages to understand the design constraints, run the quick start to generate an application and see the shape of a real command tree, and check the llms.txt file if you intend to let a coding assistant work against the documentation.

Frequently asked questions

Official sources

1. bloomberg/stricli on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases