Open anton-trunov opened 4 months ago
Got one idea just now: a sub-command config
, which would deal with tact.config.json
.
It may:
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": []
}
tact config --health
or similar.--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
Got one idea just now: a sub-command
config
, which would deal withtact.config.json
.
Another sub-command options:
tact fmt
, source code formatter #162tact 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?).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.tact ls
, for language server (in the works).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):
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?
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
These are some really nice suggestions: https://github.com/tact-lang/tact/issues/136#issuecomment-2021459272.
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.
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
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.
Having --boc
and --boc64
flag for only outputting BoC in binary and Base64 formats may be a nice addition to the compilation mode
s
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
For instance, add the following command line options:
--version
/-v
: output Tact's version (done in #137)--help
/-h
: output CLI help (done in #287)--check
: stop the compilation pipeline right after typechecking Tact code (done in #287)--func
: stop the compilation pipeline right after generating FunC code (done in #287)tact.config.json
file (done in #287)--expr
/-e
: evaluate a Tact expression:tact -e '-1 / (2 << 1 + 1)'
(done in #462)--ast-parsed
: output parsed AST (perhaps using JSON format here is preferable)--ast-typed
: output typechecked AST when we have itbin/tact
intobin/tactc
or introduce a name binding inpackage.json
to allow re-writing it as an ESM moduleYour suggestions are welcome!
Some docs, talks and guidelines on how to design CLI interfaces: