#vue.js #environment-variables
#vue.js #переменные среды
Вопрос:
Я работаю над приложением VueJS, которое использует переменные среды в нескольких местах. Он работает на GCloud с nginx, обслуживающим скомпилированные файлы vue-cli-service build .
При разработке все хорошо работает с переменными env, установленными в .env.development .env.development.local файлах и и используемыми в JS с. process.env.VUE_APP_FOO Я не использую .env.production , поскольку некоторые из этих переменных env не должны быть переданы в наш репозиторий.
Для промежуточной и рабочей среды всех наших проектов мы используем карты конфигурации GCloud, которые позволяют нам предоставлять переменные среды для модулей. Проблема в этом проекте заключается в том, что vue-cli-service build требуется, чтобы переменные среды были доступны во время сборки, чего нет в нашей настройке. Карты конфигурации доступны только в модулях, которые запускают изображения.
Из любопытства я проверил скомпилированный код, и все варианты использования process.env are довольно просто заменены объектом со всеми переменными vue env (базовые VUE_APP_* единицы). Так, например,
console.log(process.env.VUE_APP_FOO);
компилируется для
console.log(Object({NODE_ENV: "production", BASE_URL: "/", VUE_APP_FOO: "bar"}).VUE_APP_FOO);
За исключением того, что в нашем случае VUE_APP_FOO отсутствует в объекте, поскольку он недоступен в среде при сборке приложения.
Итак, как есть, не представляется возможным предоставлять переменные среды при запуске сервера или при подаче файла JS. Есть ли способ указать vue-cli-service , чтобы не компилировать env таким образом? Или любая другая альтернатива?
Единственное, что я нашел до сих пор, это заменить использование переменных env на их фактическое значение непосредственно в скомпилированном файле JS, когда модуль начинает использовать sed , но это довольно некрасиво и может легко сломаться.
Комментарии:
1. Да, образ docker создается с использованием Drone (компилируется, а затем файлы dist копируются в изображение), а затем передаются в GCloud.
2. Да, но, учитывая наши текущие настройки, это потребует от нас хранения env в репозитории, чего мы не хотим делать. Также, как упоминалось в другом комментарии ниже, это превращает «переменные среды» в «параметры сборки», что также нарушает нашу обычную настройку. Обновление переменной env должно требовать только перезапуска pod, а не полной перестройки.
3. «Как перезапуск pod обновит скомпилированные ресурсы, которые ссылаются на VUE_APP_FOO» => у нас есть другие проекты, ссылающиеся на переменные среды (например, os.getenv в Python). Для их изменения требуется только загрузка нового контейнера с обновленной конфигурационной картой, перестраивать не требуется. Опечатка в URL-адресе или ключе API может возникнуть даже при сборке проекта, было бы более досадно, если бы нам пришлось выполнять полную перестройку вместо простого перезапуска модулей.
Ответ №1:
Один из подходов, которому вы можете следовать, — это предоставление производственных значений при локальной сборке. Другой подход заключается в настройке процесса непрерывной интеграции, который извлекает переменные среды из любого места, где они хранятся, создает приложения и отправляет их на производственные серверы. Я лично работаю с подходом 2. Относительно легко настроить рабочий процесс github, который запускается всякий раз, когда ваш код передается в частичную ветку
Комментарии:
1. Что меня беспокоит, так это то, что эти переменные на самом деле являются переменными env, а не параметрами сборки. Для их изменения должен потребоваться только перезапуск контейнера, а не полная перестройка, как это работает в других наших проектах. Вот почему я искал опцию «время выполнения».
2. У вас запущено веб-приложение, а не сервер. Все переменные среды должны быть включены в приложение во время сборки.. Поэтому, когда в любом из них происходят изменения, требуется полная перестройка
3. У вас не может быть опции времени выполнения для веб-приложения, поскольку среда выполнения — это браузер пользователя. Теперь вы не можете установить переменные среды на компьютере другого пользователя, не так ли?
4. «Все переменные среды должны быть включены в приложение во время сборки ..». Зачем им это нужно? У нас есть другой веб-сайт и API, где многие переменные заполняются при подаче JS. Например, в шаблонах rails ERB используется
const foo = <%= Rails.appilcation.config.bar %>, гдеbarсам определяется при запуске сервера на основе переменных среды.5. Я мало что знаю о ruby в rails, но я считаю, что это должно быть решение для рендеринга на стороне сервера. Создание приложения с использованием фреймворка javascript, такого как Vuejs, обычно включает в себя процесс сборки, объединяющий все необходимое для запуска приложения, так что ему не нужно связываться с сервером, чтобы получить какую-либо информацию, кроме статических встроенных файлов