Move to Bootstrap v4.0.0-beta #286
Comments
|
You might need to chime in on this @markfinger. I don't have an opinion |
|
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:
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? |
|
@sam-mi any thoughts as well? |
|
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. |
|
@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 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. |
|
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. |
|
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. |
|
My personal experience with installing non-python deps into python packages is that it becomes a fragile process heavily dependent on file permissions. |
|
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. |
|
Yarn and npm are mostly interchangeable, but I don't mind consolidating on either. |
|
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. |
…ble re #286, currently setup-django makes the assumption that yarn.lock exists which it may not initially. In order to use BS4 and compile from source, we need to move away from bower (at least to install bootstrap, since bower is deprecated), they recommend using yarn instead. Can we get away with simply using npm and django-compressor? The goal is to have: - bootstrap 3 available to the admin - bootstrap 4 available to the front end - icekit .scss files compiled into the project/overridable where necessary - project .scss files that allow for bootstrap variables and overrides and provide a platform to build on that simplifies frontend setups for icekit sites. - can we get away with using only django-compressor or is yarn/alternative a necessary step? - as simple a setup as possible to avoid painful edge cases and implementation nightmares - sourcemaps would be nice Yarn - use bower-away to convert bower.json to yarn (adds yarn specific syntax to package.json) - yarn requires Ruby > 2.3 - you might need to delete bower_components/.DS_Store if bower-away fails with ENOTDIR
…ble re #286, currently setup-django makes the assumption that yarn.lock exists which it may not initially. In order to use BS4 and compile from source, we need to move away from bower (at least to install bootstrap, since bower is deprecated), they recommend using yarn instead. Can we get away with simply using npm and django-compressor? The goal is to have: - bootstrap 3 available to the admin - bootstrap 4 available to the front end - icekit .scss files compiled into the project/overridable where necessary - project .scss files that allow for bootstrap variables and overrides and provide a platform to build on that simplifies frontend setups for icekit sites. - can we get away with using only django-compressor or is yarn/alternative a necessary step? - as simple a setup as possible to avoid painful edge cases and implementation nightmares - sourcemaps would be nice Yarn - use bower-away to convert bower.json to yarn (adds yarn specific syntax to package.json) - yarn requires Ruby > 2.3 - you might need to delete bower_components/.DS_Store if bower-away fails with ENOTDIR
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.
The text was updated successfully, but these errors were encountered: