-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
-
Jenkins 2.217
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).
- causes
-
JENKINS-61660 Lack of spacing between setup wizard form errors
-
- Resolved
-
[JENKINS-60734] Replace js-builder with webpack
Description |
Original:
Right now Jenkins uses a combination of [js-builder|https://github.com/jenkinsci/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|https://webpack.js.org/]. It is the tool that has the more usage, support and customizability. h3. The js-builder ecosystem js-builder offers the possibility, using some sibling libraries ([js-modules|https://github.com/jenkinsci/js-modules], [js-libs|https://github.com/jenkinsci/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. h3. 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). |
New:
Right now Jenkins uses a combination of [js-builder|https://github.com/jenkinsci/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|https://webpack.js.org/]. It is the tool that has the more usage, support and customizability. h3. The js-builder ecosystem js-builder offers the possibility, using some sibling libraries ([js-modules|https://github.com/jenkinsci/js-modules], [js-libs|https://github.com/jenkinsci/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. h3. 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). |
Assignee | New: Félix Queiruga Balado [ fqueiruga ] |
Released As | New: Jenkins 2.217 | |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Epic Link | New: JENKINS-60919 [ 204316 ] |
Link |
New:
This issue causes |