Which templates a site can actually reach, and therefore which classes its stylesheet must carry.

A UI kit is installed once and shared by every site, so its components are written to runtime/__global__/component/*.template and the CSS compiler used to glob the whole directory. With Chelekom that is 251 templates and 2.1 MB — the great majority of everything the compiler scans — and a site that uses one alert paid for all of it on every page load.

Reachability is decidable here, because a component reference in a runtime template is a literal:

<.component component_name="chelekom-alert" site="localhost">

So the reachable set is a graph walk from a site's ROOTS: the pages and error pages a visitor can ask for, plus the layouts those pages use. Everything else earns its place by being named. A component's scope decides where it may be USED, never whether its CSS ships — a global component reaches a site's stylesheet on exactly the same terms as one of the site's own, by that site rendering it.

Components compose, so the walk is transitive: chelekom-form-wrapper pulls in chelekom-error, which pulls in chelekom-icon.

Roots

A page and an error page are roots because a visitor can ask for either directly. A LAYOUT is not: it is chosen by a database relation rather than named in markup, so it cannot be walked to from the text alone. Treating every layout as a root meant a site with thirty layouts and five pages scanned twenty-five it can never render, and put every GLOBAL layout into every site's stylesheet. MishkaCmsCore.Runtime.Compilers.TailwindCompiler.closure_roots/2 reads pages.layout_id and passes the layouts a site's pages actually name; the default here is what a bare directory can know on its own, which is the pages and error pages.

An error page needs no layout root: BootHandler.build_error_template_content/1 already writes its layouts' markup into the error template itself.

A component named through its own attribute

A component may draw another it is told the name of:

<.component component_name={@card} site={site_name()} doc={row.doc} />

When card is an attribute the component declares and never assigns itself, the names it can take are known: its default, when that is a non-empty string, and every literal a reached caller writes for it — <.component component_name="doc-workspace-list" card="doc-card" …>. Those names are walked as literal references are. The component they name may hand a name on in turn, so the walk repeats until nothing new is reached.

WHICH ATTRIBUTES QUALIFY IS DECIDED WHERE THE COMPONENT'S CODE IS AT HAND, when its template file is written: attribute_marks/1 writes a line per attribute into the file and the walk reads it back, so it asks nothing of the database. component_name={@name} in a file with no line for name — not declared, assigned by the component's own code, read inside a helper, or a file written before these lines existed — is a reference the walk cannot resolve.

When the answer is "everything"

A reference the walk cannot resolve makes the closure unsound, and for_site/2 returns :unbounded. Callers must fall back to globbing the whole directory. This is the whole safety story: an under-approximated closure means a component renders with no CSS at all, which is worse than a large stylesheet, and it would show up in production rather than in a build.

A reference cannot be resolved when, in a reached template:

• component_name={…} is any expression but {@name}, or {@name} sits in a page, a layout or an error page, or a <.component> tag names nothing and spreads {…};
• {@name} names an attribute the file has no line for;
• a call to a component that names one through name hands name over as an expression (card={…}), or spreads {…} into the tag, or draws the component from stored content, whose markers an author writes — that CALLER is the template named;
• once anything is named through an attribute, a template calls component(…) or send_update(…) from code, or holds a <.component> tag the walk cannot read.

Each degrades to correct-and-large rather than small-and-broken.

reached_components/2 answers what the walk did reach either way, for a caller that needs only what is certainly reached — the components a page builds before it draws them (MishkaCmsCore.Runtime.ComponentPrefetch).

Which copy of a component

A stylesheet looks a name up in the site's own components first and in the global ones after, and either copy found is scanned. reached_components/2 answers which MODULE a render draws, so it reads the tag's site as MishkaCmsCore.Runtime.LiveViewHelpers.component/1 does:

• no site, or site="Global" — the global component;
• site="<this site>" — the site's own, and nothing when it has none;
• site="<another site>" — nothing, as the render refuses it;
• site={assigns[:site]} or site={@site} in a component — the scope that component was found in;
• any other expression, and a name written outside a tag — the site's own, else the global one.

Components named in stored content

A template that draws stored content — <.rich_content …/> — reaches the components the content's markers name, which no template shows (MishkaCmsCore.Runtime.ContentComponents). The caller passes those names as :content_components, and such a template names exactly them, each resolved as a component_name="…" is. A site where nothing reached draws content reaches none of them.

Usage

CssClosure.for_site("localhost")
#=> %{components: ["chelekom-alert", "chelekom-icon"], templates: [...], scanned: 8, dynamic: [],
  #=> resolved: []}

See MishkaCmsCore.Runtime.Compilers.TailwindCompiler, which turns the result into @source lines, and Mix.Tasks.Mishka.Css.Closure, which prints it.