Warunkowy import

[Roman Tyczka]

Mam zatem tego webpacka skonfigurowanego, w nim babel i inne dodatki.
I teraz mam kod, klasę, która służy do łączenia do serwera REST, klasa jest
w osobnym pliku, ale ES6 ma funkcjonalność import więc to nie problem. Ale
ta klasa w konstruktorze oczekuje obiektu z parametrami połączenia do tego
serwera i oczywiście inne są te dane dla produkcji a inne dla deweloperki.
Na poziomie generowania plików webpackiem, wiem czy generuję w trybie
produkcji czy deweloperskim. Jak to połączyć? Czyli w jaki sposób zrobić
przekazywanie parametrów zależnie od trybu pracy webpacka?

W PHP było prosto, miałem dwa pliki konfiguracyjne o tej samej nazwie, ale
różnej zawartości, wiadomo o co chodzi. Tutaj nie wiem jak to ugryźć.

--
pozdrawiam
Roman Tyczka

[Roman Tyczka]

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, klasę, która służy do łączenia do serwera REST, klasa jest
> w osobnym pliku, ale ES6 ma funkcjonalność import więc to nie problem. Ale
> ta klasa w konstruktorze oczekuje obiektu z parametrami połączenia do tego
> serwera i oczywiście inne są te dane dla produkcji a inne dla deweloperki.
> Na poziomie generowania plików webpackiem, wiem czy generuję w trybie
> produkcji czy deweloperskim. Jak to połączyć? Czyli w jaki sposób zrobić
> przekazywanie parametrów zależnie od trybu pracy webpacka?

Trochę mi to zajęło, ale mam rozwiązanie i nawet działa, choć inaczej niż
chciałem:

https://webpack.js.org/plugins/define-plugin/

--
pozdrawiam
Roman Tyczka

[Borys Pogoreło]

Dnia Fri, 11 Jan 2019 11:48:43 +0100, Roman Tyczka napisał(a):

> Trochę mi to zajęło, ale mam rozwiązanie i nawet działa, choć inaczej niż
> chciałem:

Nie kombinuj z różnymi buildami dla testów/produkcji, tylko skorzystaj z
plików konfiguracyjnych lub zmiennych środowiskowych.

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Roman Tyczka]

On Fri, 11 Jan 2019 12:43:05 +0100, Borys Pogoreło wrote:

>> Trochę mi to zajęło, ale mam rozwiązanie i nawet działa, choć inaczej niż
>> chciałem:
>
> Nie kombinuj z różnymi buildami dla testów/produkcji, tylko skorzystaj z
> plików konfiguracyjnych lub zmiennych środowiskowych.

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 steruję
przetwarzaniem plików, czy inaczej to powinienem robić?

--
pozdrawiam
Roman Tyczka

[Borys Pogoreło]

Dnia Fri, 11 Jan 2019 13:13:44 +0100, Roman Tyczka napisał(a):

> ale webpack.config.js mam jedno i w nim sprawdzam "mode" i steruję
> przetwarzaniem plików, czy inaczej to powinienem robić?

To znów nie ma żadnego związku z webpackiem, chyba że konkretnie chcesz
mieć inne pakiety wynikowe na produkcję (np. z wyciętym kodem debug). To
aplikacja powinna wspierać różne konfiguracje zależnie od środowiska.

--
Borys Pogoreło
borys(#)leszno,edu,pl

[Roman Tyczka]

On Fri, 11 Jan 2019 13:34:10 +0100, Borys Pogoreło wrote:

>> ale webpack.config.js mam jedno i w nim sprawdzam "mode" i steruję
>> przetwarzaniem plików, czy inaczej to powinienem robić?
>
> To znów nie ma żadnego związku z webpackiem, chyba że konkretnie chcesz
> mieć inne pakiety wynikowe na produkcję (np. z wyciętym kodem debug). To
> aplikacja powinna wspierać różne konfiguracje zależnie od środowiska.

Ok, to napisz konkretniej jak to powinno wyglądać, bo mi nic te zdawkowe
odpowiedzi nie podpowiadają, a chętnie się dowiem jak to się poprawnie
robi. Póki co mam tak, że mam dwie "kompilacje", jedna produkcyjna, która
jest zminifikowana (bez komentarzy, bez console.log, itd.), a druga
developerska/debugowa, która ma pełny kod i mogę ją testować. Sama
aplikacja JS jest w jednej wersji, poza drobną różnicą z adresami serwera
RESTowego do którego się łączy.

--
pozdrawiam
Roman Tyczka

[Borys Pogoreło]

Dnia Fri, 11 Jan 2019 13:39:32 +0100, Roman Tyczka napisał(a):

> developerska/debugowa, która ma pełny kod i mogę ją testować. Sama
> aplikacja JS jest w jednej wersji, poza drobną różnicą z adresami serwera
> RESTowego do którego się łączy.

Ja polecam przykładowo ten pakiet:
https://www.npmjs.com/package/dotenv
który pozwala łatwo łączyć zmienne środowiskowe z plikiem konfiguracyjnym -
wtedy możesz sobie to poukładać jak tylko Ci wygodniej. A obiekt parametrów
połączenia sobie budujesz z wartości odczytanych z process.env.*

--
Borys Pogoreło
borys(#)leszno,edu,pl

[rePeter]

Fri, 11 Jan 2019 09:19:25 +0100

Roman Tyczka <noe...@because.no> napisał(a):

Wystarczyłby jeden plik konfiguracyjny z warunkiem sprawdzającym czy jest odpalony na
localhoscie czy gdzie tam masz środowisko developerskie. To samo w JS.


--
pozdrawiam, Peter