So it begins, a że jestem porządnym człowiekiem i lubię porządne tabelki, wykresy i takie tam (buziaczki dla @Deykun-a) to robię tabelki. Przed państwem proces wyboru:
https://i.imgur.com/0BiJQFv.png
So it begins, a że jestem porządnym człowiekiem i lubię porządne tabelki, wykresy i takie tam (buziaczki dla @Deykun-a) to robię tabelki. Przed państwem proces wyboru:
https://i.imgur.com/0BiJQFv.png
30 minut debaty na ten temat, ale mi się nie podobało za specjalnie:
https://www.youtube.com/watch?v=c1lBl-WKcCM
@Deykun jest mistrzem zbierania danych o sobie, ale go gonię
https://i.imgur.com/Q5U4s5F.png
Założyłem sobie czujnik natężenia światła w salonie.
Na wykresie widać, że wstawałem w nocy na szluga pięć razy po zgaszeniu światła, a moja dziewczyna wstała ok. godz. 7 i zapaliła światło, a potem więcej światła, a potem wyszła z domu, a potem wstałem ja.
To pomarańczowe to termopara, ale jeszcze nie rozkminiłem przelicznika rezystancji na temperaturę, a nie mam na to czasu teraz w zasadzie.
Właśnie czyszczę package.json bo jakaś typiara dwa lata temu dodała jakieś gówno z templatkami które zaciągnęło cirka ebaut 20 paczek z npma które nie są nigdzie wykorzystywane w projekcie. Czuję się jak saper kurwa
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.
Właśnie czyszczę package.json bo jakaś typiara dwa lata temu dodała jakieś gówno z templatkami które zaciągnęło cirka ebaut 20 paczek z npma które nie są nigdzie wykorzystywane w projekcie. Czuję się jak saper kurwa
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
Właśnie czyszczę package.json bo jakaś typiara dwa lata temu dodała jakieś gówno z templatkami które zaciągnęło cirka ebaut 20 paczek z npma które nie są nigdzie wykorzystywane w projekcie. Czuję się jak saper kurwa
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
Właśnie czyszczę package.json bo jakaś typiara dwa lata temu dodała jakieś gówno z templatkami które zaciągnęło cirka ebaut 20 paczek z npma które nie są nigdzie wykorzystywane w projekcie. Czuję się jak saper kurwa
@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.
Właśnie czyszczę package.json bo jakaś typiara dwa lata temu dodała jakieś gówno z templatkami które zaciągnęło cirka ebaut 20 paczek z npma które nie są nigdzie wykorzystywane w projekcie. Czuję się jak saper kurwa
@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?".
Właśnie czyszczę package.json bo jakaś typiara dwa lata temu dodała jakieś gówno z templatkami które zaciągnęło cirka ebaut 20 paczek z npma które nie są nigdzie wykorzystywane w projekcie. Czuję się jak saper kurwa
@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
