So, yeah. Thank you for the kind introduction, so that everyone knows who I am now. We can get right
to the dependency hell. So today's talk is about
dependencies and their relationships, dependency is a state
in which one object uses the function of another object
around in the JavaScript world we have a pretty good
tool, and a pretty great infrastructure to make that functionality
available and consumerable. So dependency relations
brings a lot of good, but sometimes we're really mad
about them, hence the term dependency hell. Let me
start with a little story. About two years ago, when
I started my university course, I was looking for people
who had already done some projects or cool stuff. So
I was looking around and there was a person who had
already done no project, so obviously we became friends,
but I soon found out that it wasn't their only
technology, like it was my technology, I'd done
a project, he'd done C++ hardware and he was a better
computer scientist than I was at the time, and I am now,
but when we started hacking together it always felt like
it was more productive somehow, and we showed each other
some code, and started hacking. And so I read through
his modules and code and then I found one line where
there was a lot of code that was handled, and it was
requiring these modules. So I said: "Why are you using
that code?" And at that time it was the most depended
upon and downloaded package, and he said "What is A
sync? I have no idea what that is." I wrote this
module myself. And so I said: "Okay, now I know why it
feels like I'm more productive than you." And so this
is the only thing to this day I could probably ever
teach to him, that's use the NPM search, or better yet
NPM search, or their web search. And that made them
a productive developer, not only excellent but
productive. And once we realised that he can just do
NPM search, and then there's a package, and then you
just plug them together, the productivity just exploded.
It got to the point where I had to be careful what I was
saying because the next morning he had just done it. So
we were living in this university home back at the time,
and there was this very, very shitty Internet where you
had to put in every few hours, so I said: "This is so
annoying, you should have one that fills in the
credentials", and the next morning he was: "Yeah, yeah
I automated that so it sets the address, which forces
the form to come up, and then I automated the form so we
have this little raspberry, you put it in here, plug it
in", and the Internet was awesome, and that's just great
and that was because he had installed the thing plus the
knowledge he already had. So that's pretty cool. But
now comes the part that is even more important for me,
and for us as a community if we want to be welcoming,
and enable more people to do stuff. So this was just
the beginning of my university course, and obviously
I am a beginner programmer, and since there were other
persons who had already done some websites, already sold
some websites, but it is pretty much been copy and paste
stuff, pretty horrible, but that's how we all start out.
I mean it is horrible in the technical sense, but it is
pretty cool that we actually did some things, and then
the university courses came in and were like teaching
the basics of programming and then doing it the real
way, and then he was really frustrated, because all he
wanted to do was build websites, do things, and that
didn't help at all. So here is the thing I told him:
use NPM search. And obviously it wasn't that easy
because he didn't even know what NPM is, but once I got
it explained, I said to him: "Listen, for everything you
want to do there's someone out there who has already
done it, and you only need to rearrange things in new
ways and be creative." So NPM search made him a productive developer,
and some people, especially at university, think
you can only teach things by making people deeply
understand the basics and the core principles of stuff, but
I think you can just stop boring people and give them
tools so they can start creating, and then they will keep
creating, and sooner or later they will understand,
and then it goes on and on and never stops. So this person
built their first node thing, and it was talking
to Twitter and Facebook, just three months later, and
obviously he didn't understand anything of OF, but no one
does, but he just started with a little guidance, and
just three months later he was a productive developer.
This is what is enabled by NPM. They have really great
tools and a registry that's available for everyone.
They're hosting it for us, making it accessible, and
they have an incredible team of humans working on that.
I couldn't be more happy about this, because it is
enabling everything, so that's pretty cool, but the
infrastructure isn't everything. We have this cool
little thing: our community. And so this is what our
community achieved. So who here has ever published a module? Can you raise you hands? That's
quite a few people. That's pretty cool. There are no exact
numbers but they're about 50,000 or more than 50,000
individual people who published modules, and it is just
incredible to observe this, to see people coding in the
open talking about stuff, and it is just inspiring
and makes everyone so productive. What we have is 180
thousand modules, and everywhere you can run JavaScript,
in your TV, we can use these modules. So everything
is pretty awesome, right? The thing is, we don't just
need productive developers, in the long-term, if
we want to shift serious products that also pay the bill
for all this, we need to be able to work in teams.
And of course we need flexibility and productivity,
but we also need stability and maintainability. That's
the part where the more serious developers come in
and say small modules are nice in theory, but it doesn't
work, stuff keeps breaking all the time, there's just
so much overheads. So we came up with a term that
is so privileged it could probably only come into
existence in the tech community, because we call it "dependency
hell". The worst possible place we could be in.
Because code that other people wrote for us stops
working. Imagine you're a small kid, and instead of
asking your parents for this one certain piece of
Lego, you just have every single Lego piece available
to you, it doesn't matter what colour, size, how many
of them, you can just build anything you want. This is
how I see the NPM registry. And imagine your house collapses
or whatever you have built, and it no longer
works the way you want. What would you do as a small kid?
You would probably start crying because your beautiful
house just collapsed. And that's what we do. Small modules
suck, NPM sucks, semantic versioning sucks, everything
sucks. We need to grow up because this room would
be pretty empty without all the modules. I'm serious.
This is a huge part of the success of JavaScript,
that we can make functionality for others without infringing.
So we have to realise this. We might be getting
functionality for free, but we have to write tests for it
ourselves. There is one exception. We only use modules
by John David Dalston, which is a joke because there
is no exception. It's quite the opposite, even if
we only use modules by John David Dalston which are well
tested, we still have to write our own tests because
that's the only way to prove our code is working. Actually
the test defines what our software is, and if
we don't have that and just have something, and even though
if you're relying on well tested modules for all the
implementation bit, that's not software, it is only
a hack. I don't want to exclude myself here, I'm using
hacks all the time. But the thing is we need to be
aware of it and stop laying the blame on others. There's one thing about dependency hell that's
accurate. Hell is a place where you get punished for
self-inflicted sins. It is not the others. It is you.
You have to write tests for your stuff. So we have to
embrace that modules are everything. They make us
productive, they are the reason why we're here, they're
the reason why JavaScript is so successful, because we
can share and be open about the stuff we're working on,
and we have to accept that we have to test our stuff.
That's the deal. Others may write the implementation bits, but we have to write the tests because
that's the definition of what we're writing. So that's
the key to maintainable software.
So over the course of the last year I started writing a tool, or a rather a test thing,
because that's what I did all the time. So it's stable. And
it helps take all this to automater and fire publishing
process. Trust me, this will change your work for the
better. I agree it is a great rule, but the thing
is it is only for package authors, and you saw earlier some
people raised their hands when I asked if there is
some package authors here, but I realised if you want to
make change in the entire eco standard, if you want to
enable more people to share their stuff and build code
I have to provide something for the users of the package,
and every author is a user of the package, as
well. And so, I listened to my friend Stephan and
I stick to these three rules: humans shoot humans,
computers shoot computers, and computers only exist
to make better humans ...
I want to show you something entirely new I was
working on with a bunch of friends. No one saw it
before, and I'm going to do a live demo, so let's see
what happens. So the thing that makes dependency hell
so annoying is that you have to keep track of the
changes in your dependencies and new versions, you can
either pin them all the time and then you're vulnerable
to random fails in your stuff, so you're constantly managing your dependencies. So the idea is
that -- so I have this demo repository, it doesn't have
any code but it has some dependencies to show this
to you. So I built this tool, it is called Link Keeper.
Obviously this had to happen because I have to sync
first. I'm sorry. I have a lot of packages, so that excuses
it maybe. Awesome. So this repository is enabled
now, and this means there's a computer computering
in the background to manage all the dependencies
for us. Of course. Of course
it just had to happen, obviously, and I'm very sorry. I swear it worked when I was
sitting in the front of the stage. I'll just explain
the concept and then you can see if you like it. So I
have these dependencies and they're all using versions
where I say use this version, and everything that's a
new patch or a minor version, and so when I enabled the
repository, I automatically get a request that pins down
all my dependencies to the highest version that is
currently satisfying in the range, and then I put a
request in and then I have pinned down dependencies, what
has happened then is whenever dependency changes, get another
pull request in time, and nothing changes in time
but the version, and then the pull request comes in,
and then you probably have some CI service configured
and it automatically runs the tests, the tests, depending
on the dependency change in isolation, and you
can merge right away with the click of one button. And
if it doesn't, you know exactly which version caused
the problem and you have a branch ready sitting
there, and you just check it out and keep working on
it and you can just merge it in as well. So the idea is that
we're going to make this available for every public
repository on Twitter so that everyone can have pinned
down dependencies, everyone can have control over
what version they're using, but at the same time,
it's always up to date. So this isn't quite as impressive
without the demo, but it's available today, and you
can get this via NPM, obviously, it's NPM install-G greenkeeper
and please sign up and share it. As I said, we
want to make this available for all public repositories
so that at some point this is running on every single
NPM dependency and therefore the entire NPM eco
system doesn't make us as productive, it is also
maintainable. Thank you. [applause]. And maybe you should
wait ten more minutes and then we have this thing fixed
and then it works, I promise it's working. Thank you.