Integrate `importmap`

Django Internals
1

So <script type="importmap"> are a thing, now, providing a standard way to instruct JS’ import operator how resolve symbols.

I think Django should integrate that HTML feature in the form of a new settings.IMPORTMAP dictionary setting and a new {% importmap %} tag.

This would provide a Django way to generate import maps, as well as providing IDE’s like PyCharm a central reference to provide autocolpletion in JS files.

I’m still unsure, however, how to integrate with {% static %}. Maybe this settings could be parsed so that it can be used like in templates:

# settings.py
IMPORTMAP = {
    "imports": {
        "my-module": "{% static 'js/my-module.js' %}"
    } 
}
2

There’s already a third-party package playing with import maps: Implementing the strategy pattern in Django with JavaScript import maps . That’s worth checking out.

It’s not clear to me that having some kind of import map integration in Django settings provides much value. I can also imagine projects may need more than one import map, if they have separate areas using different packages.

1 Like
3

That’s a great post! (I was going to link it too :slightly_smiling_face:)

In general, with these kind of things, we need to do lots of experimenting — to settle on a best approach — before we can really think about a proposal for core. (Django’s long-release cycle, and API stability policy mean it’s not somewhere we can experiment.) I think we’re a way off anything close to settled in this area. I hope that makes sense.

4

Of course, I’m just opening the discussion here. To me, the main pro is less the feature itself rather than providing a standard mecanism for IDE’s to provide a performant autocompletion in JS files, similar to what a Webpack integration proposes. I agree it’s not a game-changing feature but it’s a nice quality of life improvement IMHO et it shouldn’t be difficult to implement.

5

I’m not sure about settings…

I’ve always thought of importmap as something that could replace/complement (at least for JS) the current Media class approach and could hopefully make it something more general (AFAIK Media is only used for forms and the admin)

This is why I’m skeptic about having this as a setting, I would see this more as a system with a templatetag and a registry where views, forms, components or whatever could register assets needed for a page.
I could see a “seed” provided in settings (ie: htmx and bootstrap or whatever else) though

1 Like
6

Fair enough. How about a new per-app importmap.py exposing an importmap variable, like urlpatterns and url.py? This can then be exposed globally through a context processor, lile request is. This way, it is fully accessible and modifiable in views and templates.

I think I could write a simple POC demonstrating how this could work.

1 Like
7

Ok, so here’s my proposition. It’s still very rough and not tested at all, probably buggy. It’s just to show a glance at the solution I have in mind. WDYT?

8

@christophehenry This is precisely the sort of thing that should be done first in a third-party app.

Experiment, play around. See what works. See if folks like it. Let it mature. (Then propose it for core.)

You likely think that’s annoying but with Django’s slow release cycle and stability guarantees it really is the best way. It’s a big part of Django’s longevity and success.

9

I’m totally cool with a 3rd party app first. I just don’t want the discussion to slowly die. Is there anyone else interested in this feature willing to provide feedback and make it evolve?

10

So I started dj-importmap to develop this feature. It’s still very stimple but it’s working. Don’t hesitate to provide feedback if you’re interested.

3 Likes
11

Cool. Nice one. I posted it to Mastodon too.

1 Like