Bootstrap JavaScript modules API design questions/issues

Created by: petetnt

As a part of #17325 (closed), I have been doing the initial legwork of having better modularization for the Bootstrap modules. Currently it is rather painful to get the dependencies working properly when trying to minimize global variables and it's pretty much impossible to hand pick the features you want (without hacking on the source).

Solving #17325 (closed) is relatively easy to handle: adding import jQuery from "jquery", import Tether from "tether" and adding both of those to package.json. The tricky part comes when the user needs (or wants) a bit more control over the Bootstrap modules. Bootstrap has always* been automagical: you add the bootstrap.js file and suddenly you have all the features the framework uses at hand through the HTML markup binding. Or you could just use the provided JS API's.

As modular JavaScript has gotten more and more popular in the past few years, the developers have gotten accustomed to fine-grained control over the source files, into a situation where not everything has to be dumped to the page and then it just works. Like in https://github.com/twbs/bootstrap/issues/17325#issuecomment-137025922, the obvious choice would be allowing to import the files one by one and use them as you want to:

  import { Modal, Popover } from "bootstrap"

In my bs-modules branch this sort of works right now: Modal will be modal and Popover will be popover. The real issues begin here:

IIFE's and re-exporting

All the components are wrapped in to IIFE's

   const Foo = ((foo) => { })(bar)

When we re-export the files in index.js the exported files are executed from top to bottom and all of the IIFE's get triggered. Consider something like this:

  import $ from 'jquery'
  import { Tooltip } from 'bootstrap'
  console.log(Tooltip) // Tooltip
  console.log(Modal) // undefined
  console.log($.fn.tooltip) // Tooltip
  console.log($.fn.modal) // Modal

Not entirely sure what would be the best way to avoid this. Most likely creating some kind of init-methods that are IIFE'd in the compiled version (bootstrap.js) that could be called manually when importing, or making the end users initialize their own components (through something like Tooltip($(".foo"), {config: options, here: yup}).

Pretranspiled or raw sources

Currently the distributed modules are transpiled with Babel and wrapped into UMD-wrappers. npm.js file is created by Grunt which requires all the modules. Now the userland can use the modules without transpilation, but if you are creating something this ES2015 this seems a bit redundant as you most likely have your own transpilation process going on. #18934 (closed) asks for where the source files are and I agree: the raw sources should be included. Which leads to the question, should the UMD-modules be included too? Some of the options:

Only offer the raw ES2015 and mention in the docs that transpilation is most likely needed and show ways how to do it
- Lowest maintenance cost, dist modules === src modules
- Configure popular bundlers in repo
- Might cause headaches to some end users?
Offer ES2015 files and the transpiled ones. UMD files could be imported with bootstrap/umd and the ES2015 files bootstrap
- Increased maintenance cost
- Most robust
Offer separate packages for the 2015 and UMD flavours

Opinions?

Any opinions about either of these or the modularization in ? We are getting quite to the release (or end of the alpha, I assume) and these are quite big choices. Like in https://github.com/twbs/bootstrap/issues/17325#issuecomment-134876486 there was some discussion about people not complaining about the dependencies not being there and @vejersele replying how most people were not using Bootstrap via npm because it was hard and that's most likely true. It would be a shame if that happened to v4 too: I really want to use Bootstrap in most of my projects, but at its current state it's near impossible to get it to integrate with my apps in a way that I would consider somewhat standard.