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

[technophile-04]

Use special characters for variables like we already do (maybe something simpler than $$$)

Yeah I think there is no workaround to this variable scoping issue it's just javascript runtime evaluation problem.

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.

Yeah :( doesn't seem any straight forward way.

but for now looks like it's not worth to use handlebars at all and our solution is much better

Yup I was also tinkering with https://github.com/carletex/create-dapp-example/tree/feat/extenstion-templateConfig, I think yeah our's solution is simple also since it's .js its more convenient.

Some other things I explored which are used for code generation (an abstractions over handlebars, ejs) :

• plop
• https://www.hygen.io/

^ but not worth it

---

Btw we have this in TEMPLATING.md:

We've thought about how the strings should be joined, but an option is to use tagged templates. We can go as crazy as we want with tagged templates.

It's not clicking to me how tagged_templates will be helpful or they can be advantageous to us lol I see it solving some problems but not able to wrap my head around in our context. Just putting it out here if somethings clicks for someone.

But yeah I am kinda leaning towards #175 as well