►
From YouTube: The JavaScript coders guide to getting more from GitHub and NPM - GitHub Satellite 2020
Description
Presented by Ed Thomson, GitHub
In this session, we'll talk through the implications of NPM joining the GitHub family for JavaScript developers, and how to get the best out of GitHub for both your open source work as well as your work inside your organization.
GitHub Satellite: A community connected by code
On May 6th, we threw a free virtual event featuring developers working together on the world’s software, announcements from the GitHub team, and inspiring performances by artists who code.
More information: https://githubsatellite.com
Schedule: https://githubsatellite.com/schedule/
B
So
the
gentleman
that's
joining
us
next
is
actually
we've
been
buddies
for
gosh
15
years
now
we
did
a.
We
were
in
a
start-up
together
and
then
got
bought
by
Microsoft,
and
then
he
went
over
to
github
and
then
you
know
we
will
get
home
and
now
he's
back
in
and
then
you
know
that
was
all
good.
So
then
I
I
been
left,
Microsoft
and
joined
there
that
get
home
so
anyway,
I've
kind
of
spoiled
the
surprise.
B
So
ya
know:
we've
got
thousands
coming
up
next
for
Edwin
Thompson
he's
going
to
be
talking
to
us
about
another
acquisition.
That's
been
happening.
Actually
it's!
The
JavaScript
code
is
going
to
get
a
little
bit.
Npm
is
what
we're
going
to
talk
about
so
he's
going
to
take
us
through.
You
know
the
NPM
team
them
joining
github
and
what
that
means
and
kind
of
what
the
the
future
is
firm.
Yeah
now
that
it's
part
of
the
guild
family
so
really
excited
to
this
session,
really
excited
to
talk
to
Ed
afterwards.
C
Hi
everybody
thanks
so
much
for
joining
me
here
at
github
satellite,
the
virtual
Edition
this
year,
I'd
be
lying.
If
I
said,
I
don't
want
to.
You
know,
be
meeting
you
face-to-face
and
talking
to
you
directly
about
the
projects
that
you're
building
and
about
the
packages
that
you're
publishing
NPM.
Obviously
we
can't
do
that
this
year,
so
I'm
really
happy
that
github
has
been
able
to
keep
us
healthy
and
safe
together
and
that
you've
decided
to
join
us
virtually
this
year.
C
My
name
is
Everett
Thompson
I'm,
a
product
manager
at
github
and
I
work
on
NPM
and
if
that
doesn't
entirely
make
sense,
why
is
there
a
product
manager
at
github
working
on
NPM?
Well,
it
turns
out
that
NPM
has
been
acquired
by
github,
so
we
announced
earlier
this
year
in
March
that
the
github
was
going
to
acquire
NPM
Inc
and
then
a
few
weeks
ago
we
actually
completed
the
acquisition
in
mid-april.
So
now
NPM
is
a
part
of
github
and
here
at
github.
C
We're
extremely
excited
about
this
in
particular,
because
NPM
is
such
a
great
fit
as
part
of
github,
just
like
github
stores,
the
world's
open
source
software
NPM
packages
it
and
delivers
it,
and
that's
not
going
to
change
we're
going
to
continue
to
invest
in
NPM
and
continue
to
improve
it,
because
the
entire
JavaScript
ecosystem
relies
upon
NPM
and
in
the
year
2020.
That's
a
huge
portion
of
the
development
ecosystem,
because
almost
every
single
web
app
uses
JavaScript
on
the
front
end.
C
Many
of
them
use
javascript
on
the
back
end-
and
you
know
many
desktop
apps
are
even
built
in
JavaScript,
like
vs
code
and
and
slack
the
things
that
we
use
on
a
day
to
day
basis
and
all
of
those
applications
rely
on
NPM
when
I
think
of
the
NPM
product
I,
think
of
it
in
two
parts.
First,
there's
the
NPM
CLI
and
that's
what
most
of
us
are
used
to
interacting
with,
on
a
day
to
day
basis.
C
After
we've,
cloned
our
worries
down
from
github,
we
run
npm
install
to
actually
install
our
dependencies
and,
like
most
of
my
projects,
were
actually
typescript,
so
I
run
npm
run
build
to
transpile
that
typescript
into
javascript,
and
then
I
run
NPM
tests
actually
test.
My
application
so
I
think
that
when
many
of
us
think
about
NPM,
we
think
about
the
actual
NPM
CLI.
C
But
in
fact
NPM
is
a
lot
more
than
just
that.
There's
also
the
NPM
registry
and
that's
where
all
those
packages
live
that
NPM
fetches
and
it
turns
out
that
not
every
developer
actually
uses
NPM
on
the
command
line.
You
might
use
a
different
package
manager
like
ER
and
that's
another
great
tool,
but
whatever
you
use,
whether
it's
NPM
or
yarn
you're,
actually
still
downloading
those
packages
from
the
NPM
registry.
So
to
suggest
that
the
NPM
registry
is
important
is
an
understatement.
It's
actually
an
absolutely
critical
piece
of
structure.
C
It
turns
out
that
it
contains
just
about
one
and
a
quarter
million
packages.
Now
this
is
everything
from
the
critical
packages
that
make
up
modern
software
development
things
like
lodash
Express
and
react,
and
it
also
ends
up
being
things
like
the
silly
applications
that
I
write
that
I
build
and
publish
like
a
little
library
for
doing
complex
arithmetic.
All
of
these
packages
live
in
the
NPM
registry
and
they're
available.
Every
time
you
run
npm
install
last
week
there
were
over
20
million.
C
I'm
sorry
there
are
over
20
billion
downloads
of
packages,
so
this
is
every
time
somebody
downloads
a
project
and
runs
npm
install
or
every
time
somebody
does
a
CI
build
on
github
actions
and
runs
npm
CI.
I
think,
like
one
or
two
of
these
downloads
might
even
be
packages
that
I
built
and
as
an
app
mention
it
mentioned
in
his
keynote.
Last
month
there
were
over
84
billion
downloads
of
packages.
C
Now
we
often
call
these
things
vanity,
metrics,
and
when
you
do
that,
I
think
that's
okay,
but
you
might
minimize
these
numbers
because
each
of
these,
almost
85
billion
downloads,
has
to
succeed,
and
if
it
doesn't,
you
can't
do
your
development.
Each
of
these
downloads
has
to
succeed,
or
you
can't
do
a
deployment,
and
so
it's
absolutely
crucial
that
the
NPM
registry
is
fast,
stable
and
available
to
you
as
a
JavaScript
developer,
and
so
we're
going
to
continue
to
invest
in
NPM
to
make
sure
that
your
downloads
keep
working.
C
So
since
it's
the
thing
that
we
interact
with
most
or
at
least
most
obviously
I
want
to
talk
about
the
NPM
CLI
first,
so
right
now
the
team
is
working
on
NPM
v7
and
that's
the
next
version
of
the
CLI
and
it's
actually
a
really
big
shift.
The
CLI
team
is
doing
some
major
refactoring
they're,
improving
correctness
and
performance
they're,
helping
secure
your
software
better
and
they're
trying
to
improve
compatibility
with
the
other
tools
in
the
ecosystem.
Now
I
was
actually
able
to
get
a
sneak
peek
of
what's
coming
in
in
NPM
v7.
C
It
turns
out
I,
just
cloned
the
the
repo,
because
the
NPM
CLI
is
open-source,
so
they've
shared
that
with
me
and
I'm
actually
able
to
take
a
look
so
I'm
able
to
show
you
as
well.
So
one
of
the
things
that
the
NPM
CLI
team
is
improving
is
the
experience
around
NPM,
audit
and
I
think
this
is
incredibly
important.
You
because
NPM
Aude
it
helps
us
secure
our
software
better,
and
so
here
I
have
a
really
simple
package,
a
really
simple
JavaScript
project.
It
has
one
dependency.
C
It
turns
out,
oh,
that
this
dependency
is
a
little
bit
old
and
now
has
some
vulnerabilities.
So
if
I
run
NPM
audit
using
the
current
version
of
NPM
NPM
v6
I
can
see
exactly
what
it's
doing
and
it'll
take
just
a
second
and
it
finds
well,
it
tells
me
if
it's
found
eighteen
low
severity
vulnerabilities
there.
It
is
right
there
and
I
think
that's
helpful,
but
there
are
actually
some
problems
here.
For
example,
there's
a
lot
of
noise
like
this
tabular
layout
is
really
pretty,
but
it's
also
really
space
inefficient.
C
It's
taking
up
a
lot
of
space
just
to
tell
me
that
there's
a
simple
problem
in
one
package
and
that
package
is
minimus,
minimus,
tis
a
really
popular
package,
and
so
you
actually
see
it
a
couple
times
in
here,
because
it
turns
out
that
the
minimus
package
is
used
by
other
packages.
You
can
see
it's
used
by
make
turkey
it's
used
up
here
again
by
make
therapy
it's
used
down
here
by
optimist,
and
so
the
minimus
package
having
a
vulnerability
means
that
I
get
this
repeated
over
and
over
again
and
that's
fine.
C
It's
really
helpful
that
all
this
information
is
there,
but
it
would
be
more
ideal
if
this
were
a
little
bit
more
concise
if
I
could
get
the
information
about
the
security
vulnerabilities
and
how
to
fix
them
as
directly
and
quickly
as
succinctly
as
possible.
So
that's
one
of
the
nice
new
changes
in
@pm
v7.
C
So
if
I
run
NPM
audit
using
NPM,
seven
well,
the
outputs
a
lot
different
I
don't
have
that
tabular
layout
anymore.
So
it's
not
taking
up
as
much
space,
and
you
see
that
actually,
this
is
all
it
outputs
this
time.
It
knows
that
minimis
is
the
vulnerable
package
and
even
though
I
have
multiple
things
that
I'm,
using
the
depend
on
it
like
make
derpy
and
like
optimist,
it
doesn't
have
to
repeat
the
information
over
and
over
again,
because
it
knows
that
if
I
just
update
minimis
all
of
these
problems
go
away.
C
C
But
while
we're
doing
the
with
NPM
on
it,
we're
also
making
some
really
interesting
changes
around
the
way
it
actually
understands
vulnerabilities
and
how
it
can
fix
them.
So
here's
a
package
and
if
I,
look
at
my
package
JSON,
you
can
see
that
this
is
just
a
super
simple
project.
It
depends
on
a
single
package,
make
therapy
and
it
depends
on
carat
Oh,
dot,
4.0,
that's
semantic,
versioning
or
semver,
meaning
that
we
want
make
derpy,
o
dot,
4,
dot,
o
or
any
newer
minor
version.
C
We
won't
it
automatically
update
to
the
major
versions,
because
those
could
have
breaking
changes
and
in
fact
make
therapy
does
have
a
breaking
change.
In
version
1,
it
moved
from
a
call
back
based
approach
in
version
0
to
using
a
promise
to
returning
promises
in
version
1,
and
although
the
promise
API
is
definitely
better,
it's
going
to
require
refactoring
your
code,
where
you
call
make
syrupy.
So
it's
not
something
that
just
running
npm
install
is
going
to
get
you
now.
C
The
problem
is,
if
there's
a
security
vulnerability
in
this
version
of
make
turkey
and
there
isn't
a
vulnerability
and
make
it
repeat
itself,
but
in
minimus,
if
we
look
at
our
package,
lock
JSON,
we
can
see
that
we're
locked.
It
makes
our
p
o
dot,
4
dot
2
and
we
have
minimus
that
make
therapy
depends
on
and
if
we
run
npm
6
audit.
C
What
we
see
is
that
there
is
actually
a
vulnerability.
There's
a
vulnerability
in
this
version
of
minimus
and
the
version
of
make
derpy
that
we're
using
is
ultimately
vulnerable.
Now
npm
6
audit
tells
us
that
this
vulnerability
requires
some
ver
major
dependency
updates.
It
can't
do
this
resolution
automatically.
C
It
asks
us
to
update
to
make
their
p1
so
we'd
actually
have
to
go
and
refactor
our
code,
and
that
makes
sense,
but
it's
awfully
frustrating
the
new
audit
functionality
in
NP
mv7
if
I
run
that
it
well,
it
actually
tells
me
that
it
can
address
all
issues
just
by
and
p.m.
audit
fix,
and
that's
pretty
surprising,
because
NPM
six
definitely
can't
do
that.
So
what
happens
if
I
run
NPM
seven
audit
fix?
Well,
it
tells
me
that
it
changed
one
package
and
now,
as
a
result,
I
have
zero
vulnerabilities.
So
what
did
it
do?
C
Did
it
just
ignore
that
major
version
update?
Let's
take
a
look
at
the
package:
lock
JSON?
No,
it
didn't.
It
didn't
update
us
to
the
major
version.
It
didn't
break
our
cember
it
downgraded
us.
So
what
it's
actually
done
here
is
realized
that
in
our
package
JSON
we
have
asked
for
0.40
or
anything
newer.
That
is
semantically
versioned
acceptable
and
we
were
at
ODOT
4.2
and
instead
of
being
able
to
upgrade
us
to
fix
that
security
vulnerability,
it
can
downgrade
us.
C
So
NPM
audit
has
gotten
a
lot
smarter
and
a
lot
more
able
to
deal
with
fixing
your
vulnerabilities
automatically
I'm
really
excited
about
that.
One
of
the
other
things
I'm
really
excited
about
is
compatibility
with
other
tools
in
the
ecosystem
like
yarn
here
again,
I've
got
a
super
simple
project.
This
time
I've
got
a
package
JSON
and
now
I've
got
a
yarn
lock.
That
indicates
that
people
are
using
yarn
in
this
project
and
usually,
if
I
were
to
come
in.
C
As
you
know,
somebody
new
to
the
project
and
familiar
with
NPM
and
not
yarn
what
I
would
do
is
run
NPM
install
in
this
project
and
what
happens
is
that
actually
NPM
and
yarn
don't
coexist
very
well.
So
what's
happened
now
is
NPM
has
created
a
package
lock
JSON
like
you'd
expect
and
it's
installed
make
sure
PE
version
1.4.
C
Okay,
the
problem
with
that,
though,
is
that
yarn
is
locked
at
10.2.
So
at
this
point,
NPM
has
told
me
that
I
should
commit
this
package
lock,
JSON
push
it
up
and
I
will
just
break
everybody,
because
we've
got
two
different
teams
that
team
using
NPM
and
a
team
using
yarn
using
two
different
dependencies.
That's
very,
very
frustrating
I
can
run
this
little
reset
script
to
start
over
and
now
I've
gotten
rid
of
the
NPM
package.
Locked
out,
JSON
and
I
want
to
show
you
what
NPM
7
does
in
this
environment.
C
C
We
can
see
that
our
yarn
lock
is
also
in
good
shape
now.
The
other
thing
that
can
be
problematic
is
when
somebody
tries
to
install
a
package,
a
new
package
using
NPM,
and
so,
if
I
do
that,
with
NPM
7,
let's
say
I
install
the
brief
package.
Well
again,
I
end
up
with
that
in
my
package,
lock
JSON,
you
can
see
a
brief
version.
1
1
1
and
you
know
NPM
and
yarn
kind
of
compete
with
each
other,
so
we
sure
wouldn't
want
to
update
the
yarn
lock.
Would
we
well?
C
In
fact
we
do
want
to
update
the
yarn
lock.
We
want
to
make
sure
that
these
two
tools
interact
as
nicely
as
possible,
so
there
once
was
a
time
when
yarn
and
NPM
the
two
command
line
interfaces
really
walled
off
from
each
other,
but
with
NPM
7
we're
going
to
see
big
improvements
in
their
compatibility.
I'm
really
excited
about
that.
C
Another
place.
I'm
excited
is
a
workspace
support.
That's
coming
in
NPM,
b7
workspaces
are
incredibly
popular
in
large
projects.
Here
you
can
see,
create
react
app,
and
this
is
in
fact
the
create
react,
app
project
and
if
I
look
at
their
package.json,
they
have
to
find
workspaces,
and
you
can
look
in
the
packages
directory
to
see
that
and
now,
when
I
run
NPM
7
install,
it
will
actually
take
just
a
moment
because
there
are
in
fact
a
lot
of
packages
that
I
need
to
need
to
download
and
install
to
uncompress
into
the
node
modules
directory.
C
As
part
of
create
react,
it's
it's
a
pretty
big
project,
but
once
those
packages
do
get
downloaded
and
to
get
installed,
I
will
actually
be
able
to
look
inside
my
node
modules,
folder
and
you'll
see
exactly
how
workspaces
really
work.
So
once
that's
done
there
we
are
I,
can
look
inside
node
modules
and
there
are
a
bunch.
But
again
we
want
to
look
at
the
ones
that
align
with
our
packages
directory,
and
so
let's
look
for
react.
C
C
Sorry
I
want
to
prep
for
that
and
now
you
can
see
that,
instead
of
just
installing
it
as
if
it
were
a
normal
package,
it's
actually
created
a
symlink,
and
so
it's
actually
understood
the
workspace
support
and
able
to
hydrate
those
the
proper
way,
and
so
that's
something
I'm
really
excited
about
an
NPM,
seven
running
scripts
and
and
other
commands
in
a
specific
workspace.
It's
going
to
be
coming
soon,
but
this
is
just
amazing
progress
and
I'm
really
excited
about
what
the
team's
been
doing.
C
But
in
fact
both
products
will
continue
to
exist
and
we'll
continue
to
invest
in
both
of
them
and
honestly
they
both
have
very
different
use
cases.
First,
the
NPM
registry,
the
NPM
registry,
just-
must
stay
online
forever.
Those
of
you
who
remember
left
ad
we'll
remember
that
a
single
package
being
removed
from
NPM
had
devastating
effects
for
the
entire
JavaScript
ecosystem
for
JavaScript
developers
everywhere
now
imagine
every
JavaScript
package
disappears.
C
Imagine
that
every
time
you
run
NPM
installed
it,
it
can't
bring
in
your
dependencies.
That
would
just
be
an
absolute
unmitigated
disaster,
so
NPM
will
remain
online
forever
and
the
package
URLs
that
you
work
with
today
will
continue
to
work.
We
want
this
to
be
the
place
where
you
publish
packages
for
the
world
to
consume,
and
we've
been
spending
a
lot
of
time
lately
talking
to
package
authors,
maintainer
Xand,
publishers
about
what
it
is
that
they
want
in
NPM,
so
NPM
will
continue
to
exist
and
github
packages
will
also
continue
to
exist.
C
It's
a
different
system,
entirely.
Github
packages
supports
private
packages
that
you
can
share
just
within
your
organization,
and
so
this
is
really
helpful
when
you're
building
an
application
privately,
you
can
publish
your
dependencies
to
github
packages
and
then
use
them
in
the
build
tests
and
deployment
processes,
but
it's
also
useful
to
have
public
packages
and
github
packages
as
well.
If
you're
an
open
source
author,
you
can
imagine
publishing
every
build
into
github
packages
as
part
of
your
CI
process
and
that'll.
C
Let
you
flight
those
changes
before
you
actually
release
them
to
the
public
and
then,
as
part
of
your
release
process,
you
publish
the
release
package
up
to
NPM
itself
and
that's
when
you
give
it
to
actual
end
users,
so
for
NPM
we're
immediately
going
to
be
engaging
with
the
community.
The
NPM
CLI
already
has
a
great
RFC
process
that
guides
its
decision-making
and
its
new
features.
C
And
meanwhile,
we
started
talking
a
lot
more
to
package
authors,
publishers
and
maintainer
x'
about
how
we
can
improve
NPM
I've
spent
a
lot
of
time
listening
and
I
hope
to
spend
a
lot
more
in
the
coming
weeks
and
months,
and
while
we
do
that,
we're
spending
an
incredible
effort
on
the
registries
for
structure
right
now.
It
hosts
over
a
million
JavaScript
packages
that
can
almost
85
billion
downloads
a
month
and
we're
updating
the
infrastructure
to
get
it
ready
for
the
next
million
packages.
C
And,
of
course,
while
we
do
that,
we're
busy
working
on
NPM
v7,
which
I
hope
you
can
tell
I'm
super
excited
about
and
I
hope
that
you
are
too
looking
longer-term
we're
excited
about
how
we
can
integrate
NP
on
the
github,
for
example,
ninety-five
percent,
roughly
of
NPM
packages,
start
their
life
on
github.com.
That
means
that
we
can
provide
now
that
github
and
npm
are
joined.
We
can
provide
stronger
assurances
about
the
packages
that
you're
using.
C
Today,
NPM
has
several
paid
plans
for
private
package
hosting
and
we're
going
to
set
it
up
so
that
paying
NPM
customers
can
move
over
to
github
packages.
This
will
let
us
focus
each
of
the
repositories
on
what
it
does
best.
It
will
let
github
packages
be
a
great
solution
for
hosting
private
packages
and
let
NPM
continue
to
focus
on
being
a
great
public
registry
for
open
source
packages.
So
we're
really
excited
about
the
future
for
both
of
these
products
for
github
packages
and
for
NPM
and,
like
I,
said
earlier.
C
We're
really
interested
in
hearing
about
how
you
use
these
products
like
I,
said
I
love
to
learn
about
the
projects
that
you're
building
and
the
packages
that
you're
publishing.
So
if
you're
interested
in
participating
in
the
NPM
CLI
development
process
check
out
the
NPM
RFC's
there
at
github,
calm,
/,
NPM,
/r,
f,
CS,
and
if
you
want
to
follow
along,
but
you
aren't
quite
ready
to
participate
check
out
the
NPM
blog,
its
blog
NPM,
GS
org,
the
architect
of
the
NPM
CLI
Isaac
Slough,
we'll
have
some
really
great
blog
posts
about.
C
What's
coming
in
npm
b7
and
the
status
of
that
I'm
really
looking
forward
to
reading
those.
And,
of
course,
you
should
feel
free
to
reach
out
to
me,
I'm
otamatone
on
github
and
on
twitter,
but
right
now
I'm
gonna
go
back
and
join
Martin
and
Dana
and
I'll
be
happy
to
answer
your
questions
there.
So
thanks
so
much.
B
Well,
that's
brilliant!
It
thanks
very
much
that
was
really
enjoyed
that
one
yeah.
So
what
live
demos
for
start
yeah,
that's
fantastic
great
to
see
you
well
done!
That
was
a
took
a
lot
of
guts.
So
thank
you
everything
else
going
on
today.
So
that's
brilliant!
What
was
really
good
to
see
was
you
know
just
NPM
working
so
well
with
the
rest
of
the
JavaScript
community.
B
You
know
the
integration
with
yarn
was
amazing
to
see
and
actually
seen
it
working
live,
so
yeah
really
excited
about
what
Isaac's
and
the
team
are
doing
with
NPM
v7,
that's
fantastic!
The
scale
as
well.
The
you
know,
it's
just
insane.
The
scale
in
PM's
I
thought
github
is
big,
an
area
not
soup
as
well.
It's
insane
so
anyway,
and
but
before
we
go
into
Q&A
and
things
and
hear
Danis
be
back
and
just
wanna,
you
know
Dana,
you
might
notice
from
Dana
she's.
Just
like
tattoos.
B
C
C
A
Know
why
it's
okay,
because
you're
my
spirit,
brother,
head
you're,
my
spirit
brother,
we're
digital
nerds
living
in
a
digital
word,
but
we're
analog
first
in
all
ways,
so
you
know
what
I'll
take
it.
You
know
I
actually
listen
to
rush
on
cassette
last
night,
because
that's
what
a
nerd
I
am
yeah
double
cassette
to
wind
down.
Oh.
C
A
Pme3
7sl,
let
the
audit
functionality
that
you
showed
us
I'm
gonna,
tell
you
what
I
think
it's
a
game!
Changer!
You
know
for
people
with
a
attention
span
of
a
goldfish
like
myself,
I
love
the
crisp
way
that
you
can
just
go,
find
the
information
that
you
need.
It's
gonna
be
a
huge
time-saver,
but
we
got
some
questions
coming
in
remember
right
now
you
can
go
on
to
get
up
satellite
comm,
slash
discussions
and
ask
Edie
or
Martin
or
myself.
You
know.
What's
more
Tom
Sawyer
I'll
bring
it,
but.
A
C
That's
a
great
question:
I'm,
actually
a
big
fan
of
wasm
or
waz
I'm.
However,
you
pronounce
it,
you
know.
That's
that's
not
been
top
of
mind
for
me,
but
I
will
definitely
take
that
to
the
team.
I
can
imagine
some
ways
that
you
know
you
could
you
could
better
package
wisdom
and
especially
you
know,
go
with
that.
So
yeah,
that's
a
that's
a
great
question
and
I'm
definitely
follow
up.
B
Cool
so
yeah
I
mean
there's
been
quite
a
few
questions
in
the
discussions
and
remember
if
you
want
to
join
in
the
questions,
answers
just
click
on
the
discussions
button
or
if
you
go
on
over
to
Gil,
observe
like
on
lactis
questions,
you
can
answer
Q&A,
but
one
of
the
biggest
sort
of
threads
I
was
seeing
was
around.
You
know
why
get
her
back
wired,
MPM
people
asking
about
that
and
probably
logan
Volkers
is
got
a
good
question
here.
B
C
C
A
We
agree,
we
agree.
We
think
that
github
is
like
github,
an
NPM
to
me,
our
beer
and
burritos
or
tacos
and
tequila
we're
all
the
other
amazing
combinations
like
I
can
tell
we're
getting
close
to
lunch,
because
that
is
where
my
brain
is
that
and
I
heard
the
edit
hanging
out
there
in
London,
so
go
on
to
github
at
Twitter
and
tell
ed
where
he
can
get
some
good
tacos
and
burritos
and.
A
B
No,
no
during
the
log
down
knowing
Cambridge,
definitely
not
good
Funko's
anyway,
unless
you've
made
them
yourself,
not
in
Cambridge,
where
I
live
so
yeah
anyway.
That's
well,
we
should
probably,
which
probably
mean
I,
don't
know
if
we've
got
time
for
one
more
question,
maybe
actually
yeah
well
we're
on
the
oddest
of
Bois
Bogdan.
Her
van
was
saying
around
there
not
super
familiar
with
the
NPM
ecosystem.
But
how
does
that
audit?
So
you
were
talking
about
how
does
that
help
him
if
the
packages
include
included
directly
reference
or
the
packages
with
vulnerabilities
right.
C
So
NPM
audit
actually
works
by
looking
at
the
entire
dependency
graph
of
your
of
your
project.
So
if
you
depend
on
a
project,
a
package
like
make
therapy
make
therapy
is
just
a
really
simple,
useful
utility
that
makes
ders,
but
it
depends
on
on
other
things
and
make
the
repeat
itself
doesn't
necessarily
have
a
vulnerability,
but
the
packages
it
depends
on
does
so.
Npm
audit
can
actually
take
a
look
at
that
entire
graph
and
just
spider.
Everything
and
look
at
all
of
the
packages
that
you're
using
it
can
compare
that
to
a
list
of
CVEs.
C
A
CVE
is
a
common
vulnerability
and
exposure.
That's
a
you
know,
really
technical
name
for
a
security
hole,
and
so
it
can
actually
understand
exactly
the
packages
that
you're
using
that
have
those
security
holes,
even
if
you're
not
depending
on
them
directly.
It
can.
You
know,
walk
that
entire
graph,
and
so
it's
very
useful
to
understand
precisely
the
problems
that
you
might
inherit
in
your
codebase,
even
though
you
didn't
write
them
and
you're,
not
even
depending
on
them
directly
you're
just
pulling
them
in
you
know,
through
a
second
or
third
level,
got.
B
It
that's
fantastic
thanks,
ed,
so
again,
thank
you
very
much,
Pete
I'm.
Thanks
to
that
great
session,
ed
will
be
joining
us
in
the
Q&A
and
the
discussions
for
the
next
30
minutes
so
head
on
over
there
and
the
team.
The
NPM
team
will
also
be
in
there
in
the
Q&A
as
well.
So
please
go
along
and
see
what
you
see
what
you
want
to
talk
about,
but
with
that
ed,
we'll
wrap
up
you.
So
thank
you
very
much
for
your
time
and
yes,
mediator.