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:
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.
That’s a great post! (I was going to link it too )
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.
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.
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
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.
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?
@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.
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?
I’d love to have importmap support in Django! In Media specifically, as I foresee any JS code with dependencies would be better off using an import map. We’re discussing this here: Rejuvenating vs deprecating Form.Media.
There’s a DEP in progress, currently moving slow because importmap browser support hasn’t been good enough for me to be able to use it on projects until a few weeks ago.
Yes, thank you! I saw that discussion you linked and I replied to it a few days ago. I’m ok moving that discussion about importmaps otver there as it fits that broader discussion and I’d love to see contributors experiment with my modest importmap package and extend its features.
I may submit a talk for next FOSDEM’s Python room to get the discussion going.
I am excited to see that a growing people cares about ESM support in Django.
I have been steadily pushing my projects to switch to ESM and Web Components. I also created the Django-ESM package, which brings importmaps to Django.
If I can be of any assistance in progressing this topic, I’d love to contribute.
Until this goes mainstream into Django, I’d also love to get more contributors on board for Django-ESM, so if you are curious to join, please don’t hesitate to ask.
Hi! It seems our projects have different goals. Unless I’m wrong, your project seems automatically generate importmaps from node_modules wheras mine mainly aim to propose a Python standard to explicitely declase them to allow IDEs to parse thems and propose autocompletion in JS files. I’m not saying they are mutually exclusive but my goal is to propose a standard that is independant of NodeJS.
Hi, thanks for responding. Interesting, yes, that seems different. Might I ask why’d introduce a standard in Python/Django? It seemed handy that Node.js comes with a dependency resolver, cryptographic integrity and support for tools like Dependabot. I’d be curious to understand the motivation to use a tool detached from Node. Cheers! Joe
Because there are a lot of projects that don’t use Node and don’t wish to. Producing a standard for them would allow to enable autocompletion for static files based on what’s declared in importmap.py.
)