я запитав які практики  використовують люди для конкртеного випадку.

не увидел про css модули

Коли стилі будуть зібрані в такому порядку тоді гуд, буде те що потрібно ЖОВТИЙ.

Коли в такому - то НІ (

Думаю все будет зависеть от порядка в котором ты будешь импортировать компонент (в твоём кейсе кнопку) и стили текущего компонента, которыми ты хочешь перебить

ну так, тут модули не при чем, так css работает

Ну от я не хочу від нього залежати, хочу якийсь вихід адекватний для ксс модулів

В ксс можна .hash1.hash2

так зачастую это делает бандлер

мне тоже была бы полезная эта инфа

возможно ли как-то указать приоритизацию css модулей в вебпаке

!important? 😅

Здається такий реквест напряму протилежить філосліії css modules де вони примусово відмовляються від букви C у CSS. Певно з їх боку таких реквестів у реальному житті немає)

В мене питання тому і виникло, так як колега почав саме це робити.
Я раніше та і зараз, через родича перебиваю, але мені здаєтсья що так собі варіант (

Можна composes їхній юзати, але теж якось мені не дуже цей підхід

Вони кажуть, що неможна

Іднотична поведінка, як на мене

Note that when composing multiple classes from different files the order of appliance is undefined. Make sure to not define different values for the same property in multiple class names from different files when they are composed in a single class.

Можна, якщо класс який ти вішаєш на компонент не додавати. а змінювати той що зараз, і потім композ, і перетирати пропси які хош. Але це ОВЕР дохера всього 🙂

Ребят, кто-то из вас не задавался такой проблемой? Есть куча пакетов написанных на жс, со времен когда ещё TS не было. Сейчас все идут на TS, а старый код очевидно никто трогать не хочет. Мы его просто тайпингами вручную покрываем и пишем d.ts файлы для них.

Проблема: мы не хотим реализацию и хедер-файлы совать в один пакет. Мы хотим отдельно публиковать реализацию и отдельно хедер-файлы. Может кто-то уже автоматизировал у себя сборку d.ts файлов в отдельные пакеты?