CLI

[anton-trunov]

There are still important suggestions in comments on this ticket. They will eventually be converted to issues.

Some docs, talks and guidelines on how to design CLI interfaces:

• Some nice CLI guidelines: https://clig.dev (btw, it suggests to use https://oclif.io as a CLI arguments parsing library).
• A talk by Adir Amsalem @ NodeTLV '23: Write CLI applications with Node.js like it’s 2023

[novusnota]

Got one idea just now: a sub-command config, which would deal with tact.config.json.

It may:

1. Create the following tact.config.json file, using tact config --init or tact config --create:

{
  "$schema": "http://raw.githubusercontent.com/tact-lang/tact/main/grammar/configSchema.json",
  "projects": []
}

2. Validate the existing config (is the structure correct, do specified files exist, etc.), like by running tact config --health or similar.
3. Provide help via --help command, which should also point to the docs by the end of it.

The ability to generate the config based on existing wrappers/ when working with Blueprint would also be nice to have, but as a part or extension of their CLI capabilities, not this one. Perhaps, also as a part of the exploratory programming toolkits too :)

UPD:

I'm also thinking about making a standalone repo + npm package for CLI. Additionally, the current version (bin/tact) can be left here as-is for backwards compatibility.

Blueprint, for one, uses API of the compiler directly, rather than the CLI, see: https://github.com/ton-org/blueprint/blob/41d57ed9a7f3a39069efb7f31c0eb0fb4f32174b/src/compile/compile.ts#L12

[novusnota]

Got one idea just now: a sub-command config, which would deal with tact.config.json.

Another sub-command options:

1. tact fmt, source code formatter Formatter #162
2. tact doc, for auto-generating docs for Tact projects based on /**/ comments. For this we'll need to introduce something like JSDoc or JavaDoc for Tact (TactDoc?).
3. tact lint or tact fix, for linting source code with a set of heuristics. Like shellcheck or eslint. Not a fuzzer, nor a static analyzer, but more of an interactive style guide (+= over = and +, etc.) checker and fixer.
4. tact ls, for language server (in the works).
5. tact tick, for a simple exploratory and interactive programming experience (in the works).

All of the above should have one or the other (may have both):

1. A standalone CLI counterparts, such that they could be used without general Tact's CLI
2. Exported API options, so they can be easily wrapped into the general Tact's CLI and/or other toolkits (spawning as little additional node processess as possible)

Having all those sub-commands will make general Tact CLI installation nearly self-sufficient, so that people could do npm i -g @tact-lang/cli and have all the niceties come bundled.

But before we do that, there should be a clear separation (IMHO) between the Tact compiler's CLI and the general Tact CLI (separate repo?), where the former would have --version, --help and be able to compile projects, while the latter would have all those nice wrappers, and perhaps, be able to switch between compiler versions on the fly. What do you think, @anton-trunov?

[novusnota]

Although it's just a rough idea, I think that compiler's CLI and/or API can be extended to allow switching between compiler versions or controlling available compiler versions per project. This would simplify working with multiple compiler versions #250.

However, this is not a pressing issue until breaking changes are introduced, such as per planned Tact 2.0 #249

[anton-trunov]

These are some really nice suggestions: #136 (comment).

Moving bin/tact to a separate package sounds reasonable, since we'd like to adhere to building the Tact compiler as a library with more or less stable API (in the future), so third-party tool could rely on Tact.

[novusnota]

Perhaps, it would be reasonable to keep the compiler's CLI and simply rename bin/tact into bin/tactc to avoid confusion with the upcoming general Tact CLI.

Although I'm in full support on having a somewhat stable API of the compiler. It would be especially nice to have the AST or CST exposed right after the parsing phase, so that it can be re-used in tools

[anton-trunov]

It would be especially nice to have the AST or CST exposed right after the parsing phase, so that it can be re-used in tools

We should definitely expose AST, preferably a typed one, unless someone has a use case for an untyped AST. Unfortunately, we don't have typed AST right now.

[novusnota]

Having --boc and --boc64 flag for only outputting BoC in binary and Base64 formats may be a nice addition to the compilation modes

[anton-trunov]

Having --boc and --boc64 flag for only outputting BoC in binary and Base64 formats may be a nice addition to the compilation mode's

That might be useful, indeed. However, let's have a use-case first, before adding those