Bootstrap JavaScript modules API design questions/issues

[petetnt]

As a part of #17325, 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 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 #17325 (comment), 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 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 #17325 (comment) 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.

[cvrebert]

Re: "Pretranspiled or raw sources", see #20072.

[RyanZim]

A gigantic +1 to this; in v3, getting bootstrap to work without window.jquery is a pain.

Also wanted to add: import Tether from "tether" should only be in the modules that require tether.

[gkatsanos]

Thank you Pete, I imagine this will be done for the beta, these days modularization is kind of a hard requirement.

[mdo]

What are we tackling here for v4, if anything?

[petetnt]

Sorry for getting back so late @mdo, this one kinda fell through the cracks

In https://github.com/petetnt/bootstrap/commits/v4-js-modules I had a structure going on that mostly had the thing going on that I had in mind when writing this issue a looooooong time ago. There were couple of things that needed to be fixed, such as Carousels raising errors due to some shared state (IIRC) issues, and while the tests all pass, it would have required some refactoring that would have introduced some breaking changes. At the same time v4 went into alpha, which is why I (perhaps dumbly) decided to drop the thing and revisit it around v5 would roll around.

The beef of v4-js-modules branch was to include versions that would enable the magic behavior for browserified versions via a hidden flag introduced by Webpacks DefinePlugin, while also making it possible to use per component basis (for example in React). (Again IIRC) This mostly works on the branch (sans few issues mentioned above). What I was left wondering was if that was actually a profitable result; was it worth it. Maybe the JS modules story should have been rewritten from the start, but then again tons of things have happened between start of v4-dev and today, so the story might have ended up in the same place anyway.

Either way, I do still ❤️ Bootstrap and would love to revisit the JavaScript side someday.

[mdo]

All good @petetnt. Should we close this for now then?

[Johann-S]

Currently I try to work with another bundler (rollup) so if you're interested to help me @petetnt I'm available on slack 👍

@mdo this should stay open, it's a huge refactoring work but as it was said below modules is asked a lot these days

[snboisen]

Are we really not going to see a modular Bootstrap before v5 or later? 😞
If there is a chance for this to happen in v4, surely this issue should be kept open?

[Johann-S]

I created a PR to allow a better modularization of our plugins see : #22888
if you have time to give some feedbacks do not hesitate 👍

[danimalweb]

Any news on this for Beta 3?

[Johann-S]

Now in Beta 3, our files (bootstrap.js , bootstrap.min.js, bootstrap.bundle.js and bootstrap.bundle.min.js) are UMD ready

[iamandrewluca]

Is jQuery Event System the biggest part that keeps bootstrap from dropping jQuery?

[dvmuccillo]

Is jQuery Event System the biggest part that keeps bootstrap from dropping jQuery?

See #23586

[ysds]

@twbs/js-review can we close this?

[Johann-S]

Yep a lot have been done on that part 👍