Как вы используете узел-узел в глубоко вложенной структуре каталогов?

Question

Документация для узла-sass, по общему признанию, немного упрощена при использовании из командной строки. В настоящее время я заинтересован в использовании NPM Scripts в качестве инструмента построения.

У меня есть проект, который имеет множество компонентов, организованных функцией. Каждая функция представляет собой отдельную папку. Существуют более крупные компоненты, которые содержат меньшие компоненты, и любое количество из них будет иметь свои собственные файлы .scss.

Проблема, с которой я сталкиваюсь, заключается в том, что в документах не ясно, как можно использовать узел-узел, чтобы легко скомпилировать все эти файлы до одного файла.

Существует способ скомпилировать файлы .scss из одной директории и помещать в другую, но это сохраняет их как отдельные файлы. Существует еще одно предложение, которое использует cat cat <input> | node-sass > <output>, но cat не является рекурсивным, и не использует globs, поэтому вы можете получить только один уровень css.

Есть ли способ использования узла-узла, чтобы он мог рекурсивно просматривать все файлы заданного каталога и скомпилировать их в одну таблицу стилей CSS?

Answer 1

Лучший способ, который я нашел до настоящего времени, является довольно тупым.

используется find рекурсивно найти все нужные файлы, то, что получает выход к cat который помещает все это вместе, а затем, наконец, к node-sass и выходу на конечный файл.

find src/apps/section -name '*.scss' -print0 | xargs -0 cat | node-sass > ./dist/css/section.css 

В идеале, узел-дерзость должен принимать Glob и оперировать результатами, но это либо не доросли еще, или команда не сосредоточены на создании этой функции. IMO, любой вид компилятора, будь то для html-шаблонов, трансмиляции или миниатюры JS или что-то еще, чтобы принять глобус и вывести один файл. Не похоже на краевой случай ... но что я знаю.

Узел Sass имеет рекурсивный вариант, но текущие документы говорят, что это только для просмотра. Существует discussion об этой опции, но изложены причины, по которым многофайловая компиляция не является целевой функцией (sourcemaps и т. Д.). :/

Мне бы хотелось, чтобы у большего количества инструментов была лучшая или более совершенная возможность обработки файлов, и позвольте мне передать все мои наблюдения одному сценарию, например npm-script-watcher. Он смотрит и запускает скрипты, вот и все. Одно изменение файла может инициировать однократную переборку, сборку и тестирование. Это лучше, чем флаг наблюдателя для linter, флаг наблюдателя для строителя и наблюдателя для тестировщика, а затем дублирует скрипты для каждого, если я только хочу запускать lint, строить или тестировать один раз, не запустив свои функции часов.