You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, it's impossible to control anything beyond project-specific compilation options in tact.config.json as it's used in Blueprint.
Furthermore, with upcoming introduction of things like compilerVersion to tact.config.json (tact-lang/tact#574), the Tact and Blueprint would become even more driven apart. And that's not good :)
Current solution
In PR #96, the auto-sourcing of tact.config.json was introduced. However, in order not to re-architect the compilation pipeline, I decided to keep the changes there to a minimum — and so the properties in tact.config.json had to be re-purposed to match the Blueprint approach to compilation.
While this made it possible to better configure Blueprint behavior in Tact projects, it introduced a significant discrepancy between the Tact compiler and Blueprint.
Suggestion for a better solution
Get rid of wrappers/ (recently renamed to compilables/) completely in Tact projects and switch to using tact.config.json:
Whenever a new contract is created with blueprint create, ask people if they want a new compilation entry point (project) added to tact.config.json. If yes, then modify its contents. If not, don't touch it :)
In blueprint build, only show the projects as defined in tact.config.json.
The current build/ folder may still be actively suggested as the output folder. With the full source of tact.config.json, it wouldn't matter if users chose a different folder as long as they specified it there — Blueprint would just take TypeScript wrappers based on that.
This change would:
Align the behavior of the Blueprint and Tact's compiler, which would simplify documentation and maintenance efforts tenfold!
Help all third-party tools rely on a single source of truth for compilation configuration, the tact.config.json.
Help all users specify compilerVersion and/or projects (entry points) for compilation in a single, well-documented place with auto-completion and hover suggestions provided by configSchema.json.
Problem
At the moment, it's impossible to control anything beyond project-specific compilation options in
tact.config.json
as it's used in Blueprint.Furthermore, with upcoming introduction of things like
compilerVersion
totact.config.json
(tact-lang/tact#574), the Tact and Blueprint would become even more driven apart. And that's not good :)Current solution
In PR #96, the auto-sourcing of
tact.config.json
was introduced. However, in order not to re-architect the compilation pipeline, I decided to keep the changes there to a minimum — and so the properties intact.config.json
had to be re-purposed to match the Blueprint approach to compilation.While this made it possible to better configure Blueprint behavior in Tact projects, it introduced a significant discrepancy between the Tact compiler and Blueprint.
Suggestion for a better solution
Get rid of
wrappers/
(recently renamed tocompilables/
) completely in Tact projects and switch to usingtact.config.json
:blueprint create
, ask people if they want a new compilation entry point (project) added totact.config.json
. If yes, then modify its contents. If not, don't touch it :)blueprint build
, only show the projects as defined intact.config.json
.build/
folder may still be actively suggested as the output folder. With the full source oftact.config.json
, it wouldn't matter if users chose a different folder as long as they specified it there — Blueprint would just take TypeScript wrappers based on that.This change would:
tact.config.json
.compilerVersion
and/or projects (entry points) for compilation in a single, well-documented place with auto-completion and hover suggestions provided byconfigSchema.json
.Useful links:
tact.config.json
description in the Tact documentation: https://docs.tact-lang.org/book/configcompilerVersion
reference in another topic: Make Tact version configurable #100 (comment).The text was updated successfully, but these errors were encountered: