Конфигурация Tailwind для пакета, используемого в нескольких приложениях
В рамках системы дизайна моей организации у меня есть пакет под названием «core», из которого я экспортирую весь CSS. В приложениях он является зависимостью и устанавливается как node_module в их приложении.
Недавно я добавил Tailwindcss в свой «основной» пакет, но классы Tailwind не будут применяться к приложениям, использующим мой пакет, поскольку они не могут указать путь content.
module.exports = {
content: [], -> This resides in my "core" package and apps cannot modify it
theme: {
extend: {}
},
plugins: []
};
Один из вариантов — использовать свойство safelist в файле tailwind.config.js и добавить весь CSS, который мне нужен, но я не хочу этого делать. Я хочу, чтобы конечное приложение могло использовать любой класс попутного ветра, а также воспользоваться функцией JIT-компилятора/очистки попутного ветра, чтобы их пакет не включал весь CSS попутного ветра.
Как приложения, использующие мой пакет, могут динамически указывать путь content?
PS. Я использую rollup, если это имеет какое-то значение.
Любая помощь приветствуется, спасибо!
Ответы 1
Решением, которое я реализовал для аналогичной проблемы, было предоставление конфигурации попутного ветра в моей библиотеке вместе с несколькими функциями (например, mergeConfig(customConfig)).
Как только файл конфигурации будет открыт, ваши приложения смогут использовать его для объявления своей собственной конфигурации попутного ветра, но это означает, что в каждом приложении должен быть установлен попутный ветер.
Другой подход заключается в том, чтобы предоставить ваши окончательные скомпилированные стили вместо тех, которые должны быть скомпилированы попутным ветром.
Прежде чем стать файлом конфигурации для попутного ветра, это всего лишь файл Javascript, который запускается NodeJS, когда попутный ветер должен создать файлы CSS. Это означает, что вы можете просто экспортировать его, как и любой другой файл JS.
Ах, теперь я понимаю ваш подход. В вашем потребительском приложении установлен попутный ветер, и вы просто объединяете две конфигурации в потребительском приложении tailwind.config.js, верно? Мое требование состоит в том, чтобы потребительскому приложению не приходилось устанавливать попутный ветер, поскольку они использовали мой «основной» пакет, который предоставляет им попутный ветер. Надеюсь, вы поняли мою точку зрения.
У вас есть подход, и я понимаю вашу точку зрения. Это мой второй подход, при котором вам нужно скомпилировать свои стили и отправить их вместе с вашим приложением: если вы не установите попутный ветер на потребителей, у вас не будет возможности их скомпилировать, так что это единственное жизнеспособное решение. Другим очень громоздким решением может быть создание двоичного файла для компиляции файлов на стороне потребителя, но это всего лишь дополнительные шаги для того же результата...
Ваше последнее замечание кажется интересным. Не могли бы вы рассказать немного больше?
Не совсем потому, что я этого не делал, но приведу пример: когда кто-то использует Angular, можно ввести npx ng generate component my/component : это двоичный файл, который вы можете найти в своем node_modules/.bin каталоге : вашей целью будет воспроизвести это поведение, чтобы пользователь мог ввести npx yourlib compile-css (или что-то подобное), и CSS Tailwind скомпилировался бы в обычный CSS. Но опять же, это просто более (сложные) шаги по сравнению с предыдущим подходом, который заключается в прямой отправке скомпилированного CSS!
Спасибо, приятель! Я собираюсь использовать ваше оригинальное решение для объединения конфигурации в потребительском приложении. Спасибо, что уделили мне время :)
Я понимаю, что мы можем экспортировать функцию из
tailwind.config.jsв основной пакет вместо объекта. Но как это будет экспортировано в другие пакеты?