Created by: cvrebert
Step 1 of N in working out a proper modules story for Bootstrap 4, to address #19017 (closed) & others.
This removes UMD and CommonJS transpilation from the build.
Eventually, I propose that we offer both (and only):
- Native ES6 modules (which should be our original source code) which
importtheir dependencies - (To be added via a future PR) A pre-transpiled, all-modules-in-one-file ES5 file that exports things as global vars on the
windowobject (e.g.window.Tooltip) and likewise expects its dependencies to available as globals.
Why these 2? As I see it, Bootstrap's constituents can be broadly classified into:
- Early adopters using ES6
- Folks using older module formats & loaders/transpilers, such as AMD+requirejs, CommonJS+browserify, etc.
- Folks (especially those who aren't front-end experts) using
<script>tags, globals, and self-discipline as their JS module system.
Folks in groups (1) and (2) are already using tools (build tools, transpilers, loaders, etc.), and these tools require a comparatively higher level of technical skill, so asking them to configure their tools to ingest ES6 modules is reasonable. Especially since ES6 has been standardized by the browser vendors and will (in time) be supported natively in browsers. And for group (1), this should be essentially no extra work whatsoever.
Trying to accommodate group (2) more from our side is a decent amount of extra work for us, to support formats which will be (to my knowledge) increasingly legacy (& thus lower priority) as adoption of ES6 standard modules progresses, and to help (a bit) folks who (generally speaking) don't need as much assistance in the first place.
Group (3) is, anecdotally, a large segment of our userbase, and asking them to start using a build system (so that they could use our ES6 code directly) doesn't seem viable. In the case of newbies to development in general, they would likely need a lot of high-touch help (which we aren't in a position to provide) to setup their build systems, or at least might encounter lots of frustration while setting it up. In the case of others (e.g. backend developers), they might have the necessary skill, but not be willing to invest the requisite amount of time, particularly when they might not be familiar with the toolset (Node.js/npm/Sass/PostCSS/Babel/etc.) and might not value the knowledge gained as much. Bootstrap's "instant gratification" experience (just copy 2 files & insert 2 HTML tags) is highly valuable to this group. The all-in-one-ES5-using-globals file allows group (3) to continue with their existing simple workflows from Bootstrap v2/v3, undisturbed.
There is one other group worth noting, which is the subsection of groups (2) & (3) who were using Bootstrap v3's individual JS files (tooltip.js, etc.). It's less obvious to what extent we should prioritize this group and what we could/should offer them. It's also harder to characterize this group.
Most of our modules now depend on our util.js module, so they're not as self-sufficient as they were in v3. We could offer a build that bundled util.js into all the other modules, but that results in multiple copies of the util code if the user is using multiple modules. Not seeing an obvious best solution here, my current proposal is that such users should migrate to either ES6 modules (if modularity was their chief concern and they have sufficient technical ability to adopt a build system) or to the all-in-one-ES5-using-globals file (if ease-of-use was their chief concern; at the expense of optimal performance).
CC: @twbs/team for discussion.