/
Published on 13.01.2025
TLDR: pnpm 10 wprowadza przełomowe zmiany w bezpieczeństwie - domyślnie blokuje lifecycle scripts, przechodzi na SHA256 i zmienia sposób linkowania pakietów. To major release który może złamać istniejące buildy.
Ludzie, mamy tu prawdziwą rewolucję w świecie package managerów. pnpm właśnie wypuścił wersję 10 i nie żartują sobie - to jest major release który może totalnie zepsuć wam dzień, ale z bardzo dobrych powodów.
Największa zmiana? Lifecycle scripts dependencies nie są już wykonywane domyślnie podczas instalacji. To znaczy, że jeśli jakiś pakiet miał postinstall script, który kompilował natywne moduły czy robił inne rzeczy, to teraz się nie wykona. Trzeba go explicit dodać do onlyBuiltDependencies w package.json. I słuchajcie, to jest fantastyczna decyzja! Supply chain attacks to plaga naszych czasów - ile razy widzieliście pakiety które w postinstall ściągają jakieś podejrzane rzeczy z internetu?
Druga duża zmiana to przejście na SHA256 we wszystkich algorytmach hashujących. MD5 wreszcie idzie do kosza, długie ścieżki w node_modules/.pnpm są teraz hashowane bezpieczniej, checksumы w lockfile też. To może wyglądać jak techniczna drobnostka, ale w rzeczywistości to ogromny krok naprzód w bezpieczeństwie całego ekosystemu.
Zmienił się też sposób działania pnpm link. Teraz dodaje overrides do root package.json, co centralizuje zarządzanie dependencies w workspace. To brzmi jak mała zmiana, ale dla zespołów pracujących z monorepo to może być game changer - wreszcie jeden punkt prawdy dla linked dependencies.
Co mnie martwi w tym wszystkim? Autorzy pnpm nie mówią wprost o tym, jak bardzo może to zepsuć istniejące CI/CD pipelines. Jeśli macie projekty które polegają na lifecycle scripts - a prawdopodobnie macie - to upgrade do v10 może was totalnie zablokować. Nie ma tu soft migration path, to jest twardy cut-off.
Link: pnpm 10 Release Notes
TLDR: React wprowadza eksperymentalne <ViewTransition /> API oparte na browser View Transition API. To pierwsza oficjalna próba rozwiązania 12-letniego problemu braku natywnych animacji w React.
No i stało się - po 12 latach React wreszcie dostaje swoje pierwsze oficjalne API do animacji. <ViewTransition /> component jest już dostępny w pre-release channels i bazuje na browser View Transition API. To jest moment historyczny, ludzie!
View Transition API to potężna technologia która pozwala animować między dowolnymi dwoma view. Możecie animować rzeczy które wcześniej były nie do animowania - jak zmiana justify-content z flex-start na flex-end, albo płynne przejście między kompletnie różnymi elementami jakby to był jeden element. To brzmi jak magia, ale to jest prawdziwa technologia.
Problem w tym, że browser View Transition API ma swoje wady. Animacje są uninterruptible - jak je przerwiesz, to się wizualnie psują. CSS pseudo-element API jest okropne w użyciu. Każdy element potrzebuje unikalnego view-transition-name, co jest nightmare do zarządzania w komponowanej architekturze.
React team próbuje rozwiązać te problemy, ale tu jest haczyk - integracja z React jest fundamentalnie trudna. View transitions są inherently asynchronous, a to oznacza że musisz startować transition przed setState i owijać state update w flushSync. To jest performance killer - flushSync to nuclear option który blokuje cały React.
Co mnie niepokoi w tym podejściu? React team znowu idzie w kierunku "jeszcze więcej magii". Zamiast dać developerom proste, composable primitives, dają kolejny high-level API który ukrywa complexity. A co się stanie jak będziecie chcieli zrobić coś co nie mieści się w ich vision? Tough luck.
Dla architektów i zespołów - to może być interesujące jako sposób na ujednolicenie animacji w aplikacji, ale nie spodziewajcie się że to będzie silver bullet. Nadal będziecie potrzebować external libraries dla bardziej zaawansowanych przypadków.
Link: React's Experimental View Transition API
TLDR: Time to First Byte to kluczowa metryka dla server-side rendered aplikacji. Sentry's Trace View pozwala zidentyfikować bottlenecki na serwerze które Chrome DevTools nie pokaże.
TTFB, czyli Time to First Byte, to metryka która staje się coraz bardziej krytyczna w erze server-side renderingu. I mamy tu paradoks - SSR jest lepsze dla SEO i performance na słabych urządzeniach, ale jednocześnie zwiększa TTFB bo browser musi czekać aż serwer wyrenderuje stronę.
Problem w tym, że standardowe narzędzia jak Chrome DevTools czy WebPageTest pokażą wam tylko że browser czekał 2 sekundy na odpowiedź serwera, ale nie powiedzą dlaczego. To jest jak patrzeć na czarną skrzynkę - widzicie symptom, ale nie przyczynę.
Tu wchodzi distributed tracing. To nie jest nowa technologia, ale w kontekście web developmentu jest niedoceniana. Tracing tworzy "spans" - najmniejsze jednostki pracy - które są linkowane między sobą i mają start time oraz end time. Wszystkie spans należą do jednego "trace", co daje wam kompletny timeline tego co się dzieje.
Sentry integruje się bezpośrednio z Next.js i automatycznie tworzy większość spans których potrzebujecie. Możecie też mieć distributed traces - zacząć na kliencie, kontynuować na serwerze, wszystko w jednym timeline.
Ale tutaj jest rzecz której autorzy nie mówią wprost - tracing to nie jest free lunch. Każdy span to overhead, każde measurement to dodatkowa latencja. W production musicie być bardzo ostrożni z tym ile tracingów włączacie, bo możecie paradoksalnie spowolnić aplikację próbując ją zmierzyć.
Dla zespołów to może być game changer, ale potrzebujecie strategy. Nie włączajcie tracingu na wszystkim od razu. Zaczynajcie od critical paths, od endpoints które wiecie że są wolne. I pamiętajcie - tracing to diagnostic tool, nie monitoring tool. Nie zostawiajcie go włączonego na 100% traffic w production.
Link: How to reduce TTFB
TLDR: Wiele production-ready projektów jak UnoCSS czy React Native używa v0.x.x versioning. To nie oznacza że są niestabilne - to strategiczna decyzja o flexibility w API changes.
Anthony Fu porusza temat który jest solą w oku wielu developerów - dlaczego tak wiele projektów trzyma się v0.x.x versioning mimo że są production-ready? UnoCSS v0.65.3, Slidev v0.50.0, React Native v0.76.5 - wszystkie to stabilne, używane przez miliony projektów narzędzia.
Semantic Versioning to kontrakt między maintainerami a userami. MAJOR.MINOR.PATCH - każda cyfra niesie znaczenie. Ale tu jest problem - w prawdziwym świecie ten kontrakt jest często niemożliwy do utrzymania. Każda zmiana może wprowadzić breaking changes, nawet jeśli nie było to zamierzone.
v0.x.x daje maintainerom flexibility. Mogą wprowadzać API changes bez guilt trippu związanego z bumping major version. To szczególnie ważne dla bibliotek które są jeszcze w fazie rapid development, gdzie API nie jest jeszcze fully crystallized.
Ale jest tu druga strona medalu której Anthony nie porusza wystarczająco. v0.x.x versioning to signal dla enterprise customers że projekt może nie być ready for mission-critical usage. Procurement teams często mają policies przeciwko używaniu "pre-1.0" software. To może być unfair, ale to jest reality.
Dla architektów i zespołów - nie bójcie się v0.x.x dependencies jeśli są well-maintained i mają good adoption. Ale mějcie plan B i budżet na potential API changes. I jeśli sami maintainujecie biblioteki - przemyślcie czy korzyści z flexibility przeważają nad costs w perception i adoption.
Link: Epoch Semantic Versioning
TLDR: Akademicka praca analizuje integrację Micro Frontend Architecture z React Server Components w enterprise aplikacjach. Module Federation i gradual adoption jako klucz do sukcesu.
Mamy tu akademicką pracę z Politecnico di Torino która analizuje integrację Micro Frontend Architecture z React Server Components. To nie jest kolejny blog post, ale poważne research które może mieć implications dla enterprise development.
Kluczowym elementem jest Module Federation - technologia która pozwala na seamless integration między różnymi micro-frontendami. Do implementacji potrzebujecie Vite.js lub Webpack, które dostarczają infrastructure do module sharing i dynamic loading.
Interesujące jest podejście do gradual adoption. Zamiast rewrite całej aplikacji, możecie modularyzować po kawałku, wprowadzając server rendering practices bez complete overhaul. To jest pragmatic approach który redukuje risk i challenges.
Ale tutaj jest rzecz której praca nie adresuje wystarczająco - operational complexity. Micro frontends to nie jest tylko technical decision, to jest organizational decision. Potrzebujecie teams które mogą independently deploy i maintain swoje pieces. Potrzebujecie monitoring, logging, error handling które działa across boundaries.
Server Components dodają kolejną layer complexity. Bez native framework support (Next.js, Remix.run, Modern.js) jesteście sami sobie sterem, żeglarzem i okrętem. To może być technical debt waiting to happen.
Dla enterprise teams - to może być interesting direction, ale nie podejmujcie tej decyzji lightly. Micro frontends solve organizational problems kosztem technical complexity. Jeśli nie macie organizational problems, to prawdopodobnie nie potrzebujecie micro frontends.
Link: Micro Frontends and Server Components Research
Disclaimer: This article was generated using newsletter-ai powered by claude-sonnet-4-20250514 LLM. While we strive for accuracy, please verify critical information independently.