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 not being actively maintained.
• 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).