Раньше я писал о том, как я использую сценарии npm для своих инструментов сборки.
В этой статье я хочу написать о некоторых проблемах, которые у меня были, и о том, как я их решил.
Проблемы, о которых я хочу поговорить дальше:
- Параллелизм
- Расширенная конфигурация сборки
- Построить среду
Цель создания моей структуры сборки:
- Строим быстро
- Решайте все задачи сразу
- Свобода расширения
npm против пряжи
За последние пару недель я решил переместить все проекты, над которыми я работаю, с npm на пряжу для сборок. Это так, потому что я считаю, что пряжа намного быстрее, чем npm. Yarn - это менеджер пакетов для вселенной JavaScript. Он утверждает, что он быстрее, чем npm, надежен и безопасен.
При использовании пряжи есть несколько проблем, которые в основном встречаются в частных репозиториях. Для большинства моих текущих проектов я использую открытые библиотеки в качестве зависимостей, например. г. React, jQuery, lodash и другие, а это значит, что я пока не касался этих проблем.
Решение проблем
Как я уже упоминал, есть пара проблем, которые очень типичны для любых проектов, и я хочу рассказать о своих решениях для них.
Параллелизм
Для некоторых задач нет необходимости запускать их синхронно, а скорее для экономии времени при сборке. Здесь в игру вступает параллелизм. Например, сборка CSS может выполняться одновременно с сборкой JavaScript.
Другой пример - наблюдатель, который запускает сервер проекта и следит за изменениями в JavaScript и CSS, чтобы запустить процесс сборки.
Для этой задачи я использую одновременно. Я уже упоминал об этом раньше и до сих пор очень этому рад.
Использование: Просто запустите несколько процессов параллельно. Например, сервер и наблюдатель CSS:
concurrently "yarn run server" "yarn run css:change"
Примечание. Закройте "
перед копированием и вставкой этого кода в свой package.json
.
Расширенная конфигурация сборки
Для некоторых процессов сборки необходимо настроить больше, чем просто одну волшебную строку командной строки. Для этого я использую отдельные скрипты. Либо сценарии, которые выполняются как сценарии оболочки, либо на Node.js.
Например, для моей сборки CSS я использую сценарий Node, который я могу легко назвать следующим образом
node ./scripts/css.js
Для других скриптов пригодится файл bash.
Построить среду
При запуске сборки JavaScript я хочу, чтобы ее можно было читать в моей среде разработки, а также минимизировать и сжимать на любом этапе или в производственной среде. Я могу добиться этого, используя разные команды для сборок. Еще я использую переменные среды. Вы можете легко проверить переменные и затем действовать соответствующим образом.
Например, я часто включаю конфигурацию, основанную на среде. Вот пример:
Давайте запустим команду yarn run build
и установим переменную среды следующим образом:
export ENV=prod && yarn run build
В Node вы можете определить переменную, используя process.env.ENV
.
-- scripts
|-- config.default.js
|-- config.prod.js
|-- config.stage.js
В config.default.js
теперь вы можете определить, есть ли файл конфигурации для текущей среды.
let fs = require('fs');
// You need to install the package if you want to use it. let extend = require('deep-extend'); let parameters = process.env;
let config = { assetPath: 'assets/', debug: true, // ... };
/** * Check if a file exits * @param {String} filePath Path to file which should be checked. * @return {Boolean} True if file exits */ let isFile = (filePath) => { let stats = fs.lstatSync(filePath);
if (stats.isFile()) { return true; }
return false; };
if (parameters.ENV) { if (isFile(__dirname + '/config.' + parameters.ENV + '.js')) { let envConfig = require('./config.' + parameters.ENV + '.js');
// Merge default and environment config config = extend(config, envConfig); } }
module.exports = config;
Вывод
Конечно, проблем с использованием скриптов npm больше. Вы их нашли и решили? Дайте мне знать через Twitter.