This epic is set up to track the removal of bootstrap components in `.haml` files and replacing them with their GitLab UI equivalents. > Remove 100% of calls to bootstrap components in haml files by utilizing GitLab UI components for modals, popovers, tooltips, tabs, dropdowns, pagination, buttons, and alerts. ## Overview We have a lot of uses of bootstrap in the GitLab codebase. This is in both `.haml` and `.vue` files. If we remove all the calls to bootstrap.js, we can stop bundling it (and by extension, jQuery) which could greatly reduce our bundle size. We will see small performance improvements along the way, but will only really get the full benefit once we've removed all the instances. [Component integration scoping strategy](https://gitlab.com/gitlab-org/gitlab/-/issues/227287) has related information. ## Component specifics  *Note: I'm updating this table manually, it may be outdated* | Component | Epic | Completed | % | Notes | |-|-|-|-|-| | :smile: Alerts | &4070 | 54/55 | 98.1% | This has been largely driven by community contributions | | :white_check_mark: Buttons | &4001 | 194/194 | 100% | It's over, it's done | | :smile: Modals | &4386 | 23/29 | 79.3% | | | :grimacing: Dropdowns | &4549 | 8/72 | 11.1% | | | :white_check_mark: Pagination | | 0/0 | 100% | This was complete before we started, easy win | | :grimacing: Tabs | &3983 | 17/61 | 27.8% | We're tracking these, but the path is still al little unclear | | :white_check_mark: Popovers | &4409 | 12/12 | 100% | All done! | | :white_check_mark: Tooltips | &4383 | 109/109 | 100% | Smashed it | |-|-|-|-|-| | :smile: Total | | 417/532 | 78.3% | | ## FAQ (Frequently Anticipated Questions) ### Is this KR set up to remove `bootstrap.js`, or replace all the `bootstrap.css` classes too? Both. Removing Bootstrap.js is the goal here but since bootstrap.js reliesquite heavily on the CSS classes too, we should also remove these. ### Will we need to create Vue apps around every component we replace? This is an unkown. For some components, definitely. For others, it really doesn't make sense. In the case of Modals, it will likely make sense to create a Vue app. In the case of things like tooltips / popovers, it probably doesn't. For the cases where creating a Vue application doesn't make sense, we've opted to simply move the bootstrap implimentation to a helper function and migrate all the instances to use that helper function. This way, when we decide what the best approach to take is, we only need to take that approach in the helper function and everything else will fall in line. ### How much can we automate this? @ealcantara has done some work that may help with automating the finding of these components. It's unlikely that we'll be able to automate updating these components ### How much work is involved in updating these components? This will vary from component to component. There'll be a lot of easy tasks, some tricky ones, and probably some truly awful ones that will take ages. We should make an effort to find this out as early as possible and identify any problem areas. ### Why aren't all the epics linked to this one? Because some of the epics already have a parent and I don't want to break that relationship. For the tracking epics, please see the [component specifics](#component_epics) above. It's not ideal, but it's the best we can do without breaking other epics.