search

rails / importmap-rails

Use ESM with importmap to manage modern JavaScript in Rails without transpiling or bundling.
MIT License
1.07k stars 120 forks source link

Multiple importmaps #240

Closed manuelmeurer closed 1 month ago

manuelmeurer commented 9 months ago

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 commented 9 months ago

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

manuelmeurer commented 9 months ago

@deanpcmad Feel free to use my fork/branch as described in the PR for now: https://github.com/rails/importmap-rails/pull/241 I use it in production and it works great!

sarmad90 commented 9 months ago

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

sarmad90 commented 9 months ago

@manuelmeurer I have added some comments on the PR.

aseroff commented 8 months ago

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 commented 6 months ago

Definitely need this. any progress?

manuelmeurer commented 1 month ago

Fixed by #253.

henrikbjorn commented 1 week ago

@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 https://github.com/rails/mission_control-jobs/pull/175, fixed by https://github.com/rails/mission_control-jobs/pull/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 commented 1 week ago

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 https://github.com/rails/mission_control-jobs/pull/163.

henrikbjorn commented 1 week ago

@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 commented 1 week ago

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 commented 1 week ago

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

I have taken a stab at it with https://github.com/henrikbjorn/importmap-rails/commit/ef4df9c365097dfbdb15189d17feea847d2484ad 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 ?