►
From YouTube: npmCamp 2016 - Greenkeeper – managing dependencies with confidence by Stephan Bonnemann
Description
Greenkeeper – managing dependencies with confidence by Stephan Bonnemann
A
So
this
talk
is
about
greenkeeper
and
managing
dependencies
and
what
is
great
keeper,
and
what
does
managing
dependencies
even
me,
so
Greinke
/
aims
to
be
a
nice,
but
to
sheriff
us
humans
and
Laurie
put
it
in
one
of
his
recent
talks.
Put
like
this
green
keeper
is
NPM
outdated
as
a
service
or,
as
we
put
it
on
our
website.
It's
always
up
to
date
depend
always
up
to
date,
npm
dependencies,
sorry
n0
hassle,
and
this
sounds
all
nice
and
fancy.
But
I
figured
this
isn't
a
sales
show.
A
This
is
a
community
conference,
and
in
this
room
there
are
150
people
who
deeply
care
about
NPM,
and
so
I
want
to
put
the
situation
to
really
good
use.
So,
instead
of
trying
to
get
you
to
buy
greenkeeper
I'm
trying
to
make
you
to
deeply
understand
greenkeeper
and
the
role
it
wants
to
play
in
this
ecosystem,
we
are
all
contributing
to
so
hi.
A
My
name
is
Jeff
on,
as
raquel
already
told
you,
and
I
had
the
idea
to
build
greenkeeper
and
I
did
that
with
a
few
friends,
and
usually
when
we
like
introduce
ourselves,
we
just
list
a
few
projects.
We've
worked
on
here
and
there,
but
I
figured
that
the
things
I've
been
working
on
logically
leads
to
green
key
burn,
so
instead
I'll
just
tell
you
a
little
about
them.
A
So
back
when
I
started
programming,
all
I
really
wanted
to
do
is
build
apps
and
I
soon
figured
out
that
it's
really
complicated
and
way
too
annoying
I
just
want
to
build
apps
so
found
a
little
something.
That's
called
hoodie
and
it's
an
open
source
project
that
gives
you
generic
back
end
for
your
apps
and
it
allows
you
to
build
apps
really
really
fast,
because
you
have
sign
up
data
storage.
Think
all
that
already
you
don't
have
to
build
it
over
and
over
and
over
again
and
like
most
open
source
projects.
A
It's
not
one
hundred
percent
done
yet
so.
Instead
of
building
my
own
apps
I
got
involved
with
hoodie
and
help
building,
hoodie
and
modularizing
it
and
maintaining
the
packages
that
it
consists
of.
So
you
should
check
out
hoodie
its
hood,
that
IE,
but
soon
as
I
said
as
soon
as
it
was
working
on,
hoodie
I
got
really
really
annoyed
by
publishing
all
these
packages,
because
there
are
a
lot
of
steps
that
I
had
to
do
over
and
over
and
over
and
over
again
and
they're
really
complicated.
A
We
heard
a
few
references
to
it
already,
which
is
fine,
because
people
seem
to
like
it
and,
as
you
already
heard,
from
Andrew,
it's
built
on
top
of
conventions
on
top
of
commit
message
conventions
and
it
figured
out
sember
for
you
and
change
notes,
and
my
number
one
learning
from
this
writing
this
tool
is
that
enforcing
and
building
on
top
of
best
practices
is
a
really
good
idea.
If
you
want
to
build
tooling
so
now,
the
publishing
was
fixed.
A
I
could
go
back
to
hoodie
well
until
I
get
annoyed
again
like
we
had
to
keep
all
these
dependencies
and
all
these
packages
up
to
date
and
a
hoodie
we
use
the
same
like
we
have
a
set
of
dependencies
that
we
use
over
and
over
again,
especially
for
deaf
dependencies,
so
testing
tools
to
that
and
our
lending
and
all
that
stuff.
It's
it's
all
the
same
everywhere.
A
So
this
situation
here
it
probably
happened
a
few
too
many
times
like
oh
cool,
there's,
this
new
version
of
this
cool
package-
and
there
are
so
many
cool
things
in
there.
But
now
I
have
to
go
into
20
projects
check
it
out,
pull
it
up,
change
the
package
Jason
with
the
new
version
run
the
tests
push
it
up,
open
up
or
requests,
wait
for
the
CI
result,
merge
it
back
in
and
then
maybe
also
get
a
new
version
out.
A
So
luckily
one
of
the
original
founders
of
hoodie
young
Leonard,
it's
also
the
vice
president
of
Apache
couchdb,
which
the
original
NPM
registry
was
also
built
on
and
so
I
knew
there's
a
changes
feed
in
every
counter
to
be
which
gives
you
real-time
updates
of
what's
happening
inside
the
database
and
luckily
NPM
also
exposes
this
feat
for
us.
It's
available
under
skin
dbm
p.m.
GS
com,
and
we
heard
that
within
the
tonic
talked
already,
and
you
can
use
this
to
build
really
cool
stuff,
so
the
first
part
was
done.
A
We
have
NPM
updates
and
then
we
need
the
second
part
which
is
easily
create,
commits,
etc,
etc.
So
I
don't
know
if
you
can
read
it.
It's
almost
exactly
one
year
ago
that
I
wrote
this
tweet,
where
I
said
I
want
to
create,
commits
yet
a
github
API
with
minimal
overhead,
ideally
only
sending
a
patch.
Is
there
anything
ready-made,
hashtag
lazy
to
return,
and
really
this
was
one
of
the
very
very
few
times
where
him
did.
Npm
search
and
I
didn't
find
what
I
wanted
so
four
days
later,
the
search
is
over.
A
I
wrote
it
myself.
So
luckily
github
exposes
a
full
get
data
API,
so
you
can
handle
trees
and
blobs
and
all
that
stuff
via
the
API,
and
you
don't
have
to
actually
clone
the
repositories
and
so
rotas'
little
module
as
you
do.
That
allows
you
to
just
create
new
commits
and
branches
without
having
the
stuff
locally,
so
yeah.
The
second
part
was
done.
We
just
needed
a
little
bit
of
glue
code
in
between
a
web
service,
but
that
was
stuff.
A
We
knew
how
to
do
especially
after
building
hoodie
and
so
ready
was
our
bot,
and
he
is
how
originally
worked.
So
we
have
our
three
players,
which
is
NPM,
greenkeeper
and
github.
So
NPM
tells
us
a
module
changed.
So
then
we
figure
out
like
is
this
a
new
version.
Is
this
relevant
to
us
and
who's
depending
on
that
module
and
as
soon
as
we
figure
that
out,
we
just
sent
pull
requests
to
the
repositories,
and
this
is
how
look
like
to
get
a
pull
request.
A
It
tells
you
which
version
is
affected,
which
dependency
is
affected,
which
version
a
bit
of
metadata
and
some
advice
which
you
should
do
about
with
this,
but
it
turned
out.
This
is
only
really
useful
for
so-called
out
of
range
updates
or
what
we
call
them.
And
what
does
this
mean?
So
you
know
you
heard
about
this
earlier
as
well.
In
n
p.m.
we
have
version
ranges
that
help
you
embrace
ember
and
its
semantic
meaning.
A
So
in
this
case,
we
have
dependency
that
has
a
defined
version
number
with
the
carrot
character
for
point
0
point
0,
which
means,
if
version
5.1
point
0
comes
out.
It's
not
part
of
this
version
range
it's
out
of
the
range,
and
the
same
is
true.
If
you
have
a
tilde
character,
then
minor
versions
are
outside
of
the
range
or,
if
you
have
no
range
at
all,
then
the
patch
version
is
outside
of
the
range
and
works
really
really
well
for
that,
but
soon
this
guy
camera
I'm.
A
Sorry,
these
folks
came
around
and
we
notice
pretty
quickly
that
our
PRS
are
triggering
the
I
bills,
and
this
is
actually
really
really
useful
and
valuable
data,
because
if
the
project
has
a
decent
test
coverage,
it
can
tell
you
if
the
project
still
works
with
the
new
with
the
new
version
applied.
So
it
does
not
only
take
the
work
away
from
you,
the
automatic
GI
bills
that
are
triggered.
A
So
again,
we
have
this
carrot
character
for
point,
0,
point
0,
and
now,
if
it
wasn't
for
point
Oh
point
one
comes
out,
we
can
actually
do
something
useful
here,
and
these
versions
are
the
one
that
are
actually
really
really
dangerous
because
they
just
get
installed
and
you
don't
notice
or
you
don't
actively
upgrade
to
this
version
just
happen.
So
these
are
dangerous,
because
if
someone
doesn't
play
according
to
the
rules
of
ember
or
mistakes,
happen,
stuff
can
break
here.
A
So
now
we
were
using
the
data
that
we
got
back
from
the
from
the
CIA,
so
in
this
case
the
same
procedures
before
and
PM
told
us
the
module
change
we
figured
out
who
is
depending
on
it.
But
now
we
check
is
this
inside
of
the
existing
version
range
and
rather
than
creating
a
pull
request
directly.
We
just
created
a
new
branch
with
this
version,
update,
applied
and
then
github
comes
back
to
us
and
tells
us
with
the
status
API.
A
Did
it
fail
or
did
it
pass
and
if
it
passed,
we
can
just
delete
the
branch.
Everything
is
fine.
Your
version
range
is
still
valid,
but
if
it
fails
something
is
broken,
and
so
now
we
create
a
new
poll
request
for
in
range
updates,
and
it
looks
something
like
this.
So
in
this
case
yes,
lint
broke
a
build
process,
which
means
the
project
really
is
broken,
because
if
you
now
go
in
and
do
npm
install,
you
will
get
a
version
that
breaks
your
build.
So
this
is.
A
A
Where
everything
happens
in
the
browser
you
can
just
hit.
The
sign
in
button
go
to
github
come
back
and
you
can
just
enable
repositories
with
one
click
and
you
can
find
this
under
app.
Greenkeeper
I,
oh-
and
this
is
a
beta,
so
speak
like
if
it's
its
life,
it
works
and
we're
really
happy
if
you
can
like
try
it
out.
Go
there,
give
us
feedback.
If
you
think
where
we
could
go
with
this,
and
eventually
we
will
make
it
the
default
way
to
use
screen
keeper.
A
I
could
have
announced
even
more
at
this
moment,
but
we
wanted
to
get
it
right
first,
so
you
have
to
wait
a
little
more,
but
what
I
can
say
is
that
we
want
to
make
this
data
also
available
for
package
authors,
not
only
for
consumers,
so
that
package
authors
can
have
a
look
into
the
bills
that
we
are
triggering.
So
if
you
publish
a
new
version,
you
get
insight
into
how
many
bills
failed.
A
As
you
know,
there
are
a
lot
of
modules
out
there
and,
as
you
also
know,
people
depend
on
a
lot
of
modules
in
their
projects
and
so
all
of
a
sudden,
if
you
happen
to
enable
greenkeeper
on
your
project,
it's
too
much
noise,
and
this
is
like
the
number
one
complaint
with
the
service
and
it's
frustrating
because
it
keeps
popping
up
over
and
over
again
and
we're
trying
to
make
this
better.
But
there
are
some
concepts
that
I
want
to
explain
to
put
this
into
context.
A
What
noise
means
so,
for
example,
a
lot
of
people
are
asking
us,
rather
than
sending
Laura
cuts
in
real
time
to
make
a
weekly
digest
or
to
merge
poor
requests
automatically
as
soon
as
they
pass,
but
that's
not
really
the
philosophy
of
grim
reaper.
We
think
that
running
these
updates
in
isolation
is
exactly
what
makes
greenkeeper
valuable
because
you
know
exactly
which
dependency
broke
and
what
time
and
you
have
this
information
available
immediately
without
having
to
figure
it
out.
A
So
we
want
to
report
the
rising
problems
early
and
we
don't
want
you
cause
new
problems
by
merging
stuff
automatically
which,
just
if
you
speak
it
out,
lounge
sounds
really
dangerous.
So
here's
some
tips
and
remember
when
I
said
that,
like
building
on
top
of
best
practices
is
a
good
thing
here
are
some
of
them
good
tests.
A
The
second
thing
is
use
version
ranges,
because
if
you
use
version
ranges,
you
will
get
a
lot
less
pull
requests.
As
I
said
we
can,
if
stuff
keeps
passing,
we
don't
have
to
bother
you.
We
can
just
delete
stuff,
so
version
ranges
are
really
really
great
and
they
are
really
really
powerful
because
they
embrace
the
the
insight
that
tempered
like
the
metadata,
the
December
version
numbers
give
us
and,
together
with
your
tests,
greenkeeper
can
have
your
back
on,
fails
there.
A
So
if
someone
messes
it
up
and
like
this
is
a
mistake,
you
know,
so
you
can
just
use
version
ranges.
You
then
don't
have
to
pin
versions
anymore
and
just
use
them.
It
reduces
noise
and
another
thing
is
like
we
had
modules
and
they
publish
big
new
version
with
all
these
new
features
and
this
huge
rewrite
and
then
they
published
this
version
and
everyone
is
excited
to
try
it
out
and
like
an
issue,
comes
in
oh
well,
obviously,
it's
a
big
rewrite.
A
You
mess
something
up
version
whatever
like
patch
version
comes
out,
then
the
next
issue
comes
out.
We
have
like
10
versions
within
five
hours,
because
when
you
change
a
lot
a
lot
of
stuff,
it's
broken,
you
have
these
these
many
versions,
and
so
because
we
want
to
do
stuff
in
real
time.
Greenkeeper
sends
out
10
or
20
pull
requests.
If
you,
if
you
do
10
or
20
versions
in
five
hours,
but
NPM
already
offers
a
way
around
this
and
that's
called
dis
tags.
A
So
if
you
install
a
package,
it
automatically
installs
the
version
that
has
the
latest
this
tag
attached
to
it-
and
this
is
this
is
happening
automatically.
If
you
publish
your
version
by
default,
it
gets
the
latest
district
and
what
you
can
do
is
you
can
introduce
beta
channels
for
your
packages,
so
you
can
actually
publish
new
versions
to
the
registry,
but
it's
not
a
default
and
style
target
and
you
can
tell
you're
early
adopters
or,
like
the
community
high
try
this
new
version.
A
I
would
report
issues
to
us
or,
if
you
find
find
them,
and
if
there
are
any,
you
can
publish
one
new
version
with
the
with
the
fixes
and
then
you
can
make
that
the
default
and
star
target,
and
only
that
will
be
sent
out.
We
are
greenkeeper,
so
it's
it's
a
great
way
to
to
have
multiple
release
channels
and
I
actually
wrote
a
blog
post
on
how
to
do
this.
It's
under
bit
ly
/
dis
tags
and
another
thing
is
you:
can
let
greenkeeper
do
the
cleanup?
A
So
if
you
have
a
lot
of
pull
requests
for
the
same
dependency
in
for
the
same
version
as
soon
as
you
merge
one
of
these
poor
requests
as
soon
as
you
have
made,
your
decision,
greenkeeper
will
do
to
do
the
cleanup.
So
if
you
have
poor
requests
that
include
the
same
version,
so
let's
say
you
have
a
pull
request
for
version.
4.0
point
0
and
that's
also
one
open
for
4.0
point
one
and
you're
using
a
version
range.
A
When
you
merge
for
point
0
point
0,
it
will
close
and
delete
like
the
four
point,
no
point,
one
for
a
class
because
it's
already
included
and
equally,
if
you
merge
the
four-point
Oh
point
one.
It
closes
the
four
point:
zero
point:
zero,
because
it's
lower
as
the
version
you
merged.
So
greenkeeper
can
do
the
green
and
the
de
clean
up
for
you.
You
just
have
to
make
a
decision
and
equally,
if
you
merge,
greenkeeper,
pull
requests
and
now
all
the
other
greenkeeper
pro
requests
are
no
longer
Marable.
A
Because
there's
a
merge
conflict
in
the
package
Jason,
we
will
automatically
rebase
that
against
master,
so
that
won't
happen
as
well.
So
you
can
just
make
your
decision
and
then
let
greenkeeper
take
over
again
with
the
with
the
doll
chores.
So
I
really
don't
want
to
be
the
person
that
says
like
you're
holding
it
wrong.
But
the
thing
is
that
the
greenkeeper
experience
is
suffering
a
lot
from
underlying
problems,
and
we
would
much
rather
want
to
fix
the
underlying
problems
rather
than
work
around
them
with
greenkeeper.
A
So
we
want
to
build
on
best
practices
and
we
want
to
help
spread
them
so
have
appreciated
here.
If
you
have
ideas
that
are
in
line
with
the
philosophy
that
I've
just
described
with
like
isolated
updates
and
taking
away
chores,
but
don't
making
decisions,
that's
great.
If
you
convince
us
that
this
philosophy
is
wrong,
that's
also
great
or
if
you
want
to
help
educate
people
about
these
best
practices
that
I
lied
out.
A
If
you
want
to
send
pull
request
with
better
tests
that
remove
dependency,
the
dependency
on
a
third-party
service
or
stuff,
like
that,
that's
all
really
great,
and
we
really
appreciate
it.
So
you
can
talk
to
us
or
help
other
people
to
to
build
on
these
best
practices.
So,
to
sum
this
up,
writing
software
is
embracing
change
and
drink
keeper
makes
the
change
visible.
A
So
I
hope
with
this
talk,
you
now
understand
how
greenkeeper
works,
why
it
works
the
way
it
works
and
that
you
got
the
philosophy
we're
trying
to
apply
here.
So
greenkeeper
is
a
service
that
we
really
just
wanted
to
have
four
for
ourselves,
but
we
also
made
it
available
for
everyone.
You
can
use
it
for
free
on
your
open
source
projects,
but
they're
also
support
private
and
even
enterprise
plans
available.
A
A
If
you
cannot
support
us,
that's
cool,
but
we
think
it's
it's
like
cool
if
you
use
green
people
on
your
open
source
modules
and
help
us
like
have
the
NPM
ecosystem
be
up
to
date
and
like
have
managed
dependencies
and
I'm
around
here
to
talk
about
these
ideas
that
I
hope
some
of
you
have
I
have
stickers
and
that's
it.
Thank
you.