LINUX.ORG.RU

Вопрос по Nodejs со звездочкой (*)

 ,


0

1

Сразу говорю, что я не пишу на Node и сейчас просто пытаюсь адаптировать наш пайплайн для её раскатки на различные среды.

Разработчики говорят мне что у них в коде есть такая строка:

export const API_URL = process.env.REACT_APP_API_URL;

Которая локально у их инициализируется значением из .env

Но на вопрос на каком этапе эта переменная получает значение из .env они не знают.

Так вот у нас в пайплайне на этапе сборок никаких переменных нет, кроме совсем элементарных.

А вот при запуске, они приезжают, и всем ЯП этот вариант катит, похоже плохо от этого только Nodejs.

Так вот на каком этапе передаются значния переменных в ноду, сборки или запуска?

Я вроде уже сам все понял, но хочу мнение СПВ.


Энв это та штука где у тебя PATH прописан, например. Ясное дело что всасывает при запуске т.к. сборка тут есть только у самой ноды.

Вообще я бы рекомендовал сделать нормально т.к. енв один на все процессы (у нормальных людей).

Соответственно на одном хосте раскатывать несколько инстансев смысле нет т.к. все получат один и тот же урл, поэтому надо из аргументов запуска брать или конфига. А если ты в докере запускаешь, то тогда проще захардкодить apihost:3000 и резловить его через докер (т.е. пользовать его по прямому назначению). А так только деплой успложняет.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 2)
Ответ на: комментарий от user13

через nginx и какой то хотрый index

Собственно пускай там и чинят: откуда процесс «хитрого индекса», а не как у нормальных людей по Unix сокету или на худой конец TCP сокету, должен иметь в себе полный env

ac130kz ★★
()

Если приложение создано с помощью create-react-app, то у него в зависимостях будет react-scripts, а у того в зависимостях есть dotenv, который, собственно, и подгружает переменные окружения из файла .env: https://github.com/facebook/create-react-app/blob/main/packages/react-scripts/config/env.js#L36

static_lab ★★★★★
()
Ответ на: комментарий от user13

Не, переменные попадают во фронтовое приложение на этапе его сборки. Они туда буквально вкомпиливаются. После сборки получаются статические ассеты (index.html, *.js, *.css), которые нужно просто хостить любым способом.

static_lab ★★★★★
()
Ответ на: комментарий от user13

Как я и говорил, у nodejs нету «сборки», переменные подтягиваются при запуске команды «node».

Я понял проблему и в чем путаница.

Твоя ошибка в том, что у тебя, видимо, не Node.JS приложение, а React-фронтенд.

Сборщик React’a написан на Node.JS, и подтягивает переменные с префиксом REACT_APP_ при сборке.

https://create-react-app.dev/docs/adding-custom-environment-variables/

MaZy ★★★★★
()
Ответ на: комментарий от MaZy

А вообще это проверяется моментально,

Собираешь приложение локально с рандомной переменной, потом грепаешь по итоговому билду и смотришь подтянулось или нет.

Самый топорный, но безошибочный вариант

MaZy ★★★★★
()

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

George
()
Ответ на: комментарий от user13

Потому что не все могут знать, что переменные вида REACT_APP_API_URL относятся к фронтендным приложениям, сгенерированным с помощью create-react-app, а в остальном по тексту вопроса выглядит так, будто ты пытаешься запускать бекендное приложение на Node.js.

static_lab ★★★★★
()
Последнее исправление: static_lab (всего исправлений: 1)
Ответ на: комментарий от user13

эээ а вот это не знаю точно, на самом деле и я не знаю многого о том чем пользуюсь, ладно будем терпимы друг другу

Да ничего, нормально. Главное, чтобы как ты написал, доктора не говорили ;) Бегает случай по инету, где из-за создателей UI на планшете в скорой не отобразился список с аллергией. ПАциентка умерла. Но ты не переживай

Neuromagus
()
Ответ на: комментарий от user13

эээ а вот это не знаю точно

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

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

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

user13
() автор топика
Последнее исправление: user13 (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

енв один на все процессы

Не верно. У каждого докер образа прописываются переменные окружения. У systemd юнитов тоже. В целом один из стандартных способов передачи параметров в демон помимо аргументов командной строки (например, так принято передавать секреты, чтобы не палить их в выводе ps). Одинаковые переменные окружения только у мышкотыкательных приложений, запускаемых из DE.

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от KivApple

У каждого докер образа

Если у тебя докер, то нет никакого смысла передавать адреса через переменные. Просто хардкодишь имя хоста и порт и резолвишь всё докером. Его, блин, для того и сделали.

ya-betmen ★★★★★
()

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

antech
()
Ответ на: комментарий от ya-betmen

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

George
()

В 99% будет на уровне запуска, после инициализации dotenv в global. Есть малочисленные случаи, когда ректальные макаки пихают код сервера так же в dist. И вот тут зависит от упоротости автора. Если он написал нечто странное, то может получать на уровне билда значение, читать и представлять в исходник данные (записывать из собираемый dist). Но судя по комментам твоих макак они до этого еще не дошли)

small-entropy
()
Ответ на: комментарий от George

Докеру пофиг что и где у тебя в реальности, ты ему что угодно в конфиге можешь скормить. Твоя передача через энв, это усложнение конфигурации, которая при наличии докера бесполезна, а при отсутствии докера вредна.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Начну со второго вопроса - докер сейчас - инструмент разработки, типа как ide. Быстренько запустить всякую фигню, быстренько потом удалить. Для условного прода не подходит. Концепт хранения настроек в энвах не мой, и ему уже много лет. Нужен для того, чтобы собирать образ один раз, запускать потом в любой среде. И не плодить сущности, типа конфигмапы с настройками.

George
()
Ответ на: комментарий от George

докер сейчас - инструмент разработки

Концепт хранения настроек в энвах не мой, и ему уже много лет.

Конечно, когда в руках молоток, всё вокруг становится похоже на гвозди.

не плодить сущности, типа конфигмапы

Ты их плодишь в другом месте просто.

ya-betmen ★★★★★
()