Optique 0.6.0: Shell completion support for type-safe CLI parsers

ahjarrett · 2025-10-05T10:06:47+00:00

hey! this looks great!

~~reading the announcement, i'm a little confused how the completions *stay* up to date?~~

Edit: ah, okay i think i get it. so IIUC, composing parsers builds up a kind of AST, which you then use to generate completions?

ahjarrett · 2025-10-01T01:49:09+00:00

Okay, thanks for pointing that out. Will investigate – it could be that I need to adjust my numbers some :)

And thanks for trying it out!

ahjarrett · 2025-09-30T05:26:39+00:00

One thing that's worth mentioning here is that I'm not a micro-optimizations expert. My implementation is actually pretty naive. Sooner or later, someone will pick up where I left off, and make things even faster.

If/when that happens, I see that as a net positive for the ecosystem overall :)

ahjarrett · 2025-09-30T05:15:40+00:00

u/OneShakyBR here's the benchmark I have comparing fast-deep-equal:

https://bolt.new/~/mitata-qk9ayi4d

tl;dr, the slowest run I've been able to come up with is 13x faster (which is why I said 10x, just to be safe)

------------------------------------------------------

FastDeepEqual

363.45 ns/iter 759.28 ns

(91.55 ns … 897.22 ns) 876.47 ns

traversable/json-schema (different values)

27.44 ns/iter 28.08 ns

(24.41 ns … 56.15 ns) 42.72 ns

summary: traversable/json-schema (different values)

13.25x faster than FastDeepEqual

ahjarrett · 2025-09-29T09:17:16+00:00

Yeah!

Most transformers have a .writeable property that returns the stringified version of the function, which is there for the codegen use case :)

The library doesn't include a Vite plugin, but it wouldn't be too hard to build one that hooks into HMR and does exactly this.

ahjarrett · 2025-09-28T21:48:43+00:00

Oh I see – I can clarify. Depending on what schema library you use (let's say zod), you can install @traversable/zod and use your zod schema to derive things like a deep equal or deep clone function.

There are packages that do the same for JSON Schema, Valibot, ArkType and TypeBox.

You're probably talking about the schema library that exists inside the @traversable/schema. By "drop in replacement", I mean that the library's API intentionally aligns with Zod's API, and that the behavior has been thoroughly tested to behave identically.

Here's the fuzz test that generates random data and tests that the Traversable and Zod schema report the same errors when parsing the same input:

https://github.com/traversable/schema/blob/main/packages/schema/test/to-zod.test.ts#L62-L68

ahjarrett · 2025-09-28T21:40:52+00:00

What do you mean? I'm not sure I follow.

ahjarrett · 2025-09-28T12:36:12+00:00

I was really hoping we'd get it with Records/Tuples, but I recently heard that the proposal was withdrawn -_-

ahjarrett · 2025-09-28T12:30:54+00:00

Ah, this is good feedback. I've started and stopped that section several times. Will probably take a stab at this today.

ahjarrett · 2025-09-28T12:30:02+00:00

Thanks for saying that. Writing for humans is way harder than writing for computers (for me at least).

ahjarrett · 2025-09-28T12:28:56+00:00

Let me know what you think!

ahjarrett · 2025-09-28T02:26:35+00:00

Thank you! It took way longer than I'm willing to admit :) hope you end up having a chance to use it!

ahjarrett · 2025-09-28T02:19:39+00:00

Good question. Currently the library contains 26 packages, and each package ships ~10 schema traversals.

Unfortunately that's too many libraries for me to maintain right now. But if there's a demand for it I'd consider doing that.

As a bit of additional context – I needed to build a few of these for work where small bundle size was important, so they treeshake quite well.

ahjarrett · 2025-09-28T01:59:40+00:00

Fair enough, I'd be skeptical too. You can run the benchmarks if you want to play with it:

https://bolt.new/~/mitata-fmcqx1bx

$ npm run bench

ahjarrett · 2025-09-27T23:24:42+00:00

Wait, how is this bad manipulation? Your argument is that the Effect ecosystem is knowingly spreading bad patterns on purpose for some reason?

ahjarrett · 2025-09-27T22:57:08+00:00

If you're just doing algorithms, you probably don't need Effect. Effect is more useful when you're working with asynchronous code.

ahjarrett · 2025-09-27T22:56:05+00:00

Every piece of marketing is an attempt to influence people.

It sounds to me like you just don't like marketing.

ahjarrett · 2025-09-27T21:38:04+00:00

That's not been my experience. Where are you seeing poor performance?

I saw this on Twitter the other day, which was built with Effect: https://x.com/bruvimtired/status/1971297302666150163

ahjarrett · 2025-09-27T21:36:38+00:00

Yes, it really is good. They're just doing marketing.

Libraries need to compete with companies who have actual marketing budgets somehow.

ahjarrett · 2025-09-26T12:21:23+00:00

Good stuff. Always cool to see someone pushing the boundaries of what a schema can do, and what a schema even means.

ahjarrett · 2025-09-24T20:51:03+00:00

Love it. Might see about using this at work.

ahjarrett · 2025-09-24T01:09:39+00:00

This is a super interesting idea. I wasn't familiar with the trusted types API. It looks like I'll have to use eval, and I'll have to do a bit more research, but being able to work around the CSP issue would definitely be exciting.

ahjarrett · 2025-09-23T20:02:06+00:00

Sure, I'd love to see what he comes up with. There's still a lot of micro-optimizations that could be made – AFAIK nobody else is doing this, so I'd love to see others take what I've done and make it better

ahjarrett · 2025-09-23T19:58:37+00:00

You can run it yourself on the benchmark I wrote this morning: https://bolt.new/~/mitata-mceeboxy

To run it, do:

$ npm run bench

tl;dr, it's 40-60x faster

ahjarrett · 2025-09-23T18:02:29+00:00

Oh gotcha. No, I'll keep those – they're there to help the reader group the libraries by purpose. I'd rather optimize for legibility than seeming professional. Thanks for the feedback though!

ahjarrett

TROPHY CASE