Move to Bootstrap v4.0.0-beta

[fabinol]

Possibility of moving ICEkit's default Bootstrap from v3.3.7 to v4.0.0 beta. This is the version that is being pushed to developers and is a significant improvement on v3. The sooner we do this the better.

[jmurty]

You might need to chime in on this @markfinger. I don't have an opinion

[markfinger]

So the problem is that icekit depends on the project's version of bootstrap. If we upgrade bootstrap, we're likely to break large parts of the admin and icekit front-end.

We have a few paths:

1. vendor bootstrap and namespace it for icekit, then replace all references to bootstrap with references to the nested icekit version.
2. continue to rely on global bootstrap and deal with incompatibilities as they come up.
3. ignore the problem and continue to use bootstrap 3.

The first path is probably the sanest and easiest; the second is likely to have a lot of hidden issues and will require the most work; the third option will buy us some time, but will bite us within 6 months as 3rd-party plugins no longer support bootstrap3.

@mrmachine any thoughts?

[markfinger]

@sam-mi any thoughts as well?

[fabinol]

I like the idea of decoupling Icekit's version of Bootstrap from the project's version. It's only a matter of time before we get handed a design from an external agency which is based on a frontend framework which isn't Bootstrap. It kind of already happened with ACMI when Boccalatte wanted to use form element designs from Semantic UI.

[mrmachine]

@markfinger this sounds like a plan to revert back to the original behaviour, where ICEkit specified its own frontend dependencies and pull them in during packaging/install. At the time, you recommended that we simply put ICEkit's dependencies in the project template's bower.json and let the project deal with it from that point.

It seems that vendoring ICEkit dependencies to decouple them from project dependencies is the only real choice available to us, but I'd still like to use Bower to pull them in at packaging/install time instead of simply adding all the Bootstrap files to our repo.

[markfinger]

I'm open to using bower to handle icekit's deps, as long as it's a trivial solution.

On the other hand, vendoring will solve the problem immediately with the least amount of complexity required in the icekit bootstrap process.

[markfinger]

To clarify: by vendoring, I mean we just dump the necessary js/css/font/img files into the repo, rather than using a package manager.

[markfinger]

My personal experience with installing non-python deps into python packages is that it becomes a fragile process heavily dependent on file permissions.

[sam-mi]

Do we know what aspects of the admin and icekit require BS3?

BS4 drops support for bower in favour of yarn (bower is deprecated see https://bower.io/). There is 'bower-away' that can be used to convert a bower project to Yarn, and Yarn can also replaces 'npm install' so we'd have to update docker and go.sh to get this change to work. At the moment yarn happily installs everything but running go.sh removes the node_modules folder and tries to install with npm which breaks because it can't understand the yarn syntax put there by bower-away.

[markfinger]

Yarn and npm are mostly interchangeable, but I don't mind consolidating on either.

[markfinger]

For the benefit of others, yarn is a FB-sponsored reimplementation of npm that focuses on providing improved performance and deterministic builds.

I haven't paid too much attention to it since it came out, as I preferred to stick with npm's stability. That being said, Yarn's been around for a while now, so it should be reasonably stable state now.