1 | # FAQs
|
2 |
|
3 | <p>
|
4 | <a href="#do-i-really-need-to-learn-all-this-new-stuff">Do I really need to learn all this "new" stuff?</a><br/>
|
5 | <a href="#what-is-the-difference-between-a-module-and-a-bundle">What is the difference between a "module" and a "bundle"?</a><br/>
|
6 | <a href="#do-we-really-need-bundles">Do we really need bundles?</a><br/>
|
7 | <a href="#couldnt-i-just-use-gulp-and-browserify">Couldn't I just use Gulp and Browserify?</a><br/>
|
8 | <a href="#what-does-module-loading-mean">What does "module loading" mean?</a><br/>
|
9 | <a href="#why-not-use-requirejsamd-or-es6-modules-for-modulebundle-loading">Why not use RequireJS/AMD or ES6 modules for module/bundle loading?</a><br/>
|
10 | <a href="#how-do-i-create-a-bundle">How do I create a bundle?</a><br/>
|
11 | </p>
|
12 |
|
13 | <hr/>
|
14 |
|
15 | ### Do I really need to learn all this "new" stuff?
|
16 | One concern that has been raised about new JavaScript approaches that might involve new technologies (new to the
|
17 | Jenkins tool-chain) is the fear that it would add to the learning curve for new and existing Jenkins plugin
|
18 | developers. We added this section to this README specifically to alleviate that concern.
|
19 |
|
20 | <p align="center">
|
21 | <img src="img/keep_calm.png" alt="KEEP CALM - THIS IS OPTIONAL">
|
22 | </p>
|
23 |
|
24 | The use of `js-modules` for plugin GUI development is __totally optional__! If you want to continue developing
|
25 | your plugin's GUI using the same technologies you've always used (Jelly etc), then that is not a problem. You can
|
26 | happily ignore everything here; nothing new is being forced on anyone!
|
27 |
|
28 | `js-modules` is designed to help where the maintainer is interested in using "newer" JavaScript technologies
|
29 | to build a richer plugin GUI that has more maintainable JavaScript code (more modular, better unit testing etc) that
|
30 | can be more easily evolved over time (can safely move to newer versions of "Framework" libraries such as jQuery etc).
|
31 |
|
32 | Again, if none of this interests you at the moment, then that is not a problem. You can continue building your plugin
|
33 | GUI using the same techniques and technologies as before (server-side, Jelly etc).
|
34 |
|
35 | ### What is the difference between a "module" and a "bundle"?
|
36 | A "bundle" is a single JavaScript file that contains 1 or more [CommonJS] "modules". We use [Browserify] to handle the creation of these bundles. It
|
37 | handles the process of making sure all the module `require` calls are resolvable within the "bundle" i.e. that the bundle
|
38 | has everything it needs to execute properly.
|
39 |
|
40 | ### Do we really need bundles?
|
41 | In theory "no", but bundles provide 2 big benefits (and probably more):
|
42 |
|
43 | 1. Bundles allow us to load a suite of tightly related [CommonJS] modules (an "app") in a single request Vs loading them all individually (ala RequireJS/AMD).
|
44 | 1. Bundles make modularized "app" coding a lot nicer/cleaner because they allows us to use the synchronous
|
45 | `require` programming model made popular by [node.js]. The bundling makes this possible because it removes the need
|
46 | for the asynchronous module loading (ala RequireJS/AMD - ugly anonymous callbacks etc) that would be required if the browser needed to load each module
|
47 | individually.
|
48 |
|
49 | ### Couldn't I just use Gulp and Browserify?
|
50 | Yes, you could build modularized JS (and use it in your plugin) using Gulp and Browserify only. In fact, that was what
|
51 | we did before creating `js-modules`.
|
52 |
|
53 | However, the problem with that approach is that it means every app bundle will contain all the code for every JS
|
54 | Framework lib it depends on. That might not seem like a problem when a page has just one of these "apps", but if it has
|
55 | multiple "apps" from different plugins, all using jQuery (and maybe some other libs e.g. Bootstrap), then you have a
|
56 | situation where all of these libraries are being loaded multiple times. This is something we would like to avoid.
|
57 |
|
58 | One of the main things that `js-modules` is trying provide is the ability to create slimmed down "app" bundles
|
59 | that only contain the "app" JS modules i.e. no framework libs. The framework libs are bundled separately
|
60 | (in their own bundles) and "linked" into "app" bundles that need them via the `export` / `import` mechanism.
|
61 | See [Framework libs].
|
62 |
|
63 | ### What does "module loading" mean?
|
64 | `js-modules` is a "module bundle" loader.
|
65 |
|
66 | > Read:
|
67 | > - <a href="#what-is-the-difference-between-a-module-and-a-bundle">What is the difference between a "module" and a "bundle"?</a>.
|
68 | > - <a href="#do-we-really-need-bundles">Do we really need bundles?</a>.
|
69 |
|
70 | Two __module loading__ patterns are "relevant" with `js-modules`:
|
71 |
|
72 | 1. __Intra__-bundle module loading. The loading of [CommonJS] style modules within a bundle e.g. module `A` loading module `B`, where both modules are within the __same__ bundle.
|
73 | 1. __Inter__-bundle module loading. The loading of [CommonJS] style modules across bundle "boundaries" e.g. module `A` loading module `B`, where both modules are in __different__ bundles.
|
74 |
|
75 | [Browserify] handles `#1` nicely, but it doesn't really handle `#2` in a way that works nicely for Jenkins. This is why `js-modules`
|
76 | exists. Of course, one could just build self contained bundles using [Gulp] and [Browserify] (and so stick with `#1`), but that's not
|
77 | a scalable solution (see link below).
|
78 |
|
79 | > Read:
|
80 | > - <a href="#couldnt-i-just-use-gulp-and-browserify">Couldn't I just use Gulp and Browserify?</a>
|
81 | > - <a href="#why-not-use-requirejsamd-or-es6-modules-for-modulebundle-loading">Why not use RequireJS/AMD or ES6 modules for module/bundle loading?</a>
|
82 |
|
83 | ### Why not use RequireJS/AMD or ES6 modules for module/bundle loading?
|
84 | One could debate the pros and cons of different module loading systems ad nauseam.
|
85 |
|
86 | > Read:
|
87 | > - <a href="#do-we-really-need-bundles">Do we really need bundles?</a>
|
88 | > - <a href="#what-does-module-loading-mean">What does "module loading" mean?</a>
|
89 |
|
90 | We went with the [Browserify] + `js-modules` approach for a few reasons:
|
91 |
|
92 | 1. [Browserify] lets us use [CommonJS] style modules in browser code i.e. synchronous `require` of modules for intra-bundle module loading. Asynchronous module loading patterns (ala Require/AMD) is something we wanted to avoid as we were not fans of the async AMD loading patterns involved (anonymous callbacks etc).
|
93 | 1. [Browserify] lets us bundle all the [CommonJS] modules for an "app" into a single JavaScript file, allowing them all to be loaded in a single request Vs loading each module to the browser one at a time ala RequireJS.
|
94 | 1. Using RequireJS to perform the loading of the [Browserify] generated bundles is something we considered (and experimented with). A number of problems were encountered here, but the main one (that seems insurmountable) was the fact that [Browserify] and RequireJS have difficulty living alongside each other on the same page due to the fact that RequireJS defines a `require` function in the global scope.
|
95 | 1. We felt that using a simple name-based module loader (ala `js-modules` - "does a module of this name exist, yes/no?" - no funky module path resolution algorithms etc) for inter-bundle module loading would be less likely to result in strange unforeseen things happening.
|
96 |
|
97 | ### How do I create a bundle?
|
98 | See [jenkins-js-builder].
|
99 |
|
100 | [Browserify]: http://browserify.org/
|
101 | [Gulp]: http://gulpjs.com/
|
102 | [CommonJS]: http://www.commonjs.org/
|
103 | [node.js]: https://nodejs.org/en/
|
104 | [Keep Calm]: https://github.com/jenkinsci/js-modules#keep-calm
|
105 | [Framework libs]: https://github.com/jenkinsci/js-modules#framework-libs-jenkinscijs-libs
|
106 | [jenkins-js-builder]: https://github.com/jenkinsci/js-builder
|