Folge 26: Backend vs. Frontend

[greelgorke]

über npm:

Also, Holger, ich bin ein wenig verstört, dass du Benes npm rant einfach so stehen lässt 🤣

Man kann in npm, bzw der package.json schon immer feste Versionen vergeben. Das macht man aber nicht, weil wir eben semver haben und machen, und eben es ausnutzen um unkritische patches und minors automatisch reinzuziehen über ~ und ^ ranges. Wir nehmen nicht "irgendeine version" 🙄 . package-lock.json dient dazu reproduzierbare plain-installs zu machen. die Funktionalität des lockfiles ist aber auch nicht neu in npm, sondern mit shrinkwrap auch schon sehr lange gegeben. Was neu ist, ist der Automatismus. Feste versionen sind für stabile deployments gut, für work in progress aber eigentlich ein antipattern. Denn wenn du feste versionen hast, musst du dich bei jeder Abhängigkeit um jeden hotfix selbst kümmern. das kann keiner leisten.

Ja, es halten sich nicht alle an semver, aber die meisten. Ist halt ein tradeoff, denn durch tooling nur unszureichen lösen kannst. Was letztes Jahr allerdings erst noch gefixt wurde ist, dass man versionen force-publishen konnte, was semver eben aushebelte.

über TDD mit React:

Challenge Accepted 🗡

[holgergp]

Hi Gregor,

Danke fürs Feedback!

Ja wenn der Bene einmal in Fahrt ist, ist er kaum zu stoppen. Er hatte schon Schaum vorm Mund und ich Angst um mein Leben :) Ich gebe euch aber beiden Recht. Wenn man mit der Maven-Brille auf npm schaut wirkt es immer noch ein wenig frickelig. Die Möglichkeit jetzt 'nativ' Versionen festzuzurren ohne noch einen weiteres Tool zu verwenden finde ich auch schon angenehm. Warum siehst du feste Versionen für WiP generell als Anti-Pattern. Klingt für mich auch erstmal nach erhöhtem Testaufwand. Hast du da nen Link parat? :)

LG

[greelgorke]

Die Möglichkeit "nativ" versionen festzuzurren gab es von nahezu tag 1 bei npm :D schreib die version manuell komplett und exakt ins package.json hin. das machste in maven nicht anders, richtig? auch shrinkwrap ist ein npm feature https://docs.npmjs.com/cli/shrinkwrap

Das mit WiP kannst du mit git vergleichen. deine node_dependencies sind der master branch, dein code ist featurebranch. wenn du zu lange den master nicht mergest, ist der Schmerz viel größer. wenn du aber regelmässig mergest vermeidest oftmals kleine konflikte ganz und größere konflikte fallen früher auf und tun weniger weh. Das selbe gilt eben für dependencies. Es ist auch nicht mehr Testaufwand, wenn du deine Testpyramide ernst nimmst. dazu noch tools wie npm outdated oder greenkeeper.io und das wars. Wie viele systeme laufen mit veralteten versionen, weil der schmerz zu updaten zu groß geworden ist? Wieviele Systeme laufen mit verwundbarem Code, weil kein Mensch die minor Patches und Fixes im Auge hat und die Versionen gepinnt sind?

Oder hast du die Auto-Update Features in deinem Browser und OS auch ausgeschaltet? ;)

[dzenzes]

Vielleicht hängt auch dieser Blickwinkel damit zusammen, dass ihr die pom Dependencies oft selber schreibt und dann eine feste Version nehmt oder halt sowas wie Spring Boot im Einsatz habt wo es ja einer der Vorteile ist, dass alle Dependencies gleich mitkommen.

Kann @greelgorke hier nur zustimmen: npm kann das alles schon sehr lange und es spricht ja auch nichts dagegen dynamische Versionen einzusetzen. Es gibt ja auch in Maven Version ranges und ich kenne auch Entwickler, die damit arbeiten.

Es gibt sicher nicht nur im JS Umfeld Bibliotheken, die "semver nicht können" und hier hast Du als Entwickler alle Freiheiten Deine package.json anzupassen.

Vielleicht spielt hier auch eine Rolle, dass das JS Ökosystem sehr jung und enorm aktiv ist. Sehr viele neue Entwicklungen (auch in der Sprache) erscheinen und werden schnell von Entwicklern gefordert. Natürlich klappt dann nicht alles perfekt aber es dauert halt auch nicht Ewigkeiten, bis sich etwas entwickelt (jigsaw anyone).