@Barcol jak myslisz, goscie od node.js nie ogarniaja czy moze jakis randomowy ziomek co prowadzi bloga jest w bledzie? Gosc prowadzi bloga i promuje sie tutaj. I niby spoko, ale jak sam pisze kodowanie profesjonalne zaczal w polowie 2018. Ja nie mialbym tyle odwagi zeby po tak krotkim czasie kreowac sie na eksperta.

.env jest spoko, to jest standard w js, koncepcja jest zrozumiala dla kazdego. Wystarczy tego nie wkomitowac na git'a i jest ok.

@666 Pięknie przedstawione pytanie: 3 tysiącę technicznych kontrybutorów, czy jeden random. Tylko że na community nodejs nie składa się jeden sam autor bloga, tylko rzesza ludzi o wiele większa niż gromada jego twórców, i w której to grupie ogrom jest osób, które jak sam zauważyłeś, są pewnie w błędzie. A to właśnie oni ustalają trend, jako grupa. Oni podejmują wybory, które w perspektywie czasu doprowadzają do upadku lub rozrostu danych rozwiązań. Humorystyczna wstawka jaką umieściłem z capslockiem ma za zadanie podkreślić, że akurat w świecie JSa (pewnie przez jego popularność) takie dziwne uciekanie od przestarzałych (czyli starszych niż rok) rozwiązań, na rzecz tych z zeszłęgo tygodnia/miesiąca, jest standardem. IMO doskonale oddaje to satyryczny artykuł (prehistoryczny, ma 7 lat i dwa tygodnie) dostępny tutaj: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

Żeby nie było że gadam bzdury bez poparcia: Jest taki nowy framework JSowy o nazwie Bun. W zasadzie to runtime, menadżer paczek, i wiele innych w jednym. Bun w pierwszej stabilnej wersji ma dopiero miesiąc. Już od paru osób słyszałem, że koniecznie muszą przepisać na niego swój projekt xD A dodatkowo już zdążył trafić np. do Railsów w wersji 7.1 XD

Co do konkluzji to sam używam chętnie dotenva i nie mam zamiaru go porzucać, natomiast nie mogę odmówić autorowi posta, że faktycznie dobrze jest go nie commitować xD A niewspierane paczki z lukami bezpieczeństwa - porzucać.

@666 po ilu latach programowania odbiera się licencję eksperta?

@elszczepano nie obrazaj sie. Pisze o swoim punkcie widzenia. Moj jest po prostu inny. Co do ilości lat kodowania to niestety doswiadczenie mi mowi ze ekspertami sa ludzie kt siedza w temacie 8, 10 i wiecej lat. Dodatkowo większość z nas nie bd nigdy ekspertem tylko zwyklym klepaczem kodu - za takiego sie uwazam.

Co do samego tematu: artykuł kt podlinkowales trigeruje mnie. Bait'owy tytul a la yutuberowi znawcy od wszystkiego. .env bd żył jeszcze długo i nic tego nie zmieni, dziala dobrze. Ma wiele zalet: battle tested i praktycznie nie trzeba tego utrzymywać ani poświęcać czasu. Programisci zapominaja ze kod ma zarabiac na siebie, a nie dawac radosc z testowania na prodzie nowosci.

@666 spokojnie, nie obrażam

Nie staram się pozować na eksperta, raczej na kolesia, który lub dzielić się zdobytą wiedzą. Opublikowana notka była czymś na zasadzie luźnej rozkminy i przemyślenia którą kiedyś sobie zapisałem gdzieś na boku. Możliwe, że troche zbyt baitowa forma, ale shit happens

Z .env sam korzystam, ale uważam że są lepsze rozwiązania ale to już raczej temat na wpis na bloga (z mniej baitowym tytułem ;)).

Z zaletami się zgadzam, ale co do zarabiania kodu na siebie to mój główny problem z dotenv jest taki, że IMO skończy tj. lodash, który ostatni release na npm miał w 2021 roku. Wtedy wystarczy, że ktoś znajdzie w nim jakiś poważny vuln i robi się problem.

@elszczepano a jaka alternatywa dla `.env` ? Bo nie wiem, czy wiesz, ale jest `.gitignore` i `.dockerignore`, dzięki którym nikt przypadkowo nie wcommituje/nie doda pliku do git/docker.

`.env` rozwiązuje problem różnych konfiguracji lokalnych dla różnych developerów. Każdy z nich ma inny system operacyjny, różne porty, różne hasła, różną konfigurację. Jeden lubi naleśniki, drugi jak mu nogi śmierdzą. Skoro nawet twórcy node to dostrzegają i dodają natywne wsparcie, to czemu z tego nie korzystać? Podaj alternatywę.