Revision 412: Veroffentlichung von JS-Libraries

Published: Feb. 11, 2020, 7 a.m.

Hans und Peter hatten diesmal das Vergn\xfcgen, sich mit dem langj\xe4hrigen\nPodcast-H\xf6rer Tobias Barth (freischaffender Frontend- und gelegentlicher\nNode-Entwickler, zu finden in Web, Twitter und auf Dev.to) \xfcber die Prozesse und\nTools rund um die Ver\xf6ffentlichung von JavaScript-Paketen austauschen zu d\xfcrfen.\n\n\nUNSER SPONSOR\n\n\n\nHier kannst du mehr \xfcber IONOS erfahren.\n\n\nSCHAUNOTIZEN\n\n[00:02:45] VER\xd6FFENTLICHUNG VON LIBRARIES\n\nDie Perspektiven eines kleinen Startups (Peter und Hans mit Warhol.io) und\nTobias (MediaMarkt/Saturn) bzgl. Library-Entwicklung und -Ver\xf6ffentlichung\nprallen aufeinander! Neben offensichtlichen Fragen wie Dependencies vs.\nSelbstschreiben (vgl. Revision 397 zu Preact) geht auch um das Handwerk des\nNPM-Paket-Ver\xf6ffentlichens mit Semver (bevorzugt mit automatischen\nVersionsnummern via standard-version und/oder semantic-release) und dem\npublish-Kommando. Die kniffligen Entscheidungen im Library-Build-Prozess nehmen\nbesonderes Gewicht ein: wie genau passen TypeScript, Babel, Rollup (vgl.\nRevision 405), Webpack und \xe4hnliche Tools in den Prozess? Was bewirken die\nFelder main, browser, module und types in der package.json? Am Ende d\xfcrfen\nVerweise auf ein paar Alltags-Helfer nicht fehlen, allen voran das Link-Kommendo\n(gibt es f\xfcr NPM wie auch f\xfcr yarn), die Peer Dependencies, das Dedupe-Kommando\nund allgemeine Tools wie Prettier, ESLint, Travis, Circle CI, Greenkeeper und\nDependabot.