In the end, the cleanest way is to forgo the bells and whistles, and require users to add the static types themselves.

Next I tried code generation with overloads. Similar to how Prisma works - A command generates the static types, inserts it into package (site-packages), and Mypy picks it up. After some trial and error I got it working. But... Mypy was always picking the first overload...

I had a good mileage with Generics. But subclassing classes with generics is crazy verbose - You have to re-define all generics, and use the `default` field as the values you actually want.

Hand-in-hand with the TagSpec, I also wrote a parser that takes Django template tag's input (the string between {% %} ), and sorts and parsers it into args, kwargs, flags, etc.

The parser converts the tag's input into AST that describes each arg / kwarg / flag, and even each filter separately

The tag spec makes it possible to programmatically manipulate with the Django template tag's definition - I used for the docs for django-components to automatically generate the template tag signature from the spec.

6/5 Create a mid-sized demo project that showcases how to use django-components

This has been irking me too. My thoughts were to replace the ORM with prisma python client, but ofc that doesn't play well with current Django

See I did that in django-components. Would it make sense to make that code into a standalone package?

github.com/EmilStenstro...

So if I was writing such LSP, the for custom template tags, I would ask users to define their template tags as these "TagSpecs", so the LSP would know how to handle their custom tags. And for built-in Django tags, the LSP would have their "specs" hard-coded.

For Django-components I wrote code for declaring template tag API - so one defines upfront which args, kwargs, and flags the template tag may take. And the parser uses this "spec" to know how to parse the template tag inputs. This way the template tag API is codified, e.g. to the generate docs.

For built-in tags, this is not an issue - you can use Django's documentation and hard-code that into the LSP. But for custom template tags, I can't imagine how you could use vanilla Django template tags with LSP for e.g. autocompletion.

One issue I expect is that Django doesn't define the API of the template tags very well. It just splits up the string inside {% %}, and leaves the rest up to the user. User could use Django to parse the template tag inputs as args and kwargs, but they might not.

Do I imagine right, that the user would define the path to the Django settings file, and then your spawned process would use that to set up Django? And that's how you could then figure out which template tags are available?

Love that! Lack of LSP for Django's been irking me too. In the end what I wanna try is to allow to write Vue files directly for Django. Because I want to write JS-heavy components, and Vue already has tooling for that. I would still need to fork their code to allow for extra python section.

I'm thinking of the same for django-vue. Barely working, but getting the idea out there sounds worth it. IMO do it!

Best of luck! My there's a lot of room for improvement. I was thinking about that too, with FastAPI as the server, and Prisma as the ORM. Have a look here for more ideas:

docs.google.com/document/d/1...