W każdym co bardziej złożonym projekcie zachodzi potrzeba przechowywania różnych konfiguracji w zależności od środowiska: developerskiego, produkcyjnego, testowego, eksperymentalnego, niebieskiego i każdego innego. Oczywiście framework VueJS nie odstaje od normy i również oferuje możliwość takiej konfiguracji.
Na początku od razu zaznaczam, że zmiany w plikach konfiguracyjnych lub tworzenie nowych plików wymaga ponownego przebudowania i uruchomienia aplikacji – brak odzwierciedlania jakichkolwiek zmian w aplikacji może się okazać dość frustrujące jeśli zapomnimy o tej czynności – a często w konsoli widzimy, że się przebudowało – tylko jednak coś zmian z konfiguracji nie chwycił.
Konfiguracja dla różnych środowisk przechowywana jest domyślnie w 3 plikach (po utworzeniu czystego projektu):
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
./projekt/config/prod.env.js | |
./projekt/config/dev.env.js | |
./projekt/config/test.env.js |
Wyżej wymienione pliki ładowane są dokładnie w tej kolejności ewentualnie rozszerzając lub nadpisując dotychczasowe wartości zmiennych, więc w czystej instalacji na początku wczytywany jest plik prod.env.js
, stałe w nim zawarte nadpisywane są plikiem dev.env.js
a te z kolei test.env.js
. Proste i logiczne (…długie jak drzewo genealogiczne naszej rasy…)
Oczywiście nic nie stoi na przeszkodzie aby, jeśli zajdzie taka potrzeba, dodawać swoje pliki konfiguracyjne definiujące ustawienia dla nowych środowisk. Np. staging – dodając przykładowo plik staging.env.js
o przykładowej treści:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
'use strict'; | |
const merge = require('webpack-merge'); | |
const prodEnv = require('./prod.env'); | |
module.exports = merge(prodEnv, { | |
NODE_ENV: '"staging"', | |
API_URL: '"http://staging-api.server.com/"' | |
}); |
i wtedy np. w pliku dev.env.js
rozszerzamy środowisko stagingEnv
– a nie prodEnv
jak to jest domyślnie.
Samo ustawienie bieżącego środowiska – wg którego budowany i uruchamiany jest VueJS odbywa się w pliku ./projekt/src/main.js
w linijce:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Vue.config.productionTip = false; |
chociaż lepszą z praktycznego punktu widzenia wersją byłaby poniższa:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Vue.config.productionTip = process.env.NODE_ENV === 'production'; |
I teraz, jeśli zawsze (we wszystkich środowiskach) potrzebujemy w aplikacji jakieś stałe to definiujemy je w pliku prod.env.js
odpowiednio nadpisując w pozostałych plikach, jeśli oczywiście jakieś zmiany będą potrzebne.
W komponentach nic nie musimy importować, a dostęp do zmiennej jest wygląda w taki sposób: process.env.API_URL
Jeśli zbudujemy teraz projekt dla odpowiedniego środowiska, np.: dla produkcji npm run build
otrzymamy katalog dist
, w którym to znajduje się zbudowana chwilę temu aplikacja. Przechodząc w linii poleceń do tego katalogu cd ./projekt/dist
i uruchamiając tymczasowy serwer python3 -m http.server 8181
, w przeglądarce pod adresem 127.0.0.1:8181
powinna być dostępna nasza aplikacja – warto w tym miejscu potwierdzić różniące się między środowiskami zmienne, żeby nie było nieprzyjemnych niespodzianek.