clo4 / run-fig Goto Github PK

"Run Fig" is a placeholder. I intentionally phrased the readme/description to never mention the library's name, partly because:

• It doesn't have one yet
• It helps slow growth until it's ready to be used more widely

Deciding on a name is tricky. This isn't an official Fig thing. I do work for Fig, so it could become official (or officially endorsed as a community project), but I don't want to name-squat or do anything out of line.

This feels unnecessarily long-winded. Couldn't I just do:

    help({
      error: `Expected a command, but the value was empty`, 
      description: false,
    });

?

Originally posted by @separaterecords in #12 (comment)

There's a lot of unnecessary slowdown in the analysis stage

This was implemented before release as a proof-of-concept but was cut to due code quality. Will be reimplemented.

Add in one extra line to your subcommands (Fig.completion), then run <cli> completion fig --upload to instantly get powerful completions. Will also support running custom generators on the CLI itself to reuse app logic.

I've been using benchmarks to test the library the whole time while developing it, but I removed before release. Will re-add with a larger suite.

Maybe should be renamed to lints, and more generic (not so tied to Deno, maybe with a Deno adapter)

You can use options.get("not an option") and TS won't tell you there's a mistake, because actions currently cannot know their options or args statically.

Blocked on parser generator. Can generate types too.

I left a lot of TODOs in there

The readme explains what the library is and why you should use it, but not why it exists or where it's going. This is critical for contributors -- including myself -- to make it clear what does and doesn't align with project goals

Will put some examples of great OSS/lib vision statements in replies

Blocked on parser generator. Most CLIs only need strings but some have other requirements such as numbers, booleans, files, and enums.

Descriptions aren't "dedented" (un-indented) at the moment. There's a proposed String.dedent function, could implement this in the help system.

This would not apply actively, only when formatting the description for help.

Currently very messy. Critical feature, so did not get cut, but I didn't want to refactor it before launch because it works.

Will spec out behavior too.

This makes aliasing more convenient

Currently this isn't even on deno.land/x but an eventual goal is to host on NPM to use with Bun and Node.

Fig specs are essentially a grammar definition as JSON. The parser isn't optimal for every CLI because it has to be general enough to run them all, but a parser generator can create the optimal parser for each CLI.

I want this to be seamless. It should feel like no effort at all to set it up for your project. Not sure exactly how this will look right now