think about using template engine

[technophile-04]

Description:

Since we are planning to allow more customization (#170) and also early to do high breaking changes. It would be nice if we give a templating engine a shot (looking into all options handlebars seems very nice for use case but open for other options).

The reason for this is while tackling #174, #175 and with #135 we started reinventing wheel and creating our own solutions like having our identifier like $$$ for using vars, creating utils like stringify for allowing objects in .args.mjs etc.

Looking at current .template.mjs I think we need the following features:

1. Allowing template file(currently called as .template.mjs) to accepts args from extensions (currently passed via `.args.mjs)
2. Easily able to pass objects(with syntax highlighting) helpful for config files.
   • Objects can access arbitrary variables as well (which will be present in final full template)
   • mentioning somehow that weather this object will be merge with default SE-2 config or replaced (for certain files)
3. Passing of code snippets.
4. For future: We need to start thinking about this on how to allow multiple extensions as well (not in initial iteration but just to have it in back of our mind)
5. Not that imp: In --dev we create .dev files showing what args were passed.
6. DX for creating extensions remains same or at least improved(like current utils we have are in --dev mode symlinks)

We kind of have the above things working with current templating logic and utils but this workaround breaks when certain new use case comes up for example this where stringify util failed.

Let's try to research and tinker more with it and see if it better fits for us 🙌

Past discussions:

Search this quoted text in SE-2 core TG group(for some reason I wasn't able to copy link to message):

"I forked what Shiv made, and made some tweak in order to test point 2 (handlebars)." - Carlos creating v0.1 with hbs checkout video about it.

https://www.veed.io/view/24b6495f-32e7-4e31-84c4-f7c9ae922668?panel=share - Initial templating video of passing with args in handlebars.

Branch with handle bars : https://github.com/carletex/create-dapp-example/tree/feat/extenstion-templateConfig

"Testing an alternative to handlebars.... using a function." - Suggestion on using current version of templates instead of handlebars.

"then, for template files maybe do something different, where instead of the actual resulting file we create a special file like file.ext.dev.mjs" - Dani tinker on --dev mode so that we show what args were passed.

Dani's Initial Draft with templates literals (read RFC-extensions.md):
https://github.com/carletex/create-dapp-example/pull/2/files#diff-1c5bb9873a4d62b19f0844b00ade8d65295ffdd188d146cea2e9ce43e60e778a

[rin-st]

I created a repo to tinker with handlebars https://github.com/rin-st/tinker-handlebars , see README how to use it.

Current thoughts regarding this:

Objects can access arbitrary variables as well (which will be present in final full template)

I didn't find a good way to do it with handlebars. I see two ways:

1. Use special characters for variables like we already do (maybe something simpler than $$$)
2. Pass an object with variables, where every variable will be sent as string https://github.com/rin-st/tinker-handlebars/blob/main/different-objects/data.ts#L13 . But it already requires a lot of code to handle that object and to merge with other objects (see the whole helpers file) . Also, it's very inconvenient for our objects. See base example here and assume we need to use it for all the networks and all kind of different vars (arrays, process.env, ${...} etc, that logic is not even work for now)

You can also play with that repo, but for now looks like it's not worth to use handlebars at all and our solution is much better