Frontend Module Sync

Registers HACS plugins as Home Assistant frontend modules, using the URL HACS already registered — so you never hand-copy a ?hacstag= into configuration.yaml again.

The problem

Some HACS plugins need to load before the dashboard renders. card-mod is the clearest example: it patches Home Assistant frontend elements, so if it arrives after the cards do, styles are applied to cards that are already on screen — a visible flash of unstyled content.

The documented fix is to also register the plugin as a frontend module:

frontend:
  extra_module_url:
    - /hacsfiles/lovelace-card-mod/card-mod.js?hacstag=1316268191430

That URL must match the HACS-registered dashboard resource exactly. ES module resolution keys on URL, so a mismatch of even one query character loads the plugin twice — and applies its patches twice. And HACS regenerates hacstag on every update, so the hand-written copy goes stale each time the plugin is upgraded.

What this does

It never writes the URL down. On startup it reads the Lovelace resource registry, finds the entries matching your patterns, and registers those exact strings via Home Assistant's frontend.add_extra_js_url(). The two registrations cannot drift apart, because there is only one source of truth.

It also follows the resource collection, so when HACS updates a plugin and rewrites its URL, the frontend module is re-pointed to match — no restart, no edit.

Installation

Add this repository to HACS as a custom repository (category: Integration), download it, and restart Home Assistant. Then:

frontend_module_sync:
  match:
    - lovelace-card-mod

match is a list of substrings tested against each Lovelace resource URL. Each matching resource is also registered as a frontend module. Keep the HACS-managed dashboard resource as it is — this adds to it rather than replacing it, which matters because frontend modules are not delivered to Google Cast devices.

Remove any manual extra_module_url entry for the plugins you list here, or you will be back to maintaining it by hand.

Does my plugin need this?

Most do not. It is worth it for plugins that patch frontend elements or must run before cards render — card-mod being the main one. If a plugin works fine as an ordinary dashboard resource, leave it alone: frontend modules load on every page, not only on dashboards, so this trades a little startup cost for earlier availability.

Measured effect

Home Assistant 2026.7.4, a dashboard with 15 card-mod-styled cards, measuring from the first ha-card appearing in the DOM to the first style being applied:

card-mod delivered as	fetch begins	flash
dashboard resource only	490 ms	161 ms
frontend module	88 ms	84 ms

Your numbers will differ. The point is the shape: loading early roughly halves the window in which cards are visible but unstyled.

Requirements

Home Assistant 2025.2.0 or newer. That is where LOVELACE_DATA and the LovelaceData dataclass were introduced (core#136313); on older versions the import this integration relies on does not exist.

Notes and limitations

• Reads hass.data[LOVELACE_DATA].resources, a Home Assistant internal. If it changes in a future release this integration stops registering modules — visibly, since the plugin reverts to loading as a plain resource, not silently.
• YAML-mode dashboards are supported; the resource collection is read either way.
• Logs at info when it registers or unregisters a module, and warns if no resource matched your patterns.

Why this should live in HACS instead

HACS already calls add_extra_js_url() for its own iconset. If plugins could opt in through hacs.json, the plugin author would declare the need once and every user would get it — no per-instance configuration, and this integration would become unnecessary. That is filed as a feature request; this repository is the working proof that the mechanism is sound.

License

MIT