Skip to content

[CSS utilities TG] Discuss alternative migration strategy

We're a couple weeks in the Tailwind CSS migration and we are noticing a few quirks:

  • Some migrations can be pretty large. Even though we are providing integration MRs along with every deprecation in GitLab UI, there's a chance for those to get outdated by the time we upgrade @gitlab/ui, which would result in breakages as, at that point, the legacy utils aren't available anymore.
  • We're in a weird stance where GitLab UI is only partially Tailwindy, which isn't easy to document or to be aware of as a consumer.
  • We need to ship countless breaking changes.
  • We are creating bottlenecks for concurring GitLab UI changes that might get blocked by utils integration MRs.

@leipert suggested a different approach:

  • Make GitLab UI fully Tailwindy right now. What this means is that we stop supporting the legacy utility library immediately.
  • Projects that are ready to take full advantage of Tailwind can stop importing the legacy utils already.
  • Projects that need larger migrations, like GitLab, can copy the legacy utilities CSS. The migrations can then be performed in the consumer only, removing unused legacy utilities from their own copy.

A potential caveat with this approach is that GitLab UI also uses some legacy utils internally. If we make the project 100% Tailwind, we need to migrate internal usages to Tailwind too, the consumers then need to be able to generate those utilities. The easy solution is to enable all Tailwind core plugins, but that also means that a vast majority of utilities will be duplicated until we remove them from the copied bundle.