►
From YouTube: Chronicles of the Node.js Ecosystem: The Consumer, The Author, and The Maintainer - Bethany Grig
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
One
of
the
areas
that
our
team
explores
is
how
we
can
encourage
and
support
our
enterprise
customers
to
leverage
node.js
and
its
module
ecosystem.
So
you'll
probably
know
firsthand
the
value
of
node.js
modules.
I
personally
think
they're
one
of
the
most
powerful
things
about
node.js,
with
over
one
million
modules
on
the
npm
registry.
There's
a
high
chance.
One
already
exists
to
support
the
task.
You
have
at
hand.
A
This
can
be
achieved
in
just
17
lines
of
code
and
installing
one
direct
dependency,
the
twitter
module-
and
this
is
just
to
demonstrate
the
power
of
modules
and
show
that
they
enable
you
to
be
productive
quickly,
not
solve
problems.
Others
already
have
and
enable
you
to
focus
on
the
business
logic
of
your
application,
rather
than
lower
level
implementation
details,
but
the
usage
of
modules
can
pose
different
challenges
and
these
challenges
can
apply
not
only
to
the
users
and
consumers
of
the
modules,
but
the
module
authors
and
maintainers
too.
A
Today,
I'd
like
to
share
some
of
these
concerns
and
later
talk
about
how
the
node.js
package
maintenance
team
is
working
to
alleviate
and
provide
guidance
for
some
of
these
issues.
First,
I'm
going
to
talk
a
bit
about
the
risks
of
consuming
node.js
modules.
It's
probably
safe
to
say
almost
all
node.js
developers
fall
into
the
user
or
consumer
category,
even
if
they
are
authors
and
maintainers
too.
A
Going
back
to
my
other
example,
I
built
a
small
program
just
using
the
twitter
module
and
17
lines
of
code.
This
example
program
had
just
one
direct
dependency:
the
twitter
module,
but
that's
actually
a
lot
of
code
in
production
when
we
look
at
the
whole
tree
of
dependencies,
there's
actually
a
total
of
49
unique
packages.
This
is
because
the
twitter
module
depends
on
many
other
modules.
A
If
we
look
at
the
lines
of
code,
there's
almost
60
000
lines
of
javascript
script
covered
by
six
different
license
types,
and
what
this
shows
is
the
amount
of
code
you
write
is
significantly
different
from
the
amount
that
you
deploy
and
are
responsible
for
in
production
as
a
developer.
It
is
just
as
important
to
think
about
the
code.
You
did
not
write
as
much
as
the
code
you
did,
and
this
is
what
concerns
some
of
our
enterprise
customers,
the
more
code
you
deploy
into
production,
the
more
risk.
A
A
Those
include
making
use
of
npm
audit,
but
that
itself
comes
with
a
challenge,
as
it
cannot
tell
you
if
your
application
is
actually
susceptible
to
the
vulnerability
that
is
detected.
You
can
use
features
such
as
github
security
alerts.
You
can
lock
down
your
package
json
or
publish
a
package
lock
json.
A
A
A
A
A
It
can
be
difficult
to
understand
the
license
terminology.
Luckily,
there
are
a
few
tools
that
can
help
this.
The
first
is
tldrlegal.com,
and
this
helps
to
convey
software
licenses
in
plain
easy
to
understand
english
and
there's
also
the
github
licenses
view
where
it
will
break
down
the
license
into
what
it
permits
you
to
do.
Limitations
and
conditions
of
the
license.
A
Some
tools
exist
to
help
you
understand
which
licenses
are
included
in
your
whole
module
tree.
You
can
use
a
module
named
license
checker.
This
will
provide
a
summary
of
all
of
the
licenses
it
can
detect
in
the
tree.
There's
a
big
caveat
with
this,
though
it
will
only
show
you
what
the
license
field
says.
It
will
not
check
the
license
text
itself,
so
it's
still
very
possible.
There
are
clauses,
you're
missing
or
perhaps
even
the
license
field
in
the
package.
Json
doesn't
match
the
license
file
in
the
repository
itself.
A
However,
this
tool
does
help.
Give
you
a
general
overview
of
which
licenses
are
included
in
your
module
dependency
tree
now
to
consider
maintenance.
I'm
sure
most
businesses
understand
that
once
you've
built
a
piece
of
software,
there
is
an
ongoing
maintenance
cost
that
you
need
to
account
for,
but
if
most
of
the
code
isn't
your
own
and
it's
coming
from
your
dependencies,
you
also
need
to
consider
how
well
maintained
your
dependencies
are.
A
There
are
a
few
questions
you
can
ask
yourself
to
help,
determine
how
well
maintained
a
module
is.
Those
include,
is
the
module.
Deprecated
are
issues
in
the
module
being
fixed.
Are
there
still
regular
releases
of
the
module?
Is
development
still
active
and
how
many
maintainers
are
there?
If
there's
just
one
maintainer,
what
would
happen
if
something
happened
to
them
and
they
had
to
give
up
the
project.
A
There
are
some
tools
that
exist
that
can
help
you
analyze
the
activity
and
maintenance
of
a
module.
Those
include
the
github
insights
view,
which
will
show
you
metrics,
such
as
the
number
of
match,
pool
requests,
number
of
closed
issues
etc
and
there's
also
a
website
named
mpms.io,
and
this
website
ranks
npm
modules,
high
quality
and
to
determine
quality.
They
feed
in
similar
metrics,
such
as
the
ratio
of
open
to
closed
issues
and
the
number
of
maintainers.
A
A
A
A
A
A
A
A
A
A
The
attacker
originally
appeared
to
be
acting
in
good
faith,
offering
to
take
over
maintenance
of
the
module,
but
once
they
gained
the
access
they
needed,
they
published
a
malicious
release,
and
this
really
highlights
the
need
for
some
defined
processes.
For
handing
over
modules,
so
that
covers
some
of
the
challenges
from
an
author's
perspective,.
A
So
now
we've
covered
the
user
and
author's
concern.
How
does
the
main
container
fit
in
it's?
At
this
point,
I
would
like
to
introduce
node.js
package
maintenance
team.
The
node.js
package
maintenance
team
was
established
in
2018
and
it
was
established
to
focus
on
the
sources
of
friction
to
module
ecosystem
adoption,
particularly
in
the
enterprise.
A
A
A
I
would
also
like
to
document
processes
for
authors
and
maintainers
to
follow
in
certain
situations.
For
example,
when
you're
handing
over
a
module
the
package
maintenance
team
also
wants
to
encourage
and
promote
responsible
and
sustainable
consumption
of
modules
and
also
is
working
towards
encouraging
clearer
and
closer
communication
between
users,
authors
and
maintainers.
A
So
what
is
the
package
maintenance
team?
Actually
doing
so?
We've
got
to
set
the
groundwork.
First,
we're
trying
to
understand
the
state
of
the
ecosystem,
we're
doing
this
as
surveys,
but
we're
also
getting
together
and
discussing
the
common
problems.
Users,
authors
and
maintainers
face
we're
also
asking
what
are
the
most
time
consuming
tasks
for
users,
authors
and
maintainers.
A
The
package
maintenance
team's
also
been
working
with
some
pilot
packages,
including
the
express
module
for
working
with
the
express
maintainers
we've
been
able
to
identify
some
key
problems
that
the
maintainers
are
facing.
The
first
is
that
they're
struggling
to
keep
track
of
the
status
of
all
of
their
issues
across
express
modules.
A
The
express
github
organization
has
several
repositories,
so,
with
issues
being
opened
across
them,
things
can
get
very
fragmented,
fragmented
and
difficult
to
follow,
and
also
generally
they're
struggling
to
keep
up.
With.
All
of
the
issues
raised
where
express
is
so
popular
and
the
package
maintenance
team
has
been
working
with
express
to
find
a
solution
to
their
key
issues,
and
one
of
those
we're
investigating
is
triaging
efforts.
A
A
Some
of
them
are
still
in
draft
phase,
and
this
is
because
we're
still
working
with
authors
and
maintainers
to
gather
a
variety
of
use
cases
in
some
areas.
We
may
go
a
bit
further
and
provide
resources
that
module
authors
and
maintainers
can
use
such
as
for
testing.
We
may
provide
a
sample,
travis
yama
file
that
enables
you
to
configure
your
travis
ci
to
run
across
each
of
the
supported
node.js
versions.
A
A
A
So
what
are
next
steps
for
the
node.js
package?
Maintenance
team?
Well,
we're
going
to
continue
to
seek
consensus
on
best
practices
for
module.
Consumers,
authors
and
maintainers
we're
also
going
to
continue
to
build
tooling,
to
support
consumers
offers
and
maintainers,
and
also
we're
looking
to
support
more
modules
in
need
of
help
by
recruiting
more
triages
and
in
particular,
at
the
moment,
node
fetch
is
looking
for
help
you're
interested
in
getting
involved
in
the
node.js
package
maintenance
team.
There
are
a
few
ways
that
you
can
do
so.