Ability to do simple checks on template tag content

[lb-]

Is your proposal related to a problem?

• there are some Django template conventions we would like to enforce with a linting rule
• example: require using trimmed with blocktrans

Describe the solution you’d like

• template tag requires - a configurable list of regex (might be simplest) that runs inside any template tag usages (in Django those with {% ... %}

Describe alternatives you’ve considered

• add a custom tool that does a regex parse across all html files within a folder
• monkey patch the Django template system (or add a custom template order that extends the Django one), when running in test or Dev mode any template tags that do not conform will throw an error

Additional context

• Django blocktrans reference https://docs.djangoproject.com/en/4.0/topics/i18n/translation/
• Wagtail is likely to adopt blocktrans using trimmed across all translations - https://github.com/wagtail/wagtail/pull/8226 & https://github.com/wagtail/wagtail/issues/8217
• there are a few other translation behaviours we would love to enforce at the template level - https://github.com/wagtail/wagtail/discussions/8017
• this is kind of similar in concept to eslint no-restricted-syntax https://eslint.org/docs/rules/no-restricted-syntax

[thibaudcolas]

Hi @lb- :) I’ve been working on such a blocktrans trimmed rule, but with a JS version of curlylint, not the Python one currently available here.

Technically what you’re describing is already possible – Curlylint creates an AST from templates with nodes for DTL/Jinja syntax, as well as HTML. The node you’re looking for here is JinjaTag, specifically its content property.

The main issue to implementing this is that Curlylint currently provides the raw AST to each and every linting rules – most linters implement the visitor design pattern, which makes implementations much simpler.

[lb-]

Hmmmm interesting - a JS version - I guess it's just html so doesn't really matter what is used.

Now I see why you were not a fan of the make lint rule server / client separation.

However, it does add another ecosystem for template linting that some projects may not be keen on adopting.

Nonetheless - I might try to understand what you mean by visitor pattern and see what is possible with this library instead

[thibaudcolas]

@lb- it’s definitely possible with this library, visitor pattern or otherwise. The visitor pattern is just one of the most common ways to structure code working on tree structures, ASTs in particular. Here’s an example Python implementation. The consequence of not having it is "just" that every linting rule currently needs to reimplement its own variant of AST parsing :)

The main reasons I’m keen on trying out a JS version of curlylint is that:

• The parser of the Python version, built with parsy, is hard to work with and doesn’t perform well (#124). It’s unclear to me whether those issues are with the implementation or with the underlying library, but there are a few warning signs – Parsy relies a lot on recursive function calls, in a language where function calls have a very clear performance cost. I haven’t seen many examples of Parsy being used in scenarios where the parsing is quite complex (template syntax + HTML syntax), and time-sensitive (linting ideally happening in code editors)
• I have a bit of static analysis experience with Prettier, ESLint, Stylelint – all of which are written in JavaScript.