Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 48 posts

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

#21

Post by codybontecou »

embedding-shape wrote: post #19
camkego wrote: post #12

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.

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.

That’s… actually a great definition. I’m going to try to retain that.

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

#22

Post by olivia-banks »

matt_kantor wrote: post #6
jellyotsiro wrote: post #5

Earlier quoted context omitted.

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.

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

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.

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

#23

Post by chenxin-yan »

camkego wrote: post #12

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.

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

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

#24

Post by chenxin-yan »

rgbrgb wrote: post #17
jellyotsiro wrote: post #15

Earlier quoted context omitted.

tens of KBs (v small)

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

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!

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

#25

Post by chenxin-yan »

matt_kantor wrote: post #3

> 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/

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.

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

#26

Post by chenxin-yan »

bennettpompi1 wrote: post #7

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

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

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

#28

Post by chenxin-yan »

qyron wrote: post #27

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

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.

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

#29

Post by matt_kantor »

olivia-banks wrote: post #22
matt_kantor wrote: post #6

Earlier quoted context omitted.

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

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.

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?

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

#30

Post by matt_kantor »

chenxin-yan wrote: post #25
matt_kantor wrote: post #3

> 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/

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.

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).
Post reply on HN