NPM Packages in Experience Builder 1.8

NiklasKöhn

When pulling up some NPM packages in ExB 1.8 widgets, I stumbled upon the problem that Webpack 5 no longer includes polyfills for Node Core Modules. This manifests in the error message "BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default", <\/SPAN>and that means in High German:<\/EM><\/DIV>Packages that use core functions of node.js no longer work natively with Webpack 5.<\/STRONG><\/DIV> <\/DIV>In search of an explanation, the following seemed plausible to me: "Webpack 4 automatically polyfilled many Node APIs<\/STRONG> in the browser. This was not a great system, because it could lead to surprisingly giant libraries<\/STRONG> getting pulled into your app by accident, and it gave you no control over the exact versions of the polyfills you were using. <\/SPAN>So Webpack 5 removed this functionality." (Source<\/A>)<\/SPAN><\/DIV>

 <\/DIV>

Descriptions for remedies can be found

many<\/A>, directly in the error messages in the console and also under the above source: The required sources must be entered in the webpack.config under resolve.fallback and installed via 'npm i'.<\/STRONG><\/DIV> <\/DIV>So far so good. Only this configuration in ExB is fragmented and distributed across several files:
<\/span> <\/P>From left to right:<\/SPAN><\/P>webpack.config.js<\/EM> in the "client" root folder references webpack-extensions.config.js<\/EM> in the subfolder "webpack"<\/LI>webpack-extensions.config.js <\/EM>assembles the config from references to webpack-extensions.common.js<\/EM><\/LI>in webpack-extensions.common.js<\/EM>, the resolve<\/EM> object appears in 3 places, namely ingetTemplatesWebpackConfig(), <\/SPAN>getWidgetsWebpackConfig() and <\/SPAN>getThemesWebpackConfig(). Here the property fallback<\/EM> is entered, whose contents (analogous to the other props) are entered in webpack.common.js <\/EM>.<\/SPAN><\/DIV><\/LI>in webpack.common.js <\/EM>, finally, the references to the "to be filled" packages are under exports<\/SPAN>.<\/<\STRONG><\/<\EM>fallback.<\/<\EM><\/<\DIV>This works.<\/DIV> <\/DIV>The annoying thing is<\/STRONG> that the Webpack files at the root level of the "client" folder are not in the code repository but delivered with ExB. ExB offers exactly the advantage of being able to mount your own Git repos marked as "exb-web-extension-repo" and thus only having your own source code in source control (without hooking any wild copy processes into the build process like years ago with Gulp for WebApp Builder projects implemented by us <\/<\A>). If you now use NPM packages that require polyfills in your custom widgets, you have to get to the Webpack configs, which are not in the repo.<\/<\STRONG> <\/<\DIV> <\/<\DIV>My solution<\/<\STRONG>: I created a subfolder named "_webpack5-config-updates" in my repository, which contained the originally supplied configs as its first commit. The second commit then contains my additions, so you can still trace what has changed.<\/<\DIV> <\/<P>

This becomes important exactly when you want to include multiple repos that each require their own polyfills<\/<\STRONG>. Because then you have to look at the configs manual<\/<\STRONG> and include all required polyfills in the Webpack configs in the "client" folder.<\/<\DIV>This is exactly why this solution is not really cool<\/<\STRONG>. <\/<\DIV> <\/<\DIV>If anyone has any ideas<\/<\STRONG>, please feel free to report and discuss!

 <\/<P>

NiklasKöhn

Na gut, hier ist eine Idee. Um einfach wieder alle hinzuzufügen,  gibt es dieses Paket: https://www.npmjs.com/package/node-polyfill-webpack-plugin
Ich hab's nicht ausprobiert. Wer will?