Конфиги

NODE_ENV позволяет определить, было ли приложение собрано. Например, при сборке приложения через jenkins на дев-машину NODE_ENV все равно будет равна 'production'. NODE_ENV доступна в приложении.

REACT_BOILERPLATE_ENV зависит от машины и может использоваться для настройки частей конфигов. Пример: isOutputAppInfo: process.env.REACT_BOILERPLATE_ENV !== Env.PROD. Для избежания путаницы рекомендуется не прокидывать REACT_BOILERPLATE_ENV в приложение напрямую. Вместо этого можно воспользоваться приемом из примера выше.

Основной файл - ./config/config.js. Переменные окружения (в частности, REACT_BOILERPLATE_ENV) можно использовать только тут.

При разработке переопределять эти конфиги можно в файле ./config/local.js.

• ConfigBuilder хочет работать с файлами на диске, что противоречит webpack-dev-middleware, который держит файлы в ОП.
• ConfigBuilder в принципе слишком громоздкий.

// Например, скрипт для генерации схемы Apollo.
const { config } = require('../../config');
console.log(config.api.graphqlEndpoint);

Приложение использует подмножество полей конфигов. Они не импортируются из ./config, вместо этого они доступны на объекте global.

Передача конфигов в приложение зависит от того, где выполняется рендеринг:

• Client-side - конфиги передаются с HTML.
• Server-side - конфиги задаются при старте сервера на основе импортированного ./config. Важно, что импортировать конфиг можно только для инициализации global.

• Доступность на global вместо импорта - для изоморфности.
• Использование подмножества полей - полный контроль над тем, что попадает в приложение, нормальные имена констант.

Указанные выше конфиги доступны в рантайме и зависят от переменных окружения (в частности, среды). Однако, некоторые данные доступны на момент сборки и не могут меняться в зависимости от переменных окружения (время сборки, ветка, версия, ssr mode и т.п.). Такие данные лучше передавать с помощью webpack.DefinePlugin.

• Возможность изменять конфиги в рантайме позволяет использовать одну и ту же сборку на разных машинах (dev, qa, prod).
• Так работает текущий деплой.
• Неизменные данные лучше по-прежнему передавать вебпаком, потому что это производительнее и проще для разработчика.