►
From YouTube: Node.js Package Maintenance... - Glenn Hinks; Bethany Griggs; Darcy Clark; Dominykas Blyze; Rodion
Description
Panel: Node.js Package Maintenance Working Group: Year 3 - Glenn Hinks, American Express; Bethany Griggs, Red Hat; Darcy Clarke, Github; Dominykas Blyze, NearForm; Rodion Abdurakhimov, Aspire Global
It is a challenge to ensure that key Node.js ecosystem modules are maintained, safe, and up to date. The resulting pain is felt by both the users of the modules, and the module authors and maintainers. The Node.js Package Maintenance Working Group was initiated in 2018 to bring together users, authors, and maintainers to work towards solutions for these challenges. This talk will showcase the working group’s current focuses, guidance, and tooling three years on.
A
Welcome
to
package
maintenance
team
working
group
year
three
panel
discussion:
my
name
is
glenn
hinks.
Now
I'd
like
to
start
off
by
just
introducing
the
package
maintenance
working
team,
so
the
health
of
the
javascript
module
ecosystem
in
part
depends
upon
the
ability
of
the
community
to
maintain
the
core
packages
within
it.
The
package
maintenance
team
is
addressing
these
issues.
These
issues
of
long-term
maintenance
goals
by
offering
a
place
for
maintenance
advice,
some
tooling
development
assistance
to
struggling,
maintainers
and
guidance
to
folks
that
depend
upon
seemingly
unmaintained
modules.
A
B
A
C
Hi
everyone,
my
name,
is
beth
briggs
and
I'm
a
senior
engineer
at
red
hat,
where
my
roles,
all
my
whole
roles,
focused
on
node.js,
including
spending
a
portion
of
my
time,
contributing
to
the
node.js
project,
particularly
I'm
active
in
the
node.js
release
working
group,
so
working
on
getting
releases
of
node
out
there,
and
also,
when
I'm
not
working
on
that.
I'm
looking
at
all
of
our
clients
that
are
using
node
in
the
enterprise
and
looking
what
issues
are
hitting
and
things
like
that.
D
D
E
Sure,
thanks
glenn,
my
name
is
darcy
clark,
I'm
the
engineering
manager
on
the
npm
clyde
team
at
github
recently
acquired
last
year,
I'm
pretty
active
in
the
node
community
and
open
source
javascript
community,
helping
out
with
opengs
efforts,
as
well
as
the
node
projects,
wherever
I
can
and
collaborating
with
folks
here
in
the
package
maintenance
working
group
as
well
as
the
tooling
working
group
and
yeah.
It's
a
little
bit
about
me.
A
A
C
C
So
the
team
was
was
announced
to
get
together
a
bunch
of
folks
who
wanted
to
work
on
the
challenges
around
module
ecosystem
adoption
with
that
enterprise
focus-
and
this
was
also
stand
because
at
the
time
there
were
a
lot
of
widely
used
modules
that
weren't
necessarily
getting
the
maintenance
and
support
that
was
needed.
When
you
look
at
how
wide
properly
how
wide
widely
they
were
used,
and
so
the
team
got
together,
then
and
since
then,
we've
been
getting
together,
probably
every
couple
of
weeks
to
talk
about
various
challenges
and
the
early.
C
The
early
kind
of
work
was
around
producing
some
best
practice
documentation
for
module
maintainers
to
follow,
particularly
to
help
bridge
the
mismatching
expectations.
Some
folks
may
have
between
consuming
and
maintaining
modules
and
and
then
from
there.
The
project
started
to
get
talk
about
more
challenges.
We
found
a
need
to
produce
some
tooling
to
help,
support
and
know
module
maintainers
and
we're
we're
still
continuing
we're
still
talking
about
new
issues
and
building
more
tooling
and
figuring
out
how
we
can
help
out.
B
Yeah,
so
node's
ecosystem
is
huge
right
and
there's
a
very
broad
spectrum
of
things
happening
there.
I
think,
there's
from
my
personal
perspective
is
is
my
personal
interest
is
to
kind
of
have
kind
of
be
able
to
sleep
at
night
quietly,
knowing
that
you
know
the
modules
that
we're
using
are
high
quality
and
are
well
maintained.
I
I
have
a
particular
interest
in
tooling
and
in
ci
tooling,
which
you
know
been
up.
I've
been
observing
the
ecosystem,
how
it
acts.
B
In
that
regard,
I
think
we
have
it
really
nice
in
node.js
land,
because
mostly
we
have
a
very
well
standardized
approach
to.
You
know
how
you
do
tests
for
how
you
run
tests
for
various
modules
right
that
you're,
using
if
there's
npm
test
as
a
shortcut
and
for
a
very
long
time
we
had
a
very
nice
open
source
initiative
from
travis,
where
pretty
much
everybody
used
the
same
setup
in
ci
as
well,
so
yeah
just
watching
out
for
modules
to
be
up
to
date,
and
there
was.
B
There
was
also
the
case
that
around
the
time
that
this
group
started,
there
was
the
eslint
scope,
issue
security
problem
and
you
know:
there's
there's
people
moving
on,
there's
packages
being
abandoned,
but
they're
still
getting
a
lot
of
use.
So
in
terms
of
overall
health,
I
just
want
you
know
for
the
customers
to
deliver
the
proper
experience,
and
you
know
the
quality
modules
that
they
can
use.
A
D
Yeah,
we
all
know
that
companies
that
build
a
big
enterprise
level
application
they
desire
to
depend
on
the
stable
maintainable
packages
with
predictable
releases
and
smooth
node.js
version
upgrades.
So,
unfortunately,
we
see
the
situation
that
some
critical
for
the
ecosystem
packages
may
not
receive
required
level
of
support
because
of
increased
popularity
of
the
package,
but
in
the
same
time,
initial
maintainers
were
not
reinforced
with
relative
manpower
to
deal
with
a
growing
amount
of
issues.
B
A
Thank
you,
rhodium,
that's
very
interesting
and
that's
a
very
common
view.
I
feel
from
many
people
the
concern
about
the
sheer
size,
what
happens
as
people
that
initiate
modules
and
hand
off
to
maintainers
what
happens
next?
It
is
such
a
vast
system
and
I'm
not
sure
that
this
really
has
happened
on
this
scale
before
bethany.
C
What
what
actually
makes
a
module,
supported
and
maintained
enough
for
you
to
be
willing
to
stand
like
stand.
Your
whole
production
application
on
top
of
it,
and
so
that
that's
really
where
a
lot
of
my
interest
comes
from,
and
why
I
like
getting
involved
because
trying
to
trying
to
figure
out
how
we
can
encourage
responsible
consumption
of
modules
and
how
to
help
people
choose
them.
A
A
E
Glenn
yeah,
so
my
original
involvement
was
is
bit
selfish,
obviously
trying
to
stay
up
to
date
with
other
folks
in
the
ecosystem
and
and
also
trying
to
hopefully
bring
discussions
into
a
form
that
is
sort
of
neutral,
a
neutral
form.
I
really
like
what
we've
done
here
with
this
group
from
npm's
perspective
in
terms
of
the
ecosystem
and
how
it's
changing
evolving,
we
can
continue
to
see
exponential
growth.
E
E
E
If
you
compare
that
to
other
languages,
python
is
819
roughly
19
median
transitive
dependencies,
ruby,
68
and
php
is
70,
the
closest
to
you,
know
node
and
javascript
projects.
So
that's
pretty
interesting
in
terms
of
the
growth
and
sort
of
the
network
that
we're
establishing
here
as
an
ecosystem
and
sharing
projects
with
each
other.
It's
a
big
web
and
we're
all
working
together,
hopefully
to
strengthen
you
know
our
projects.
A
Thank
you
darcy,
and
it
is
interesting
to
note
that
sometimes
we
have
a
let's
say,
a
selfish
self-interest
from
a
perspective
that
we
have,
but
that
interest
actually
serves
the
wider
community
because,
funnily
enough,
we
all
have
that
same
interest.
We
want
our
thing
to
be
maintained
and
to
be
stable,
but
the
only
way
to
get
our
thing
to
be
maintained
is
to
do
it
at
a
much
larger
level
because,
as
you
say,
we
have
so
many
dependencies
and
now
all
open
source
majority
of
them
maintained
by
volunteers
in
in
the
community.
A
A
That
time
has
long
since
passed
as
darcy
has
said,
you
just
got
to
look
at
the
size
of
it.
It
is
now
the
largest
ecosystem
and
the
barriers
to
entry
are
very,
very
low,
very
low
indeed
compared
to
other
ecosystems.
You
do
not
need
years
of
experience
to
make
a
really
big
positive
contribution,
and
this
makes
it
a
very
inviting
community
and
I
look
at
it
and
I
can
see
people
with
only
one
year's
experience
making
packages
pushing
them
out
and
they're
being
adopted.
A
However,
I
see
also
see
from
everything
we
said:
there's
a
downside
to
a
large
ecosystem.
We
have
the
most
dependencies
transitive
dependencies
and
we
do
see
common
modules
becoming
less
commonly
used
and
as
ideas
change,
we
the
common
models,
might
change,
and
this
is
good.
The
ecosystem
we're
pushing
this
ecosystem
forwards.
However,
there's
a
basic
underpinning
of
the
ecosystem,
the
underpinning-
actually
comes
from
commercial
companies.
A
They
pay
for
us
to
go
to
work
and
do
stuff,
and
although
we
use
this
this
thing,
they
have
revenue
generating
sites
that
often
depend
upon
these
maintained
pieces
of
code
and
sometimes
some
modules
get
superseded
by
others,
and
these
modules
that
they
depend
upon
are
now
unmaintained
and
when
we
say
unmaintained,
there
are
different
types
of
unmaintained.
Somebody
may
not
have
time.
Somebody
may
have
essentially
ghosted
a
module
and
have
moved
on.
A
A
What
should
we
do,
and
I
think
this
is
the
first
time
as
an
ecosystem,
and
I
originally
was
looking
into
the
ecosystem
from
the
outside
before
I
joined
it
and
when
I
was
on
the
inside,
I
realized
it
was
much
bigger
on
the
inside
than
the
outside,
meaning
I
realized
what
it
was
we're.
The
the
first
point
of
call,
I
think,
that's
been
set
up
for
this
actual
long-term
health
of
the
ecosystem.
So
that's
what
my
mine
is
also
selfish.
A
I
want
things
I
use
to
be
maintained
and
the
only
way
to
do
that
is
to
do
that
at
this
sort
of
larger
level.
So
I'd
like
to
thank
everyone
for
that
taking
given
us
their
perspectives
on
this
particular
ecosystem,
I'd
like
to
go
into
some
of
the
things
we've
actually
done
in
the
package:
maintenance
team,
I'd.
E
A
To
go
to
the
early
days,
this
is
a
three-year
look
back
when
we
first
started.
Obviously
you
know
there's
lots
of
interest
when
a
team
is
first
kicked
off.
We
we
are
looking
to
see
what
our
our
remit
was.
What
were
we
doing
and
we
actually
started
with
documentation
so
with
many
projects.
The
initial
phases
are
characterized
by
long
open
discussions
and
we
were
no
different.
We
had
long
open
discussions.
A
So
we
started
writing
things
down
and
some
of
the
the
first
things
we
we
wrote
down
were
really
basic
things
like
what
license
should
you
have
and
we
looked
at
licensing,
we
actually
contacted
npm
and
we
said
what
are
the
most
popular
licenses
and
they
provided
us
with
a
nice
ordered
list,
and
from
that
we
made
some
judgment,
calls
and
said:
okay,
these
are
the
commonly
used
ones.
We
recommend
you
should
have
a
license.
We
wrote
it
down
at
that
time.
It
was
still
very
early.
A
We
weren't
sure
how
much
or
how
big
a
remit
we
had.
So
we
started
writing
down
other
things.
We
wrote
down
what
we
thought
about
testing.
We
came
up
with
a
governance
model
for
our
team.
It
was
very
much
about
starting
off
and
we
weren't
quite
sure
what
the
entire
remit
was.
We
knew
what
the
problem
was,
but
how
should
we
go
about
solving
it?
A
Somebody
could
come
to
us
and
we
could
say
yes,
we
will
contact
them.
We
will
say
who
we
are.
Are
you
maintained?
Are
you
not
maintained
and
we
would
wait?
We
pri
provides
some
sort
of
guidance
to
users.
It's
not
just
a
case
of
maintainers
there's
also
the
users
of
those
modules
and
then,
of
course,
this
leads
into
what
we
should
do
when
we
actually
have
to
support
things.
So
I'm
now
going
to
ask
rhodium
about
the
package
support
tool.
What
does
support
mean
to
you
and
why
is
it
valuable,
rhodium.
D
So
it
was
decided
to
document
a
process
of
how
package
maintainers
can
communicate
the
level
of
support
they
are
going
to
to
provide
for
the
package
that
they
create
and
we
created
a
specification
called
package
support
which
describes
how
package
maintainer
can
specify
target
version
of
node.js
they
will
to.
They
will
support
and
how
quickly
maintainer
will
respond
to
issues
and
the
bacon.
D
So
how
package
is
supported
and
how
consumers
may
help
support
the
package
and,
based
on
this
specification,
we
created
the
tool
called
support
that
will
help
maintainers
to
create
and
validate
the
structured
support
information
for
their
packages,
and
this
tool
also
can
read
support
information
in
dependencies
three
of
the
projects.
So
I
definitely
recommend
everybody
to
check
out
pkg.js
support
repo.
E
A
A
How
much
support
do
you
think
users
should
be
getting
and
do
you
think
that
they've
become
a
little
bit
spoilt
after
all,
most
of
these
modules
are
maintained
by
volunteers
and
we
always
enter
into
these
things.
Very
you
know
bright
eyed,
but
after
a
few
years
of
maintaining
something,
you
may
become
a
victim
of
your
own
success.
B
I
can
answer
the
first
question
right
as
a
user
of
a
package.
You
should
expect
zero
support
right.
That's
that's
the
reality
of
this.
I
think
there's
a
lot
of
ethics
of
open
source
to
be
communicated
to
a
lot
of
people.
On
the
other
hand,
there
is
a
certain
expectation-
I
guess,
between
the
people-
that
overall,
the
community
would
step
up
to
fix
major
issues,
and
I
think
this
has
happened.
B
I
think
there's
a
bunch
of
really
well
known
and
widely
used
packages
that
have
not
necessarily
exactly
changed
hands
over
the
past.
You
know
few
years,
even
even
last
year
that
have
been
receiving
security
reports,
vulnerabilities
cds
that
have
been
getting
addressed,
and
I
think
that
overall,
as
long
as
you
know,
you're
picking
your
modules
carefully,
the
community
has
been
providing
that
support
to
to
kind
of
not
necessarily
guarantees,
but
a
certain
baseline
of
support
where
issues
are
getting
addressed
in
a
timely
manner
in
critical
packages.
A
Yes,
it's
a
it's
a
very
interesting
thing
on
the
face
of
it.
We're
kind
of
offering
an
ecosystem,
however,
currently
we're
not
guaranteeing
any
levels
of
support,
and
I
think
many
of
us
on
this
panel
are
always
amused
by
the
things
we
read
in
github
and
the
demands
that
are
made
upon
maintainers,
who
have
given
their
time
freely
that
they
should
provide
features
or
services
to
people.
A
B
Yeah,
so
webby
is
a
bit
of
an
experiment.
I
guess
there
is
an
overall
need
to
have
a
gener,
a
generic
tool
in
the
ecosystem
that
would
be
similar
to
the
scanner
in
the
gold
mine
tool.
That's
available
for
node.js
itself,
whereby
there's
nightly
builds
of
node
or
prerelease
cat
release.
Candidates
of
node.js
are
getting
tested
against
the
modules
in
the
ecosystem.
B
B
What
will
be
does
differently
is,
and
I
guess
that's
the
tricky
part
and
that's
the
experiment
part
right
to
see
if
it
works
is
instead
of
downloading
the
packages
and
running
their
tests
locally,
it
opens
pull
requests
or
pushes
branches
into
the
package
repositories
of
dependents,
which
allows
these
tests
to
actually
run
in
the
ci
environment
of
that
package.
The
way
it
is
set
up.
So,
as
I
mentioned,
we
we
have
mostly
standardized
in
node.js
ecosystem
to
basically,
you
can
test
any
package
using
npm
test.
B
However,
if
you
do
that
locally,
that's
probably
going
to
run
in
the
node.js
version
that
you
have
installed
locally,
whereas
most
of
the
packages
would
probably
be
testing
against
multiple
would
be
targeting
multiple
versions
of
node
right,
so
you
could
have.
I
guess
10
is
how
is
it
out
yet
yeah?
It's
probably
out
of
support.
Yet
at
this
point,
but
if
you
have,
if
you're
supporting
12,
14
and
16-
and
you
start
to
use
new
features,
you
could
be
breaking
something
in
node
14,
so
you
want
to
test
the
whole
run.
B
The
whole
suite
the
whole
system
of
tests
with
the
changes
that
you're
making
so
webby
tries
to
do
that
and
yeah.
It's
very
much
still
in
progress,
there's
a
couple
of
unsolved
issues,
but
we're
moving
there
and
we'll
see
how
that
goes
right,
I'm
very
interested
to
start
using
it
in
in
in
real
life
against
real
packages
against
real,
I
guess
plug-in
ecosystems
and
we're
we're
getting
really
close
to
be
able
to
do
that.
So
yeah
looking
for
volunteers
to
test
that
as
well.
A
Yes,
I'm
I'm
super
excited
to
start
using
the
tool
too.
So
thank
you.
Thank
you
very
much.
I'm
going
to
move
on
to
darcy
now
to
talk
about
vulnerabilities,
because
we
all
know
that
vulnerabilities
cause
problems
and
nothing
freaks
out
the
enterprise
more
than
a
vulnerability
report.
Darcy.
Would
you
like
to
comment.
E
Json
spec
that
sort
of
came
came
out
of
that
work,
and
so
myself
and
wesley
todd
have
become
the
co-champions
of
a
new
collaboration
space
in
the
open.js
foundation.
It's
the
first
ever
it's
called
the
package.
Let
me
get
the
name
right.
It's
very
long
package,
vulnerability
management
and
reporting
collaboration,
space
and
we'll
be
kicking
off,
essentially
the
first
session
there
at
at
this
conference
and
and
we'll
be
talking
a
little
bit
more
about
what
we're
hoping
to
achieve
with
that
group.
E
The
idea
being
that
we
would
like
to
improve
the
cve
reporting
and
sort
of
resolution
workflows
that
we
see
today
going
back
to
some
of
the
data
that
I
I
gave
before
from
the
github
state
of
the
octoverse.
We
see
roughly
59
of
those
683
transitive
dependencies
they're
up
to
59
of
them
are
going
to
get
a
security
alert
within
a
year
of
them
being
active
on
in
a
in
a
project.
So
that's
that's.
E
More.
So
that's
the
idea
behind
putting
together
this
collaboration,
space
and
we're
working
with
folks
that
have
already
been
working
this
space
for
a
while
and
yeah
we're
hoping
that
the
outcomes
of
that
work
will
be.
You
know,
improved,
tooling
and
potentially
even
auditing
tooling,
for
for
the
ecosystem
as
a
whole.
So
that's
a
little
bit
about
what
we're
doing
that
space
and
that
was
spun
out
of
this
group,
which,
which
is
an
amazing
and
exciting
initiative.
A
Yeah,
it
is
quite
amazing
to
think
we've
spun
off
some
children
from
from
the
team
and
no
one
takes
security
lightly
and
you
know
for
the
health
of
the
ecosystem
and
its
adoption
within
the
enterprise.
This
is
a
serious
thing
and
it's
good
to
have
a
place
to
go,
that
we
could
point
those
organizations
to
and
go.
We
take
this
seriously
as
well.
So
I'd
like
to
get
back
to
bethany
and
have
a
talk
about
what
she
thinks.
The
greatest
achievements
for
the
package
maintenance
team
is
so
far.
C
So
we
have
the
folks
from
npm.
We
have
people
who
are
active
within
node
project
and
so
bringing
all
of
these
people
together
to
try
and
figure
out
the
problems.
I
think
that's
probably
the
greatest
achievement
because
we're
we're
then
satisfying
everyone's
needs
and
challenges,
rather
than
just
like
a
subset
of
the
the
constituencies.
A
Absolutely
so
this
is
the
first
time
I've
been
involved
in
a
party
group
two,
and
you
know
I
just
walked
up
to
people
at
conferences,
yeah
yeah
I'll
help.
I
don't
know
how
I
help
and
they
reached
out
to
me
and
said.
Okay,
and
I
said
what
you
don't
want
me
to
write
code,
they
said
no,
and
I
think
if
we
give
that
message
to
people,
it's
not
just
about
writing
code
and
majority
of
projects
need
other
help
too.
D
Yes,
so
I
joined
working
group
almost
a
year
ago
and
I
heard
that
node.js
working
groups
have
live
meetings
on
youtube,
so
I
decided
to
check
those
recordings
and
I
found
meetings
for
package
maintenance
working
group
and
after
that
I
subscribed
to
working
group
repo
on
github
and
from
one
of
meeting
notes
in
that
repo.
I
discovered
a
pkgs
organization
with
tooling
repositories,
so
I
subscribed
to
several
repositories
there
and
in
a
few
days
I
think
I
got
a
notification
that
some
of
support.
D
A
So,
thank
you
rhoda
and
I'd
like
to
reinforce
that.
The
most
important
thing
is
not
your
ability
or
the
level
of
your
contribution.
It's
actually
just
participation,
and
I
I
keep
saying
this
to
people
people
I
work
with
people.
I
kind
of
it's
actually
please
participate
you'll,
find
that
you're
far
more
valuable
than
you
realize,
no
matter
what
your
skill
level
is.
A
So
I'd
like
to
wrap
up
today,
I'd
like
to
thank
each
one
of
the
panelists
and
if,
if
you're
listening
to
this,
that
we
will
be
taking
questions,
what
I'd
like
to
say
is
the
number
one
thing
with
any
ecosystem
for
its
vibrancy
is
its
community
and
I
think
whatever
your
level
of
contribution
or
skill
level
is
actually
just
that
first
initial
participation
often
leads
to
greater
and
better
things,
and
all
I
can
say
is
there's
almost
no
downside
to
participation.
I
can
think
of.
All
I
can
say
is
there
is
an
upside.
A
We
are
the
largest
community.
I
said
at
the
beginning.
We
were
not
viewed
as
serious
to
begin
with,
but
I
think
everybody
knows
we
are
very
serious.
We
are
very
large
and
we
are
certainly
a
competitor
to
most
ways
of
doing
things
in
what
I'd
called
a
traditional
neoclassical
way.
We've
provided
a
different
way
with
a
very
low
entry
point
for
junior
developers,
with
that
I'd
like
to
thank
the
panelists
and
wish
everyone
a
great
day.
Thank
you
all.