For performance reasons, we'd like to avoid exposing the entire set of icons, because it's so large. Instead, I think we'll want to offer two options:

• Using a build step, tree-shake just the icons that are needed, and include those in the built bundle
• Allow RL modules to list the icons they need in their module definition, and build some ResourceLoaderImageModule-style magic to automatically add wvuiIcons.iconName = '...svg string...'; to those modules

In T275914#7156516, @Catrope wrote:

For performance reasons, we'd like to avoid exposing the entire set of icons, because it's so large. Instead, I think we'll want to offer two options:

• Using a build step, tree-shake just the icons that are needed, and include those in the built bundle
• Allow RL modules to list the icons they need in their module definition, and build some ResourceLoaderImageModule-style magic to automatically add wvuiIcons.iconName = '...svg string...'; to those modules

Neither one of those would work for onwiki scripts though, right?

In T275914#7156632, @DannyS712 wrote:

In T275914#7156516, @Catrope wrote:

For performance reasons, we'd like to avoid exposing the entire set of icons, because it's so large. Instead, I think we'll want to offer two options:

• Using a build step, tree-shake just the icons that are needed, and include those in the built bundle
• Allow RL modules to list the icons they need in their module definition, and build some ResourceLoaderImageModule-style magic to automatically add wvuiIcons.iconName = '...svg string...'; to those modules

Neither one of those would work for onwiki scripts though, right?

The latter could work for gadgets if we made the syntax simple enough and supported it in gadget definitions. For user scripts it wouldn't work, and we may want to keep a (deprecated?) wvui-icons module around for that use case.

In T275914#7161717, @Catrope wrote:

In T275914#7156632, @DannyS712 wrote:

In T275914#7156516, @Catrope wrote:

For performance reasons, we'd like to avoid exposing the entire set of icons, because it's so large. Instead, I think we'll want to offer two options:

• Using a build step, tree-shake just the icons that are needed, and include those in the built bundle
• Allow RL modules to list the icons they need in their module definition, and build some ResourceLoaderImageModule-style magic to automatically add wvuiIcons.iconName = '...svg string...'; to those modules

Neither one of those would work for onwiki scripts though, right?

The latter could work for gadgets if we made the syntax simple enough and supported it in gadget definitions. For user scripts it wouldn't work, and we may want to keep a (deprecated?) wvui-icons module around for that use case.

So I was look at why the dist files for the main wvui and wvui-search modules already include the icons anyway, and I think its because in Input.vue there is an import of wvuiIconClear from the icons file. Given that the icon data is already present in the dist files, would adding it to the exports result in needing to repeat the data again? Or just move it around so that its added to the exports with minimal increase in bundle size?

A quick test later found that adding all of the icons to the default exports of the wvui and wvui-search bundles would increase each by 22KB, compared to the 91KB of the dedicated wvui-icons module (sizes are based on the commonjs2 distribution). But, we shouldn't add to the defaults, because then we can't pass the default exports directly to the components property of our app. Instead, maybe add to the WvuiIcon component the ability to just be given the name of our icon, and if it matches one of the icons in the library it would then use that, like OOUI does.

In T275914#7219246, @DannyS712 wrote:

So I was look at why the dist files for the main wvui and wvui-search modules already include the icons anyway, and I think its because in Input.vue there is an import of wvuiIconClear from the icons file. Given that the icon data is already present in the dist files, would adding it to the exports result in needing to repeat the data again? Or just move it around so that its added to the exports with minimal increase in bundle size?

This happens because dead code elimination is currently broken in our builds (possibly because minification is disabled for the commonjs2 builds). Once we fix this issue, then only wvuiIconClear will be included, and the other icons (that aren't used by Input.vue) will not be, which will significantly reduce the size of the icon-less build.

A quick test later found that adding all of the icons to the default exports of the wvui and wvui-search bundles would increase each by 22KB, compared to the 91KB of the dedicated wvui-icons module (sizes are based on the commonjs2 distribution). But, we shouldn't add to the defaults, because then we can't pass the default exports directly to the components property of our app. Instead, maybe add to the WvuiIcon component the ability to just be given the name of our icon, and if it matches one of the icons in the library it would then use that, like OOUI does.

I think that 22KB is all export code (repeating __webpack_require__.d(icons_namespaceObject, "wvuiIconAlert", function() { return wvuiIconAlert; }); for every icon adds up to a lot), which is another way in which our current build is inefficient. We want to move WVUI away from Webpack to Rollup or Vite in the near future, which would fix both of these things (dead code elimination and super high export overhead).