Hacker News new | ask | show | jobs
by usaphp 3456 days ago
What is the best way to extend bootstrap without loosing an ability to update it in the future and also do not have a ton of duplicated code?
6 comments

Use the Bootstrap Sass files. In particular, overwriting the variables as much as possible instead of just overriding the compiled css will give you flexibility, as they try to preserve those across versions. If you've minimized the amount of overriding css that you've written, then rewriting it will be easier.
This.

I've upgraded bootstrap styles using "Less" which is being replaced by "Sass". It takes a little bit to get set up (the jet brains phpstorm app builds it), but once its done its pretty great.

You can also customize your download leaving out the parts of bootstrap you don't want. (I originally did that for and older version bootstrap, while keeping some of my page styles). The customizer seems to now give you a json file, so you can download updates with the same settings as your original download, I have not tried this though.

http://getbootstrap.com/customize/

The way I prefer to do this is we have our own SCSS files which get compiled along side bootstrap, and they are all more specific than the Bootstrap SCSS so they get precedence.

For example, we might want our default alerts to all be purple or something. We can add a class "my-namespace" to the body, or to a closer parent of the alert and then add the following to our "my-namespace" SCSS. If I wanted to change the "alert-info" background to orange I could also include a rule for that.

Hopefully in production you'd be using color variables instead of hex codes, but:

    .my-namespace {
        .alert {
            background-color: #aa00aa;

            .alert-info {
                background-color: #dd8800;
            }
        }
    }
Now you're overriding Bootstrap without touching Bootstrap's SCSS. I far prefer this method than the method I see a lot of folks using where they just go mucking around in the Bootstrap SCSS directly.
If you need to extend it, just extend it with your own includes. If you need to modify it, stick to editing variables. If you have both of those, then updating minor versions should be easy.

I tend to keep the source in the bower_components directory and copy/modify only the includes.

The issue is that the project is changing, you will have to wait for an RC if you really want stable code.

This tutorial [0] / [1] (using LESS) worked well for me. I recently did the upgrade from 3.3.6 - 3.3.7.

You create a directory just outside bootstrap and reference that from `bootstrap.less` inside the bootstrap core to override the bootstrap variables. Then you just have to modify `bootstrap.less` in the core bootstrap directory after upgrading.

  [0]: https://www.smashingmagazine.com/2013/03/customizing-bootstrap/
  [1]: https://github.com/thomaspark/bootswatch/
It depends on how deep you plan to extend Bootstrap, obviously. I had one project I worked on that did a lot surgery to the Bootstrap files in a branch of fork of the main Bootstrap repository. I don't recommend that if you can avoid, and it was late in that project that I got better at being able to do overrides of the LESS files (as this was Bootstrap 2/3) in other LESS files without needing to edit the Bootstrap sources. There ends up being more duplication by doing it in separate files you control, but it makes it easier to deal with "merge conflicts" from upstream.

From that approach, one useful example I have seen is the infrastructure of the Bootswatch project. [1] Perhaps unsurprisingly for how many themes Bootswatch maintains, their GitHub repository is quite well laid out, easy to learn from, and even easy enough to fork as the basis of your own project.

[1] http://bootswatch.com/

In my experience, it's really one or the other. There's unfortunately going to be a lot of duplicated overwriting code if you want to update it in the future. I'd love to know of better methods though.