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 (https://github.com/tact-lang/tact/issues/574), the Tact and Blueprint would become even more driven apart. And that's not good :)
Current solution
In PR https://github.com/ton-org/blueprint/pull/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.jsonas it's used in Blueprint.Furthermore, with upcoming introduction of things like
compilerVersiontotact.config.json(https://github.com/tact-lang/tact/issues/574), the Tact and Blueprint would become even more driven apart. And that's not good :)Current solution
In PR https://github.com/ton-org/blueprint/pull/96, the auto-sourcing of
tact.config.jsonwas 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.jsonhad 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.compilerVersionand/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.jsondescription in the Tact documentation: https://docs.tact-lang.org/book/configcompilerVersionreference in another topic: https://github.com/ton-org/blueprint/issues/100#issuecomment-2227454565.