Multiple importmaps

[manuelmeurer]

Maybe I'm missing something, but shouldn't it be possible to have multiple separate importmaps? :)

My app has three distinct parts/namespaces ("web" for the public marketing page, "admin" for the admin area, and "clients" for the login area for clients) and for each I'd like to have different pinned (and preloaded) modules.

Right now I'm solving it by keeping three different Importmap::Maps around and delegating Rails.application.importmap to Current.importmap, which loads the correct importmap for the current namespace, but that seems to be much more complicated than it should be.

I'm sure I'm not the only one that has multiple distinct namespaces in their app? :)
Is there another way to solve this?

Happy to have a stab at implementing this if it's a welcomed feature.

[deanpcmad]

I'd also like to see this. Would be very useful for splitting up public/admin JS

[manuelmeurer]

@deanpcmad Feel free to use my fork/branch as described in the PR for now: #241
I use it in production and it works great!

[sarmad90]

@manuelmeurer that's great. Let me know if you need any help in completing the PR. I would be happy to help.

[sarmad90]

@manuelmeurer I have added some comments on the PR.

[aseroff]

I +1 the need for this.
An approach I was considering taking is keeping a single importmap (since having unnecessary pins doesn't make a significant difference), but changing the pin's preload based on the provided import module tag.

To illustrate: javascript_importmap_tags expands to the importmap, the preloads, and the initial module import defined by the provided entry_point parameter. If we passed the entry_point parameter to javascript_importmap_module_preload_tags, we could enable the preloading to be defined by something like pin 'admin', preload: [:admin] in config/importmap.rb. The result would accomplish the desired result without having to maintain multiple importmaps.

If this seems agreeable I could throw a PR together.

[jimhj]

Definitely need this.
any progress?

[manuelmeurer]

Fixed by #253.

[henrikbjorn]

@manuelmeurer This is not fixed by #253

This will still allow for a gem to overwrite the names of the pinned dependencies eg pin_all_from "app/javascript/controllers", under: "controllers" (example rails/mission_control-jobs#175, fixed by rails/mission_control-jobs#163)

Or to include dependencies that will interfere with each other.

I don't really get how the preload: ['array', 'of', 'entrypoints'] is better than having config/importmaps/application.rb and config/importmaps/admin.rb etc. and then allow referencing those by name.

Having two or more separate areas of an application isn't that rare.

[manuelmeurer]

Well, #253 makes it possible to preload dependencies based on different entry points, which (for the most part) solves the same problem that multiple separate importmaps would solve. @dhh decided that this was sufficient.

Gems that include a separate area like Mission Control Jobs should always define their own importmap IMO, as implemented in rails/mission_control-jobs#163.

[henrikbjorn]

@manuelmeurer I don't see it as gems defining separate areas, being different from an application that have e.g a marketing frontend and an application / dashboard area.

So I believe closing this as fixed is not really true.

[manuelmeurer]

I agree of course, I would have been happy to see my solution of multiple importmaps accepted. 😄
But as mentioned, it was decided to go with another approach, which is also fine with me.
Why should we keep this issue open if a decision against implementing it was made?

[henrikbjorn]

Mostly because I think it is not solving a need or issue that people have.

I have taken a stab at it with henrikbjorn@ef4df9c which just keep all of the normal config/importmap.rb configuration and cli etc. So everything works as now

But additional importmaps can be defined in config/importmaps and accessed via Rails.application.importmaps.admin

I think this strikes a balance of keeping everything simple as it is today, but also allow for more complex applications and workflows.

@dhh What do you think about that approach ?