support Jinja2 template backend

[anentropic]

I was hoping to use this in a Django+Jinja project.

Looking at this issue: #8 ...a solution is provided in the comments by @wizpig64

It works quite serendipitously because the tags in django-vite are all using @register.simple_tag decorator... and that ultimately returns the decorated function untouched (it just does registration as a custom tag).

The other decorator applied is @mark_safe, which promotes the return value to SafeString str subclass... which will have no effect for Jinja, but is harmless.

And that works ok currently because Jinja does not autoescape by default (otherwise because it's not 'marked safe' for Jinja the rendered HTML tags from django_vite would get escaped if you have autoescape turned on... the docs hint that may become default in future).

I think the only django-jinja specific part in the comment is the TEMPLATES["OPTIONS"]["globals"] setting. But for other usages you can do the same thing by updating the env.globals attr of your jinja2.Environment instance.

Given the caveats above I have prepared this PR to explicitly provide a Jinja extension that is safe for autoescaping, and still taking advantage of the fact the tags can share a common implementation.

[Niicck]

Thank you for this contribution! This feature looks good and I appreciate the docs and tests.

I'd have one request -- since @marksafe and @simple_tag don't have any impact on jinja, can we keep the original django_vite.py templatetags file in place and just import those straight into the jinja.py templatetags file? I'm not sure what the new base.py gets us, and I find it cleaner to have the decorators directly attached to the templatetag they belong to. I think this PR could get away with only needing extra wrappers around the jinja tags.

[KevinMind]

Is this PR stale? I have the same desire to use this lib with an existing jinja2 based project and wondering if this is something that could be picked up?

[anentropic]

I'm not sure what the new base.py gets us, and I find it cleaner to have the decorators directly attached to the templatetag they belong to. I think this PR could get away with only needing extra wrappers around the jinja tags.

each template engine needs different decorators applied

the point of the base.py was to apply only the specific decorators for each template engine, rather than rely on accidental property that the Django decorators are currently a harmless no-op for Jinja