@sens:
U nas wszystko było w devDependencies, i chciałem zoptymalizować build w chmurce i zrobić podział na deps do buildu. I wywaliłem paczki yarn build i jak wywaliło, że brakuje x to sobie napisałem skrypcik yarn dep-to-prod który robił remove z devDependecies i instalował w normalnych. :3

Cały dzień żeby zejść ze średnią 7m 58s na 7m 0s. xD

Ale zadowolon z komendy jestem:
https://i.imgur.com/hreBu0p.png
https://i.imgur.com/Wn2TKZr.png

@Deykun: pięknie :3

Pokaż ukrytą treść tylko czemu po polsku XD

@sens:
Jak robiłem zrzuty to też mi było trochę wstyd, ale niektóre komendy tak mamy, niektore promty to jeszcze smieszkują, że "to co wystawiamy?".

@sens: nie ma to jak Deno: żadnych package.json czy tam package-lock.json, same importy i jest git

@duxet: serio tak prosto, czy jest jakiś haczyk? Jak to się ma do wersjonowania paczek?

@sens: Serio, Deno samo przy starcie zaciąga i keszuje zależności (podobnie jak Go). Pierwotnie moduły można było importować tylko przez HTTP, ale kilka miesięcy temu dodali wsparcie dla npma.

tak więc teraz działa np. import express from "npm:express@^4.17";

@duxet:
Nie no wiadomo, że deno później i ma jakieś fajne rozwiązania, ale jak używasz expressa w wielu plikach i będziesz miał import express from "npm:express@^4.17"; to ostatecznie możesz skończyć z różnymi wersjami jak gdzieś ci zostanie stary import. Brzmi gównianie. Więc to nie tylko zalety.

@duxet:

nie ma to jak Deno: żadnych package.json czy tam package-lock.json, same importy i jest git

O jeszcze tutaj się przywalę. Albo deno w repo trzyma ten szajs - a pewnie tego nie robi, albo jak padnie import po urlu a nie taki npmowy to jesteś w 100% w piździe jeśli ktoś nie ma tych rzeczy w lokalnym keszu, bo nawet nie wiesz z jakiej wersji korzystało, ten problem rozwiązuje package-lock.json, przecież te pliki nie istnieją dla jaj tylko mają oczywiste uzasadnienie. dx

@Deykun: Rozwiązanie problemu z różnymi wersjami jest proste: można w jednym pliku trzymać wszystkie zewnętrzne importy i eksportować je dalej.

Import z npma tak samo może w każdej chwili przestać działać, tak jak to było np. w przypadku słynnego leftpada :D Dlatego na takie sytuacje dodali ostatnio też komendę do eksportu wszystkich wykorzystywanych zewnętrznych modułów oraz opcjonalny deno.lock.

@duxet:

można w jednym pliku trzymać wszystkie zewnętrzne importy i eksportować je dalej.

Well, that just sounds like package.json with extra steps. dx

Import z npma tak samo może w każdej chwili przestać działać, tak jak to było np. w przypadku słynnego leftpada :D

Tak i jak przestał działać to miałeś informację, że twój projekt korzystał z leftpad w wersji 2000.4 nawet nie bezpośrednio tylko w zależnościach i szukasz co się stało z leftpad 2000.4 albo czy twoje zależności już mają plan co z nim zrobić. A jak import HTTP pada w deno to szukasz dlaczego stronka o URL padła. I ten leftpad zaraz miał setki wątków, bo popularny, ale jak paczka miała 200 instalacji dziennie, to node zwraca to samo info, że padła wersja x z repo y i to łatwiej googlać niż url strony.

Dlatego na takie sytuacje dodali ostatnio też komendę do eksportu wszystkich wykorzystywanych zewnętrznych modułów oraz opcjonalny deno.lock.

Znaczy ja nie jestem wrogiem deno, ale masz mi tu przyznać, że to co piszesz to wcale nie jest "same importy i jest git". >:-(

xD

Też się zastanawiam jak deno jest w chmurze i ten mój przykład do góry by był na importach HTTP to by pewnie nie było odpowiednika yarn install bo może brać z HTTP i to usuwa mój i sensowy problem. Ale jak jest lag na połączeniu HTTP w jednej zależności to słabo, więc odpowiednik deno install który pobiera musi mieć listę co pobrać a czego nie, bo nie będzie używane.

U mnie na dockerach jest docker który instaluje paczki i jak sa takie same to ta warstwa może być użyta do kolejnego buildu oszczędzając instalacje, jak deno to determinuje w locie to trudniej to stwierdzić czy paczki w apce są takie same, czy na tyle inne, że bardziej się opłaca tego dockera wywalić do kosza niż reużywać.

Nie wiem jak @duxet jesteś w JS, ale u w JS zależności to wielkie wielkie gówno💩, jakbym pisał w C# czy w czymś to bym się tak nie bał ich jak w js który domyślnie jest nietypowany, więc jak używasz zewnętrznej libki to ci czasami nie powie, że dajesz stringa tam gdzie oczekuje obiektu.

@Deykun: W porównaniu do package.json jest o tyle lepiej, że łatwiej można śledzić wykorzystanie zależności w IDE, importować tylko wybrane elementy zamiast całej paczki czy też po prostu dzielić projekt na "submoduły".

A jak import HTTP pada w deno to szukasz dlaczego stronka o URL padła.

Takie są minusy decentralizacji, niestety :D

Ta elastyczność imho najbardziej przydaje się w przypadku korzystania z Deno do tworzenia skryptów. Jak projekt jest większy to można utworzyć sobie bardziej skomplikowaną i "dojrzałą" strukturę, a w przypadku prostych skryptów całość projektu może składać się tylko i wyłącznie z jednego pliku (który można później udostępnić chociażby jako zwykły gist).