Eigene Bundle-Namen und Grenzfälle

Ein abweichender BundleName erzeugt einen eigenen Endpunkt. Das ist schnell gemacht — und genauso schnell übersehen, dass ihn niemand ausliefert.

Was passiert

public class BerichteBundleScriptSetup : IJavaScriptProvider
{
    public string BundleName => "fmh-berichte";

    public int Order => 100;

    public IEnumerable<string> GetJavaScriptPaths()
    {
        return ["_content/FMH.Komponente.Berichte/lib/chart/chart.js"];
    }
}

Daraus entsteht /bundle/fmh-berichte.js. Der Endpunkt funktioniert sofort — aber keine Seite lädt ihn. _HeadIncludes und _BodyIncludes der Basis kennen nur die sechs Standard-Adressen.

Die Einbindung ist deshalb Sache der Hostanwendung, im Layout oder in einer einzelnen View:

@section Scripts {
    <script src="/bundle/fmh-berichte.js"></script>
}

Genau darauf weist auch der Kommentar an BundleKonstanten.FmhScriptBundleName hin: alternative Namen sind möglich, dann müssen die Bundles jedoch eigenständig eingebunden werden.

Sinnvoll ist ein eigenes Bundle, wenn eine grosse Fremdbibliothek nur auf wenigen Seiten gebraucht wird — sonst zahlt jede Seite dafür. Für alles Übrige ist fmh-scripts der richtige Ort.

Im Repo gibt es derzeit kein frei gewähltes Bundle. Am nächsten kommt dem fmh-bootstrap.css: Es existiert als eigener Endpunkt nur, weil BasisBundleBootstrapScssSetup einen abweichenden BundleName setzt — und wird entsprechend von Hand in _HeadIncludes eingebunden.

Leere Bundles entstehen gar nicht

Liefert kein Provider einer Gruppe Pfade, wird der Endpunkt übersprungen. Die Adresse antwortet dann mit 404, nicht mit einer leeren Datei. Wer also einen 404 auf ein Bundle bekommt, sucht nicht nach einem Auslieferungsproblem, sondern nach dem Provider.

Zweiter Kandidat für einen 404: die Adresse ist /bundle/ im Singular. /bundles/… hat im Repo schon einmal für Verwirrung gesorgt.

Grenzfall: native ES-Module

Der Bundler minifiziert mit NUglify, und NUglify versteht import/export nicht. Module gehören deshalb nicht ins Bundle — ein eigener Bundle-Name ist hier also nicht die Lösung.

Der richtige Weg ist der Modulkatalog über IModuleScriptProvider, beschrieben in «Native ES-Module einbinden». Er erzeugt keine Datei, sondern verwaltet Adressen, und er nimmt einem die beiden Fallen ab, die Module mitbringen: die Ausführungsreihenfolge gegenüber klassischen Skripten und die Revalidierung der transitiv importierten Dateien.

Nicht jedes Paket braucht einen Provider

Eine Komponente ohne eigene Dateien braucht keine Bundle-Konfiguration. Zwei verbreitete Fälle:

• Styles in der Basis. Gehört das Aussehen fachlich zum Corporate Design, liegt die Partial in der Basis und kommt über deren style.scss ins Bundle. Das Komponenten-Paket bleibt ohne Provider.
• Skript zur Laufzeit erzeugt. Wird die Client-Logik aus einem Builder heraus geschrieben (Html.Script() / PostScript()), landet sie über _BodyIncludes in der Seite und hat mit dem Bundle nichts zu tun.

Auch die Hostanwendung selbst muss ihre eigenen Dateien nicht bündeln — dort genügen direkte ~/…-Tags im Layout.