There are over 160.000 packages on npm today, which makes it the biggest ecosystem out there. Using the right packages in your applications makes JavaScript a joy to develop. But if even immensely popular libraries fail to declare and communicate breaking changes, how can we trust over 50.000 strangers who developed all these modules?
Currently we can’t. Let me show you how you can write confidence-inspiring modules with breaking change detection and fully automated and tested releases including changelogs. Machines do a way better job with this than buggy humans.
Bio
I'm a web developer, who as of recently lives in Berlin, Germany. I try to do things that help other people to build a better web. Be it open-source projects like Hoodie, tooling like semantic-release, as well as talks about these projects or community work and conferences like .concat() and Reject.JS.
Details
The talk is all about dependency hell and how SemVer could help to fix it.
First I'll explain why it doesn't do that already. It's because humans are particularly bad at following the simple rules the spec defines, because they attach additional meaning, emotions and huge expectations to version numbers.
In this talk I want to make people aware of why they should care about SemVer, where common misconceptions are and how to overcome the irrational fear of increasing the major version. This is partly done by automating the process and removing humans from the decision process.
This is not only relevant for current module authors, but really for everyone who develops applications that build upon many, many of those tiny modules on npm for two reasons: First everyone should be able to share their code and I want to reduce barriers for that. Second this is also highly relevant for private modules that are used internally.
The npm ecosystem is a key factor that sets JavaScript development above other languages and environments. With all this growth, not becoming overwhelmed and unable to manage all these dependencies is very important for the speed, sustainability and success of your development process.
Abstract
The talk is all about dependency hell and how SemVer could help to fix it.
First I'll explain why it doesn't do that already. It's because humans are particularly bad at following the simple rules the spec defines, because they attach additional meaning, emotions and huge expectations to version numbers.
In this talk I want to make people aware of why they should care about SemVer, where common misconceptions are and how to overcome the irrational fear of increasing the major version. This is partly done by automating the process and removing humans from the decision process.
This is not only relevant for current module authors, but really for everyone who develops applications that build upon many, many of those tiny modules on npm for two reasons: First everyone should be able to share their code and I want to reduce barriers for that. Second this is also highly relevant for private modules that are used internally.
The npm ecosystem is a key factor that sets JavaScript development above other languages and environments. With all this growth, not becoming overwhelmed and unable to manage all these dependencies is very important for the speed, sustainability and success of your development process.