| Right now Jenkins uses a combination of js-builder and gulp as the toolchain to build the frontend assets. There are many reasons to replace js-builder with a modern, industry-standard tool:
- It does not support many new technologies and techniques commonly used nowadays, like post-css.
- It is a tool used only within the Jenkins project. This and the lack of comprehensive documentation makes it difficult for developers to modify or extend the toolchain.
- It is based on outdated tools (i.e. browserify) and uses a module system that is incompatible with modern JS build tools.
I propose basing the new frontend toolchain on webpack. It is the tool that has the more usage, support and customizability. The js-builder ecosystem js-builder offers the possibility, using some sibling libraries (js-modules, js-libs), to have shared libraries across multiple projects running on the same window. For example, if both Jenkins core and a plugin use the same version of jquery, it would only be loaded once. While this can seem like a great idea, having this behaviour on Core can be problematic. Having core load its own libraries would only add an extra 50-100KB of JS code. It introduces a huge maintainability burden and locks the project into using js-builder & friends. Planned changes The goal of this improvement is to replace js-builder with webpack, and use NPM versions of the js-libs used on the project (handlebars, jquery, bootstrap). |
