Analysis of templ AST for tooling and framework development

[tylermmorton]

The ability to inspect (and modify) component AST directly is a huge boon for tooling developers in the JSX/React world. This enables things like prettier and eslint to format and lint code effectively. It also opens the door for code migration via AST (dubbed codemods), where transformations are run against UI codebases automatically.

At another level, while building a MVC system, it may be helpful for the controller to inspect the view layer for certain properties. A great example of this is Remix's 'nested routes', where an <Outlet/> element is added in the view layer, and the controller layer then knows to look for that tag and handle the nesting logic.

I wanted to bring this up as a topic of discussion, because to me, great support for static analysis is vital to so many parts of web development. FWIW html/templates have ParseTrees that enable this type of work.

I will have to dig around in a-h/templ/parse package to see what is available. Is there a public API that is meant for this use case and are there any examples of tools being developed with it?

Also I know that templ files are compiled at build time and converted into Go functions so all of the templ AST is unavailable during runtime. I'm wondering if there is a runtime variant of the compiler that could be used in situations where server frameworks need to inspect template structure?

Thanks in advance for the discussion!

[joerdav]

I agree that this would be great for developing external tools, such as stricter formatters with rules that are too opinionated to be the defaults, and even security checkers.

I do believe that the current parser package should be able to support this use case though I've not seen any examples yet. There could be some quality of life changes that would make this easier such as a Walk method to iterate nodes.

[dgrundel]

Apologies for resurrecting a fairly old thread. My team is using Templ in a large project with lots of contributors and we're creating a Templ linter to help enforce some of our own coding standards.

Part of creating a good linter is being able to point to a specific source location where problem code exists. However, this is a challenge using the existing AST nodes. Many of them do not include a Range, while others only provide a Range for part of the source (e.g. Element provides NameRange).

@joerdav I did also have to implement my own Walk function. :D

Any opposition to a pull request that would add additional position information to existing nodes? Have a preference as to using Ranges or simple indexes?