alt.hn

3/17/2026 at 4:43:29 AM

Show HN: Crust – A CLI framework for TypeScript and Bun

 https://github.com/chenxin-yan/crust

by jellyotsiro

3/17/2026 at 6:23:57 PM

This looks useful. But, it's interesting how the backend-world and front-end world keep diverging. I must admit, I had no idea what this was from the title. "CLI framework"? But in backend-land, these would typically be called "argument parsers" or "command line argument parsers". But maybe I am missing some of the functionality.

by camkego

3/17/2026 at 8:16:55 PM

Both in the frontend and the backend, I've usually used "If it calls your code, it's a framework, if you call its code, it's a library", and would seem to fit here too. An argument parser you'd call from your main method, then do stuff with what it returns. In Crust, it seems you instead setup the command + what will happen when it's called, then let the framework call your code.

by embedding-shape

3/17/2026 at 6:40:12 PM

good point.

we’re using “framework” intentionally because it goes beyond argument parsing. crust handles parsing, but also:

type inference across args + flags end to end compile-time validation (so mistakes fail before runtime) plugin system with lifecycle hooks (help, version, autocomplete, etc.) composable modules (prompts, styling, validation, build tooling) auto-generates agent skills and modules from the CLI definitions

so it sits a layer above a traditional arg parser like yargs or commander, closer to something like oclif, but much lighter and bun-native.

by jellyotsiro

3/17/2026 at 9:34:11 PM

Hi, I called it "CLI framework" because it is more of a ecosystem of modules that contains everything you need to build a CLI, argument parsing is just part of it. The @crustjs/core module is the argument parser, and there are more modules such as @crustjs/skills that would derive agent skills from your command definition, @crustjs/store that state persistent and so on

by chenxin-yan

3/18/2026 at 1:01:19 AM

also: no "C", and no "rust", despite being a portmanteau of both these other languages names :)

by lozf

3/18/2026 at 6:51:15 AM

I was looking for something like this.

Does the help plugin not support color?

Looks like the spacing is messed up too. I just converted my app to use it and its coming out like

``` COMMANDS: export-schemaExport table definitions from existing database to YAML export-dataExport table data in CSV format import-dataImport table data from CSV file schema-sqlConvert YAML schema back to MySQL export-usersExport users in YAML format users-sql Convert users.yaml back into SQL export-allExport all data from host export-all-tgzExport all data from host databases-sqlConvert databases.yaml back into SQL export-typescriptExport TypeScript interfaces ```

i.e. there's no space after `export-schema` it just goes immediately to the description.

by hdjrudni

3/18/2026 at 7:10:24 PM

I will add color support for help plugin later. open a issue if you found bugs or improvement

by chenxin-yan

3/18/2026 at 11:05:37 AM

The plugin system and compile-time validation are nice touches. My main concern would be the standalone binary size — 58-109MB is a lot for a CLI tool. Most Go CLIs land around 10-20MB and even that gets complaints. Is there a way to strip unused features, or is this mostly the Bun runtime being bundled?

by derodero24

3/18/2026 at 2:53:18 PM

The binary size is my main hesitation with Bun-based CLIs too. For comparison, a typical Go CLI with cobra compiles to ~10MB statically linked, and you get cross-compilation for free. The plugin system and compile-time validation here are genuinely nice though — Go's CLI ecosystem doesn't have anything equivalent to that.

by babarot

3/19/2026 at 10:38:13 AM

Yeah exactly. Go's ~10MB binaries with dead-simple cross-compilation is tough to compete with. I think Bun makes more sense for internal tools where you control the install and care more about the plugin ecosystem than distribution size.

by derodero24

3/18/2026 at 4:51:03 AM

Looks cool. If anyone is interested in a simple option with autocomplete working out of the box and no extra bells and whistles, feel free to check out my project: https://github.com/gutenye/script.js

by GutenYe

3/17/2026 at 5:57:13 PM

this is cool! i'd recommend fleshing out the README. Clicked on the link before the discussion and was a tad confused.

by bennettpompi1

3/17/2026 at 10:07:11 PM

Hi, I will update the README.md to make it more informative. The reason I left it kinda empty is because curst has a website that have more details about this project at crustjs.com. I just had the link in README.md for now

by chenxin-yan

3/17/2026 at 5:59:42 PM

will fix in the next hour!

by jellyotsiro

3/17/2026 at 8:26:07 PM

I’ve been using the jsr:@cliffy/* packages from deno to solve the same problem.

by nullstyle

3/18/2026 at 7:53:22 AM

yup yup same. That one's worked well for me. Between that and the deno std, it's nice to have it feel like mostly everything you need is available with very little searching.

by bpev

3/19/2026 at 10:32:50 AM

As a Bun user, this caught my eye. Gonna give it a try!

by iktakahiro

3/17/2026 at 5:33:48 PM

Is there an examples section? Would be helpful to see a demo

by landl0rd

3/17/2026 at 5:42:17 PM

one of the examples would be trynia.ai (search and index api for ai agents)

here is github: github.com/nozomio-labs/nia-cli

by jellyotsiro

3/17/2026 at 11:21:12 PM

Any plans to support Node.js? Also some comparison (at least design choices) with existing frameworks would be nice.

by qyron

3/17/2026 at 11:46:40 PM

Technically most modules would work with node.js as they are not using any bun specific APIs. The reason for crust to be all in bun is because bun can compile your cli into binaries for distribution which powers curst build. The idea is that since you will have bun bundled with your CLI to end user. the developer does have to worry about the end users don't have bun installed and use Bun api freely when building.

by chenxin-yan

3/17/2026 at 6:37:19 PM

nice, congrats on launch. To get an idea... what's the size of a standalone hello world cli binary?

by rgbrgb

3/17/2026 at 7:11:53 PM

tens of KBs (v small)

by jellyotsiro

3/17/2026 at 7:39:05 PM

Isn't a standalone Bun binary like 50MB because it has to bundle the runtime? How could this get smaller?

by rgbrgb

3/17/2026 at 10:01:54 PM

Hi, the creator of crust here, the binary size varies between platforms. With the hello world cli, the smallest, on darwin-arm64 it is 58.1M, the largest on windows-x64 is 109M. hope this helps!

by chenxin-yan

3/17/2026 at 5:36:04 PM

> Versions before 1.0 do not strictly follow semantic versioning.

Sorry for being nitpicky, but yes they do. Semantic versioning[0] allows arbitrary changes while the major version is 0:

> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[0]: https://semver.org/

by matt_kantor

3/17/2026 at 10:04:42 PM

Hi, the comment I left in README.md is just to warn user that do expect breaking changes before 1.0 for THIS PROJECT specifically. there is no implication that semver as a standard is promoting arbitrary changes/version before 1.0.

by chenxin-yan

3/18/2026 at 12:16:59 AM

I get that, and it's a nice thing to warn users about. My nitpick was merely about the specific "do not strictly follow semantic versioning" phrasing. There's nothing you can do in a 0.y.z release which doesn't follow the SemVer spec (e.g. your next release could turn the project into a spell checker instead of a CLI framework and you'd still be in compliance).

by matt_kantor

3/18/2026 at 1:16:48 AM

ohh thank you for pointing that out. I just double checked the semver docs and it makes sense now. Something new I learned today

by chenxin-yan

3/17/2026 at 5:43:07 PM

thanks for the catch, what we meant is that we’re not committing to strict stability guarantees yet, so APIs may still change as we iterate toward 1.0.

by jellyotsiro

3/17/2026 at 5:46:13 PM

I understand, but that's already implied by a 0.y.z version number.

by matt_kantor

3/17/2026 at 9:09:36 PM

I will say that this doesn't seem to be how semver is used in the wild, which I would argue is more important. I personally didn't know about this rule. Tons of Rust projects follow semver don't follow it either, and just stay on 0.x.y forever.

by olivia-banks

3/18/2026 at 12:07:32 AM

How is it used in the wild, in your experience? Have you observed projects following some alternate set of rules?

I thought projects that stay on 0.x.y forever mostly do it because it means they're allowed to break things. Also, since 0.x.y means "anything goes", projects can introduce their own conventions within that range without violating the spec.

I know that some package managers (including Cargo and npm) confusingly treat 0.1.0 → 0.1.1 like a "minor" update, despite the spec. Is this what you're referring to?

by matt_kantor

3/20/2026 at 3:30:48 PM

Yes, that was what I was referring to, although I thought the reason of staying at 0.y.z was more of a cultural one. v0, at least to me, implies that the API may change arbitrarily and quickly, but makes no assertions about the actual versioning scheme itself.

There's a website making fun of it: https://0ver.org/

by olivia-banks

3/18/2026 at 9:30:21 AM

seems pretty useful and easy to setup

by todteera

3/18/2026 at 4:50:48 AM

wow, cannot wait to start with this

by optivly

3/19/2026 at 2:56:48 AM

[dead]

by rrojas-nexus

3/17/2026 at 8:02:32 PM

[dead]

by leontloveless

3/18/2026 at 9:15:05 AM

[dead]

by kaihong_deng

3/17/2026 at 6:11:27 PM

Psst, the GitHub link in your post is broken (it should be https://github.com/chenxin-yan/crust).

by dnlzro

3/17/2026 at 7:31:28 PM

Fixed above. Thanks for the heads-up!

by dang

3/17/2026 at 6:15:32 PM

thanks for flagging! the post itself works, just the link at the bottom

by jellyotsiro