Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependency Hell Just Froze Over #69

Open
boennemann opened this issue Jun 29, 2015 · 0 comments
Open

Dependency Hell Just Froze Over #69

boennemann opened this issue Jun 29, 2015 · 0 comments

Comments

@boennemann
Copy link

Abstract

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant