@webitel/ui

Appearance

SCSS to CSS Migration ​

Ця стаття – про мій досвід міграції SCSS до CSS, який я робив у проєктах, "широкими мазками", і за допомогою AI.

Що на даний момент (28.01.2026) зроблено:

  • ✅ Міграція основних файлів у @webitel/styleguide CSS з SCSS до CSS.
  • ✅ Міграція основних файлів у @webitel/ui-sdk CSS з SCSS до CSS.
  • ✅ У всіх апплікейшенах, всюди забрав всі @extendʼи.
  • ✅ У всіх апплікейшенах, всюди забрав всі selector concatenation'и (але може не всі, треба буде проклікувати і фіксити).

І що НЕ зроблено:

  • ❌ Видалити SCSS як залежність з апплікейшенів (хз навіть, чи це можливо).
  • ❌ Присутні деякі копі-пасти типографії замість @extendʼів.

Нюанси ​

CSS i repeatable-типографія для інших утилітарних класів (коли "не вистачає" @extendʼів) ​

В процесі міграції стикнувся з таким кейсом:

  1. У нас в адмінці є титулка для таблички (хай буде .table-title) і вона мала такий scss:
scss
.table-title {
  @extend .typo-heading-3;
  //...other styles
}
  1. Питання: як її мігрувати, якщо немає @extendʼів?

Прямий шлях (1) – це копі-пастити CSS з .typo-heading-3 у .table-title.

Прямий шлях (2) – це копі-пастити назву класу .typo-heading-3 у всі <template> блоки, де використовується .table-title.

Обидва шляхи – всраті. І виходить, що обидва є погані.

І от я задумався: а як це має працювати на чистому CSS, але щоб це виглядало "пристойно"?

І, дійшов такого висновку:

Це має бути окремий компонент для цієї титулки. В якому, вже один раз буде написаний class=typo-heading-3. І потім всюди буде перевикористовуватись.

Проблема тоді лише одна – "треба порефакторити".

CSS i Viewport Breakpoints ​

Не мігровані: CSS не вміє роздупляти var(--) у @media запити. Тому, тут лишилась SCSS'ка, щоб не копі-пастити raw values, і не мігровувати ті компоненти.

Тому, у нас з @webitel/styleguide експортується SCSS файл для viewport breakpoints 🥲

Мотивація для міграції ​

Складність підтримки SCSS ​

Основна проблема: його регулярно треба було доналаштовувати, щоб він корректно працював і не валив білди. Не те щоб це треба було робити часто, але коли таке траплялося, то починалася біда.

(Мінімальні) бенефіти від використання SCSS ​

З фічів scss ми юзали тільки @extend'и і selector concatenation'и.

Селектор конкатенація – зручна, але у великому проєкті втрачає читабельність:

  1. Важко шукати стилі певного класу глобальним пошуком (бо повна назва класу може не писатися, а використовується конкатенація)

  2. Може бути важко IDE'шці "провалитись" на стилізацію класу з темплейта – та ж причина.

  3. Читабельність. Субʼєктивно, але мені здається що для нашого кейсу (багато коду, мало стилів, long-term maintenance) читабельність знижується, а зручність написання не переважає.

Екстенди – зручні, але не достатньо, щоб перекрити попередні недоліки.