Warn when a module's JS hooks will never be loaded

[alexdont]

From the integration report, item #7 — the one the boards 0.3.0 and 0.4.0
incidents were both symptoms of.

The trap

A module declares its hook bundle with js_sources/0. The only thing that
consumes that declaration is the :phoenix_kit_js_sources compiler. A host
without it in :compilers gets nothing — no vendored bundle, no error, no
warning. window.PhoenixKitHooks never gains those hooks, while the module's
templates go on rendering phx-hook="..." names the LiveSocket has never heard
of.

That is the worst shape a failure can take. The page renders, the module looks
installed, and only the half that needed JavaScript is missing — so it reads as
"this module is broken" rather than "its JS never loaded". phoenix_kit_boards
shipped exactly that state twice before anyone traced it, and a host running the
CSS compiler but not the JS one (the reporter's app, and an easy asymmetry to
end up with) lands there without ever having made a decision.

The warning

phoenix_kit_routes() runs while the host's router compiles, which is the one
place that can see both facts: what is installed, and what is in :compilers.
When any installed module declares a bundle and the compiler is absent, it names
the modules and the line that fixes it.

Silent when the compiler is present, and silent when nothing declares a bundle.
That restraint is the point — a warning that fires on correctly-configured hosts
is one people learn to scroll past, which is how we got here.

Verified against a real host both ways:

=== compiler PRESENT (expect silence) ===
0
=== compiler REMOVED (expect the warning) ===
warning: PhoenixKit: these modules ship JavaScript hooks that will not be loaded:
PhoenixKitBoards
PhoenixKitReferrals

It can never fail a host's compile: discovery is rescued, and the Mix lookup is
guarded for contexts where Mix isn't loaded.

The stale rationale

The compiler's moduledoc opened with:

A LiveView JS hook must be present in the host's single LiveSocket at
construction time — a nested LiveView cannot register one at runtime.

Not true since LiveView 1.1. getHookDefinition/1 resolves a hook name when its
element mounts and falls back to a script[data-phx-runtime-hook="Name"] in the
document; LiveView re-creates such a script when a patch adds it, so it works for
a page delivered over the socket too. (Verified against the 1.2.x source while
building the boards fix, not taken on trust.)

So a module can deliver its own hooks and ask nothing of the host — which is
what phoenix_kit_boards does now. Leaving the old reasoning in place tells the
next module author that host wiring is unavoidable when it isn't. Rewritten to
say what the compiler actually is: the cheaper path where it's set up, not the
only one.

Testing

Six tests on the decision itself. The first version reached it through real
module discovery, which meant the interesting branch only ran on a host that
happened to be misconfigured — i.e. never, in this library's own suite. Split
into a two-argument form so both branches are exercised directly.

Both directions mutation-tested: silencing the warning fails three tests,
removing the "configured" guard fails one. (My first attempt at the former was
invalid Elixir and only produced a compile error, so it proved nothing — redone.)

705 web tests pass, credo --strict clean, compiles with --warnings-as-errors.

Scope

Only #7 (plus its moduledoc). On the rest of the report, three corrections worth
recording:

• feat: Add user creation and editing functionality with LiveView #1 and Updated the comments in users_live html file, and added Modules link in dashboard. #2 are not core. Comments is a separate package,
  phoenix_kit_comments (0.2.13). The resource model and the zero-width-space
  GIF placeholder both live there.
• Add Sesion manage, whith auto log-out while role change. Live data update for admin boards whith broadcast. #4 already exists.Auth.merge_user_custom_fields/3 does the atomic
  COALESCE(?, '{}'::jsonb) || ? merge the report asks for, and its docstring
  says to reach for it whenever the intent is "add/update these keys, leave
  everything else as any concurrent writer left it". There is a
  delete_user_custom_field/3 too. The host's 13 call sites are calling the
  wrong function — a real race in that app, a discoverability problem here. A
  one-key put_user_custom_field/3 convenience would be a fair addition.
• Add profile settings and fix router integration #3, Add live data updates system for admin panels and comprehensive session management system for admin interface #5, Add live data updates system for admin panels and comprehensive session management system for admin interface #6, Fix magic link URL path to match router definition #8 and the rest of Moved date.ex to Utils folder, and made the date formatting much simpler to use in the layouts #9 are untouched and still stand.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NTj7hm3fpCTcFvKLRtgppW