Strip out UMD & CJS in favor of ES6 modules

[cvrebert]

Step 1 of N in working out a proper modules story for Bootstrap 4, to address #19017 & 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 import their 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 window object (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:

1. Early adopters using ES6
2. Folks using older module formats & loaders/transpilers, such as AMD+requirejs, CommonJS+browserify, etc.
3. 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.

[hnrch02]

I think this is a good way to go forward. ES6 modules seem to be the accepted standard and are integrated into many build tools today so (as you stated) the transition from UMD shouldn't be too hard. It would also be in line with us switching to arguably more mature technologies like we did with Sass. Maybe though we need opinions from actual AMD/CJS users on this?

For the people using our JS plugins individually maybe the lodash-cli solution would work? This would mean some additional overhead for us but it wouldn't be much more than just running Babel and maybe rollup to create the personalized file for the user.

Anyway, thanks for this. 👍 from me.

[petetnt]

As the author of #19017 I fully support just providing the raw (ES2015) sources, informing the user about the need of transpilation and letting the user choose their own tools in the way they best see fit while offering the "complete" bundle for those who just want to add the <script> and be done with it. For the niche that used the individual files I'd rather point them to using the ES2015 modules instead. If there's more demand for those kinds of builds, a tool like bootstrap-cli could be an option.

Not only does this significantly reduce the overhead for supporting all kinds of systems, it also means that things will only get better in the future when browsers start to get module support and so on (not that the need for transpilation will go away anytime soonish, but it does enable users to just use the individual files for some specialised use cases).

[cvrebert]

Seeing the positive feedback/reactions and lack of negative response, and wishing to make progress on steps 2 thru N, I'm going to merge this.

[sergey-dev]

Hi, guys, you provided a big change by stripping out UMD, but the decision was took based on 5 days discussion. You was no hearing for a negative response just because the period was really short.

If you'll crawl internet, something alike:

Uncaught Reference Error: Util is not defined

or similar... There are questions in the air, how to behave, if people still would need to support applications utilizing previous v4-dev, where been an old module formats & loaders/transpilers are being used (AMD+requirejs, CommonJS+browserify, etc).

It was totally not expected, that you dropped UMD-support in v4.0.0-alpha.3 without prior notice, or not releasing this under newer v4.0.0-alpha.4.

May you please enlighten this topic in blog, or in the documentation somewhere?

[bardiharborow]

@sergey-dev

the decision was took based on 5 days discussion. You was no hearing for a negative response just because the period was really short.

Bootstrap is not a government committee, it's an open-source software project. The maintainers can and do make changes at any time they wish. However, the wonderful thing about git is that the changes can be reverted if you can make a technical case for why UMD is still needed.

people still would need to support applications utilizing previous v4-dev

v4-alpha.* versions are, by definition, alpha releases. Per #17021, "nothing is guaranteed to be part of v4 until our first beta release". Alpha releases SHOULD NOT be used in production if you not prepared to accept the maintenance cost of keeping up with changes or dealing with potential bugs.

[danimalweb]

While I agree that it was a bit of a pain to see them disappear rather instantly, I accept that this is an alpha as should be treated as such.

I'm personally looking forward to seeing the following PR #19017 implemented, which should take care of my modular JS needs.

[sergey-dev]

@bardiharborow and @danimalweb , thanks for the input!
I clearly understand the difference between the open-source project and some official committee, the discussion is not about risks of the alpha version neither. I clearly understand the boostrap v4 changes, and it will change even further, though it doesn't prevent me from using alpha on production of the huge retail shop, I clearly understand the risks connected, and I took them :)

My main message was not about "should we have UMD in BS.v4 or not", that's not the discussion, I was trying to say, that community has to be more speaking on such a drastic changes, they have to be enlighten, or at least mentioned in the blog for the specific milestone. As all of you know UMD support was advertised among one of the key features in Bootstrap 4.

Rewrote all our JavaScript plugins. Every plugin has been rewritten in ES6 to take advantage of the newest JavaScript enhancements. They also now come with UMD support, generic teardown methods, option type checking, and tons more.

yes, PR #19017 looks extremely promising, I'm looking forward to it as well.

[gkatsanos]

For the niche that used the individual files

I was just trying to figure out whether there is a way for us who need to use only 1 Bootstrap plugin and not all of them (without manually copy-pasting the actual plugin in the codebase) and read this.

I also created this ticket : #21548

Is there a way?