NPM Packages in Experience Builder 1.8
1039
1
06-13-2022 02:28 AM
by
NiklasKöhn
Beim Hochziehen einiger NPM-Pakete in ExB 1.8 Widgets bin ich über das Problem gestolpert, dass Webpack 5 keine Polyfills für Node Core Modules mehr beinhaltet. Das äußert sich in der Fehlermeldung "BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default", un dat heiß op hoochdeutsch:
Pakete, die Kernfunktionen von node.js verwenden, funktionieren nicht mehr nativ mit Webpack 5.
Auf der Suche nach einer Erklärung erschien mit folgende plausibel: "Webpack 4 automatically polyfilled many Node APIs in the browser. This was not a great system, because it could lead to surprisingly giant libraries getting pulled into your app by accident, and it gave you no control over the exact versions of the polyfills you were using. So Webpack 5 removed this functionality." (Quelle)
Beschreibungen zur Abhilfe finden sich viele, direkt in den Fehlermeldungen in der Konsole und auch unter o.g. Quelle: Die benötigten Quellen müssen in der webpack.config unter resolve.fallback eingetragen und per 'npm i' installiert werden.
So weit so schön. Nur ist diese Konfiguration im ExB zerhackt und auf mehrere Dateien verteilt worden:
Von links nach rechts:
- webpack.config.js im "client" Root-Ordner referenziert webpack-extensions.config.js im Unterordner "webpack"
- webpack-extensions.config.js bastelt sich die Config aus Referenzen zu webpack-extensions.common.js zusammen
- in webpack-extensions.common.js kommt das resolve-Objekt an 3 Stellen vor, nämlich ingetTemplatesWebpackConfig(), getWidgetsWebpackConfig() und getThemesWebpackConfig(). Hier wird die Property fallback eingetragen, deren Inhalte (analog zu den anderen Props) in webpack.common.js eingetragen werden.
- in webpack.common.js schließlich stehen die Referenzen auf die "einzufüllenden" Pakete unter exports.fallback.
Dat funzt.
Blöd daran ist, dass die Webpack-Dateien auf Root-Ebene des "client"-Ordners nicht im Code-Repository stehen, sondern mit dem ExB geliefert werden. Der ExB bietet ja genau den Vorteil, eigene als "exb-web-extension-repo" markierte Git-Repos einhängen zu können, und so nur den eigenen Quellcode in der Quellcodeverwaltung zu haben (ohne irgendwelche wilden Kopier-Vorgänge in den Build-Prozess einzuhängen wie vor Jahren mit Gulp für Web...von uns umgesetzt). Verwendet man nun in seinen Custom Widgets NPM-Pakete, die Polyfills benötigen, muss man an die Webpack-Configs, die aber nicht im Repo stehen. 
Meine Lösung: Ich habe in meinem Repository einen Unterordner namens "_webpack5-config-updates" angelegt, der als ersten Commit die originalen mitgelieferten Configs enthielt. Im zweiten Commit sind dann meine Ergänzungen, sodass man auch noch nachvollziehen kann, was sich denn getan hat.
Das wird genau dann wichtig, wenn man mehrere Repos einbinden, die jeweils ihre eigenen Polyfills benötigen. Denn dann muss man sich die Configs manuell anschauen und alle benötigten Polyfills in die Webpack-Configs im "client"-Ordner aufnehmen
Genau das ist auch der Grund, warum die Lösung nicht so richtig cool ist.
Wer hier Ideen hat - bitte gerne melden und diskutieren!
1 Comment