znaczacy > comp.lang.* > comp.lang.javascript

Roman Tyczka (11.01.2019, 10:19)
Mam zatem tego webpacka skonfigurowanego, w nim babel i inne dodatki.
I teraz mam kod, klase, która sluzy do laczenia do serwera REST, klasa jest
w osobnym pliku, ale ES6 ma funkcjonalnosc import wiec to nie problem. Ale
ta klasa w konstruktorze oczekuje obiektu z parametrami polaczenia do tego
serwera i oczywiscie inne sa te dane dla produkcji a inne dla deweloperki.
Na poziomie generowania plików webpackiem, wiem czy generuje w trybie
produkcji czy deweloperskim. Jak to polaczyc? Czyli w jaki sposób zrobic
przekazywanie parametrów zaleznie od trybu pracy webpacka?

W PHP bylo prosto, mialem dwa pliki konfiguracyjne o tej samej nazwie, ale
róznej zawartosci, wiadomo o co chodzi. Tutaj nie wiem jak to ugryzc.
Roman Tyczka (11.01.2019, 12:48)
On Fri, 11 Jan 2019 09:19:25 +0100, Roman Tyczka wrote:

> Mam zatem tego webpacka skonfigurowanego, w nim babel i inne dodatki.
> I teraz mam kod, klase, która sluzy do laczenia do serwera REST, klasa jest
> w osobnym pliku, ale ES6 ma funkcjonalnosc import wiec to nie problem. Ale
> ta klasa w konstruktorze oczekuje obiektu z parametrami polaczenia do tego
> serwera i oczywiscie inne sa te dane dla produkcji a inne dla deweloperki.
> Na poziomie generowania plików webpackiem, wiem czy generuje w trybie
> produkcji czy deweloperskim. Jak to polaczyc? Czyli w jaki sposób zrobic
> przekazywanie parametrów zaleznie od trybu pracy webpacka?


Troche mi to zajelo, ale mam rozwiazanie i nawet dziala, choc inaczej niz
chcialem:

Borys Pogorelo (11.01.2019, 13:43)
Dnia Fri, 11 Jan 2019 11:48:43 +0100, Roman Tyczka napisal(a):

> Troche mi to zajelo, ale mam rozwiazanie i nawet dziala, choc inaczej niz
> chcialem:


Nie kombinuj z róznymi buildami dla testów/produkcji, tylko skorzystaj z
plików konfiguracyjnych lub zmiennych srodowiskowych.
Roman Tyczka (11.01.2019, 14:13)
On Fri, 11 Jan 2019 12:43:05 +0100, Borys Pogorelo wrote:

>> Troche mi to zajelo, ale mam rozwiazanie i nawet dziala, choc inaczej niz
>> chcialem:

> Nie kombinuj z róznymi buildami dla testów/produkcji, tylko skorzystaj z
> plików konfiguracyjnych lub zmiennych srodowiskowych.


W package.json mam kilka buildów:

"dev": "webpack --mode development",
"build": "npm run clean && webpack --mode production"

ale webpack.config.js mam jedno i w nim sprawdzam "mode" i steruje
przetwarzaniem plików, czy inaczej to powinienem robic?
Borys Pogorelo (11.01.2019, 14:34)
Dnia Fri, 11 Jan 2019 13:13:44 +0100, Roman Tyczka napisal(a):

> ale webpack.config.js mam jedno i w nim sprawdzam "mode" i steruje
> przetwarzaniem plików, czy inaczej to powinienem robic?


To znów nie ma zadnego zwiazku z webpackiem, chyba ze konkretnie chcesz
miec inne pakiety wynikowe na produkcje (np. z wycietym kodem debug). To
aplikacja powinna wspierac rózne konfiguracje zaleznie od srodowiska.
Roman Tyczka (11.01.2019, 14:39)
On Fri, 11 Jan 2019 13:34:10 +0100, Borys Pogorelo wrote:

>> ale webpack.config.js mam jedno i w nim sprawdzam "mode" i steruje
>> przetwarzaniem plików, czy inaczej to powinienem robic?

> To znów nie ma zadnego zwiazku z webpackiem, chyba ze konkretnie chcesz
> miec inne pakiety wynikowe na produkcje (np. z wycietym kodem debug). To
> aplikacja powinna wspierac rózne konfiguracje zaleznie od srodowiska.


Ok, to napisz konkretniej jak to powinno wygladac, bo mi nic te zdawkowe
odpowiedzi nie podpowiadaja, a chetnie sie dowiem jak to sie poprawnie
robi. Póki co mam tak, ze mam dwie "kompilacje", jedna produkcyjna, która
jest zminifikowana (bez komentarzy, bez console.log, itd.), a druga
developerska/debugowa, która ma pelny kod i moge ja testowac. Sama
aplikacja JS jest w jednej wersji, poza drobna róznica z adresami serwera
RESTowego do którego sie laczy.
Borys Pogorelo (11.01.2019, 18:12)
Dnia Fri, 11 Jan 2019 13:39:32 +0100, Roman Tyczka napisal(a):

> developerska/debugowa, która ma pelny kod i moge ja testowac. Sama
> aplikacja JS jest w jednej wersji, poza drobna róznica z adresami serwera
> RESTowego do którego sie laczy.


Ja polecam przykladowo ten pakiet:

który pozwala latwo laczyc zmienne srodowiskowe z plikiem konfiguracyjnym -
wtedy mozesz sobie to poukladac jak tylko Ci wygodniej. A obiekt parametrów
polaczenia sobie budujesz z wartosci odczytanych z process.env.*
rePeter (11.01.2019, 20:11)
Fri, 11 Jan 2019 09:19:25 +0100
Roman Tyczka <noemail> napisal(a):

> Mam zatem tego webpacka skonfigurowanego, w nim babel i inne dodatki.
> I teraz mam kod, klase, która sluzy do laczenia do serwera REST, klasa jest
> w osobnym pliku, ale ES6 ma funkcjonalnosc import wiec to nie problem. Ale
> ta klasa w konstruktorze oczekuje obiektu z parametrami polaczenia do tego
> serwera i oczywiscie inne sa te dane dla produkcji a inne dla deweloperki.
> Na poziomie generowania plików webpackiem, wiem czy generuje w trybie
> produkcji czy deweloperskim. Jak to polaczyc? Czyli w jakisposób zrobic
> przekazywanie parametrów zaleznie od trybu pracy webpacka?
> W PHP bylo prosto, mialem dwa pliki konfiguracyjne o tej samej nazwie, ale
> róznej zawartosci, wiadomo o co chodzi. Tutaj nie wiem jakto ugryzc.


Wystarczylby jeden plik konfiguracyjny z warunkiem sprawdzajacym czy jest odpalony na
localhoscie czy gdzie tam masz srodowisko developerskie. To samo w JS.
Podobne wątki