To jest post przetłumaczony przez AI.
Wybierz język
Tekst podsumowany przez sztuczną inteligencję durumis
- W Next.js plik .env jest konfigurowany podczas kompilacji, ale czasami należy ustawić zmienne środowiskowe po kompilacji, w zależności od środowiska produkcyjnego (lokalne, dev, qa, prod).
- Użytkownicy Windows nie mogą używać tradycyjnych skryptów opartych o Unix, dlatego muszą zainstalować cross-env i napisać skrypt, który działa w obu systemach: Windows i Unix.
- Zastosowaliśmy cross-env do poleceń start i dev, aby skonfigurować zmienne środowiskowe i uporządkować skrypt, zwiększając jego czytelność.
W Next.js .env jest wbudowany podczas kompilacji.
Jednak czasami istnieje wiele potrzeb, aby ustawić env podczas uruchamiania skompilowanego obrazu, a nie podczas kompilacji.
Zwykle dzieje się tak, ponieważ zarządzamy środowiskami lokalnymi, deweloperskimi, testowymi i produkcyjnymi.
Jak więc możemy to zrobić?
Większość kontekstów jest podobna do poniższego artykułu.
Jednak ten artykuł odrzuca Windows.
Można to zauważyć, umieszczając składnię Unixa w skryptach package.json.
Oznacza to, że uczciwy, czysty i troskliwy użytkownik Windows nie może użyć tego skryptu, ponieważ nie używa brudnego Unixa.
Dlatego uczciwy i troskliwy użytkownik Windows powinien pokazać troskę o użytkownika Unixa, umieszczając w zamian skrypt, który działa poprawnie na obu systemach operacyjnych.
Rozwiązanie jest proste.
Możemy umieścić skrypt, który robi to samo, co ta składnia.
Używając powyższego polecenia, instalujemy cross-env.
I to wszystko, wystarczy zmodyfikować polecenie start wspomniane powyżej, jak pokazano poniżej.
Jednak skrypt jest zbyt długi, co utrudnia jego czytanie, a ponadto musimy go dołączyć do polecenia dev.
{
"dev": "npm run _env:-local && next dev",
"dev:dev": "npm run _env:dev && next dev",
"start": "npm run _env:-local && next start",
"_env:-local": "cross-env-shell node ./utils/cli.js next-env -e $APP_ENV",
"_env:dev": "node ./utils/cli.js next-env -e dev"Dlatego uporządkowałem go w ten sposób.
