►
From YouTube: 2021-07-12-Next 10 years of Node.js
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
Right,
so
let
me
go
back
to
the
minute,
so
this
is
where
the
minutes
were
from
the
last
time.
So
I
you
know,
I
see
version
management
was
one
of
the
things
that
was
highlighted
so.
C
A
Discussed
that
I
think
the
comment
here
was
like,
should
we
at
least
add
it
to
the
docs
yeah?
I
don't
know
so
I
mean
did
you
want
to?
Did
you
want
to
discuss
a
little
bit
that
I'm
happy
to
sort
of
say,
let's,
let's
start
around
there,
and
we
can
start
by
talking
a
little
bit
about
that
too.
B
I
mean
I,
I
definitely
think
that
version
management
should,
like
you
know,
having
a
version
management
binary
in
the
project,
should
be
a
thing
that
we
we
do,
and
I
know
that
there
was
interest
from
people,
including,
like
the
volta
people,
to
do
that,
like
literally
just
to
do
that,
so
I
don't
know
I
I
think
that
we
should
do
something
along
those
lines
and
vm.
I
love
nvm.
I
use
nvm
personally,
it
also
doesn't
work
on
windows,
so
I
don't
think
it's.
A
B
Go
ahead,
I
I.
I
think
that
having
nvm
is
a
or
sorry
a
version
manager
as
a
part
of
the
project
and
that's
something
that
ships
with
core
is
something
we
should
do.
B
A
B
Because
this
was
actually
something
that
came
up
in
the
comca
meeting,
which
was
like
there's
when
we
were
talking
about
the
notice.dev
documentation,
because
there
was
a
problem
in
that,
I
don't
think
anyone
in
node
who
uses
node
day-to-day
will
be
using
the
like
official
binaries.
We
provide
from
nodejs.org
download
like
it's,
not
a
thing.
People
use,
I
mean
people
do
use
it,
but
not
like
they
probably
shouldn't
be
using
it,
and
most
people
who
have
be
passed,
intermediate
or
sorry
beginner
users
will
not
be
using
it.
B
B
But
yeah
I
don't
know
it's,
I
I
think
that
that's
we
should
ship
some
kind
of
version
manager
with
no
it's
not.
It
reflects
how
people
use
the
the
project
and
it
I
think
it's
it's
a
miss
on
our
part,
not
to
do
that.
A
Okay,
yeah
there
we
go
joe,
we
couldn't
promote
joe
because
he's
logged
in
as
the
node
user.
So
I
was
just
telling
him
that,
but
he
also
just
saw
it
so
once
he
comes
back,
we
should
be
able
to
promote
okay.
So
I
think
that's
the
note
I
can
take
that
we
should
add,
like
version
management
as
one
of
the
the
needs
of
the
constituencies
which
makes
sense
to
me
under
our
list,
we've
got
users,
ops,
app
dev,
lib,
dev,
orgs
and
node
maintenance.
I
kind
of
see
that
more
under
users,
appdev
libdev.
B
I
think
it's
useful
in
ci,
but
like
in
you
know
like
a
lot
of
like
jenkins
and
stuff
or
not
jackets.
Travis
use
nvm
directly.
B
It
is,
it
is
built
into
drink,
like
travis
as
a
production
product
right.
Like
that,
the
feature
it
is
the
tool
that
they've
used
to
implement
the
version.
Switching
and
now,
if
it's
global,
I
don't
think
so,
but
like
there
are
products
that
are
built
with
it
in
that
way,.
B
The
one
thing
I
will
say
there
is
that
I
believe
a
lot
of
platforms
like
at
least
I
know
azure
does
and
I'm
pretty
sure,
gcp
and
aws
do
this
too.
They
will
take
you
there.
There
are
certain
products
that
will
take
a
nvm
version
from
like
the
nvmrc,
as
your
like
for
the
infrastructures
and
service
things
like
the
heroku,
like
services,.
C
B
They'll
take
a
version
from
nvmrc.
If
that's
provided.
A
A
A
Okay,
let
me
flip
back
to
here
so
okay,
so
we
were
at.
A
The
next
one
was
a
bundle,
bundled
linterin
core.
So
I
guess
that's
that's
something.
I
know
that's
been
discussed
back
and
forth
as
well.
In
some
ways
it's
interesting,
I'm
just
gonna.
Look
that
might
have
been
what
led
to.
A
Or
sorry
I
was
looking
at
the
the
minutes
from
the
last
time
if
I
can
find
it
but
or
right
here
yeah,
so
we
want
to
be
able
to
think
less
about
what
we're
pulling
in
yeah.
So
maybe
not
so
maybe
that's
kind
of
like
I
guess
that's
leading
into
again
like
what
things
are
are
useful.
You
know
to
have
built-in
versus
not
built
in.
B
B
I
think
that
I
struggle
with
that
one
because
it
chooses
a
winner
in
the
ecosystem,
because
I
don't
think
we
want
to
write
our
own.
A
And
it
is
pretty
easy
to
get
a
linter
in
your
you
know:
it's
not
a
it's
not,
and
the
linter
won't
work
better
in
core
either.
I
guess.
B
Right,
yeah
there's
nothing
that
that'll
directly
benefit.
Oh,
like
the
the
direct
benefit
of
having
a
lintering
core.
Is
you
have
it
and
you
don't
have
to
npm
install
it,
which
is
just
like
we're
installing
it
or
like
whatever
yarn,
whatever
you're
you're
we're
just
doing
it
for
you,
which
I
I
don't.
I
don't
necessarily
think
that's
a
good
design
design.
C
It's
more
than
that,
if
we
ship
a
linter,
we
would
have
a
set
of
default
rules
applied
that
that,
I
think,
is
more
valuable
than
the
npm
install
say,
yeah
having
a
default
set
of
reasonable
rules.
Probably
not
all
the
rules
in
the
world
would
probably
at
least
help
people
write
common
codebase
styles.
C
C
B
C
I'm
not
saying
you
can't
have
more
rules,
I'm
stating
that
not
having
framing
it
as
though
you
never
join
a
new
project
that
has
new
rules
is
weird.
That's
not
what
I'm
saying
well
you're
saying
that
whenever
you
start
something
new,
whether
you're
a
beginner
or
starting
on
a
new
team,
you
have
to
adjust
for
whatever
the
lint
rules
are.
C
My
presumption
is
that
that
would
happen
organically.
I'm
not
saying
you
should
enforce
that.
They
must
only
have
ours.
A
B
Gosh
you
I
I
wasn't
getting
the
they
will
build
off
ours,
so
there
will
be
less
churn
or
the
there
will
be
17
people
that
are
so
they'll
be
lesser
yeah
I
mean
I
guess.
The
thing
I
was
getting
at
was
that,
like
the
the
people
who,
I
think
are
most
likely
to
use
the
default
rule
set
without
changes
will
be
someone
who
is
completely
new
to
javascript
or
node
and
or
building
a
project
with
them
from
scratch
and
would
default
to
that,
which
I
don't
know
like.
A
I
think
that
that's
an
interesting
one-
maybe
we
we
don't
want
to
spend
too
too
much
time
right
now.
We
can
sort
of
note
it
as
something
somebody
mentioned.
I
I
personally
think
we'd
have
a
hard
time.
Agreeing
on
one
set
seems
to
be
things.
People
are
fairly
have
strong
opinions
and
even
within
teams,
it
seems
to
be
hard
to
choose
the
the
one.
The
only
one
versus
like
several
profiles
but
yeah.
A
But
unless
somebody
is
like
hey,
we
have
you
know,
let
that's
that's
a
need
that
we
need
to
have
in
the
constituency
list.
I
think
it's
kind
of
like
it's
an
interesting
technical
thing
that
we
can
include
in
the
technical
brainstorm,
but
I'm
not
sure
it's
a
like
something
to
put
into
the
needs
of
the
constituencies,
necessarily
as
its
own
thing.
A
C
B
I
mean,
I
also
think
that
part
of
the
part
of
the
issue
with
docs
is
just
that
they're,
pretty
inconsistent
and
honestly
pretty
thick
like
they're
they're
reference
stocks
and
not
usage
docs
like
they're,
not
like
particularly
friendly,
like
I
I
I
was
talking
with
this
about
this
with
with
suez
hinton
like
a
year
or
two
ago
like
just
before
covid,
and
I
guess
a
year
ago
and
like
sus,
I
assume
most
of
y'all,
know
her
or
know
of
her
she's
very,
very
good
at
node
knows.
B
The
ego
stem
gave
me
permission
to
share
this,
that,
like
she,
can't
use
the
no
docs
they're
just
completely
useless
to
her
because
of
how
thick
and
and
inconsistent
they
are,
and
that's
I
bring
that
up
because
that's
a
experience.
I've
had
and
many
others
have
expressed
over
the
years
like
this-
is
something
this
is
feedback
that
we've
constantly
gotten.
A
I
think
this
just
really
confirms
the
consumable
apis
and
docs
right
and
we've
heard
it
a
number
of
times.
Docs
are
something
that
that
would
like
people
would
like
to
see
better
versions
of
so
we
could
spend
a
lot
of
time,
but
I
think
I
think
that's
one.
We
already
kind
of
know
it's
like
yeah
docs,
many
many
people
have
commented.
Docs
could
be
improved,
we've
got
it
in
the
list.
So
from
this
perspective,
I
think
we've
covered
it
from
the
yeah.
We
know
that's
important.
A
A
You
know
it's,
it's
not
necessarily
something
I
would
call
it
the
need.
Specifically
it's
more
like
on
the
technical
side.
It
falls
into
one
of
those
other
categories.
We
have
optional
central
package,
cache
to
reduce
disk
usage.
A
That
one,
I
guess,
is
yeah
it's
optional
for
sure
like.
If
you
want
to
share
your
packages
or
not,
and
I
guess
we
need
to
understand
a
little
bit
more
like
how
does
that
differ
from
like
installing
globally
versus.
A
C
So,
there's
a
difference
actually
from
way
back
in
yesteryear,
so
there
was
home
directory
dot,
node,
underscore
libraries
that
is
different
from
global
installs
right,
okay,
so
a
global
install
when
you
install
something
globally,
it
generally
like,
doesn't
change
it's
fairly
safe.
C
If
you
upgrade
one
thing,
it
won't
destroy
another
global
install
with
the
shared
cache
that
that
isn't
really
true.
If
they
are
transitively
updating
across
things,
there
are
different
ways
to
work
around
this
like
pnpm
does
what
dino
is
doing
is
basically
the
same
idea.
You
install
something
to
a
well-known
directory.
It
is
shared
across
multiple
working
directories.
C
They
don't
quite
have
the
same
module
infrastructure
as
we
do
my
main
concern
with
stuff
like
this.
Is
we
already
have
tools
doing
this
with
pnpm
to
some
extent
yarn
too
and
barry?
C
A
C
C
A
B
A
A
Module,
maybe
it's
covered
by
module
dependency
info
and
management.
Let's
see.
A
A
B
I
mean
honestly,
this
is
kind
of
what
I'd
envisioned
examples,
as
is
a
way
to
do
that
right
now,
we're
slowed
by
github
and
platform
issues
with
actions
that
I
need
to
basically
go
rewrite
the
whole
thing
but
yeah.
I
think
that
this
is
oh
I'll.
I
will
also
say,
since
this
is
on
stream,
I
don't
think
php
sucks
php
is
a
good
tool
and
I
I
don't
think
that
that
is
particularly
warranted,
but
I
I
think,
yeah.
B
I
think
that
there's
I
I
like
this.
I
think
it's
it's
also
covered
by
the
better
documentation.
A
A
B
Yeah,
that's,
like
you
know
everyone's
gonna
end
up
using
uuid
at
some
point
right
for
something
somewhere.
If
you're
writing
good
stuff,
it
should
probably
be
in
core.
Like
I,
I
get
that.
C
B
At
this
point,
geez
I've
been
away
for
a
while
in
certified
modules
where
they're
basically
saying
like
this
is
the
thing
you
need
to
to
do
or
like
this
is
the
thing
everyone
uses,
or
this
is
the
this-
is
a
a
good
one,
providing
some
kind
of
verification
that,
like
our
validation,
external
validation
for
people,
saying
hey,
this
is
like
you
know
something
the
node
project
would
recommend,
or
something
like
that
is,
I
think,
a
useful
tool,
but
yeah.
A
Confidence
and
security
widely
used
it's
it's
kind
of
the
thought
of,
like
I
mean,
as
I'm
thinking
like
as
a
constituency,
need
it's
like
a
solid
base.
A
It's
something
something
along
those
lines.
I
don't
know,
if
that's
something
we
should
add
as
one
of
the
cons
as
one
of
the
the
needs,
the
constituencies
like
you
know
it
would
it
make.
You
know
you
have
all
the
modules
that
are
out
there
and
I
don't
know
if
we
can
say
that
hey
they
need
people
need
everything
to
be
trusted,
but
they
may
need
some
subset,
like
some
core
subset
to
be
trusted
or
to
be
like
have
better
confidence
or
something
like
that.
C
So
we
actually
encourage
people
to
leave
it
in
the
ecosystem,
but
we
don't
really
give
any
support
after
that.
So
we're
both
like
at
this
situation,
where
we
want
people
to
read
up
and
use
outside
modules.
We
don't
want
to
put
them
in
core,
but
we
we
do
want
them
to
like
use
them
just
for
basic
everyday
usage
like
node
certification,
and
I
think
we
should
look
at
some
kind
of
support,
even
if
it's
just
like
a
rubber
stamp
that
this
is
being
watched
in
some
way.
Yeah
yeah.
C
B
Yeah
I
mean
that
was
the
the
use
case,
for
that,
when
you
know
certified
modules
was
the
thing
was
a
lot
of
a
lot
of
a
lot
of
people,
don't
necessarily
know
what
the
best
thing
is
or
what
to
pick.
B
And,
like
I'm
sure,
all
of
us
here
could
find,
like
you
know,
find
reasons
to
pick
one
thing
over
the
other
have
our
own
preferences,
but
like
there
are
generally
like
community
selected
solutions,
like
you
know,
es
lent
is
a
good
example
like,
regardless
of
whether
you
standard
or
airbnb
style,
guide
or
whatever,
like
you're
gonna,
be
using
eslint
somehow,
and
so
like
someone
outside
of
the
ecosystem,
someone
like
a
java
developer
who's
having
to
like
start
learning,
note,
isn't
going
to
know
that.
A
C
A
A
C
We
do
have
an
open
issue
on
next
10
about
making
a
formal
security
model
right
reminded
the
other
day
that
this
group
can't
make
it,
though,
so.
A
Right,
it's
yeah,
I
mean
the
then.
When
we
get
to
the
technical
side,
this
group
won't
necessarily
be
building
any
of
that,
where
it'd
be
more
just
trying
to
get
consensus
on
these
things
are
important,
and
that
could
be
part
of
the
like
you
know
under
the
think.
Would
that
fall
under
here
could
see
his
security
and
cv
practices
in
the
project.
C
I
think
it's
under
security,
not
cve
itself.
The
model
itself
is
going
to
determine
what's
in
scope
and
what
is
required
in
order
to
obtain
your
model.
Cves
could
be
determined
to
be
out
of
scope
if
we
have
a
model.
C
A
C
C
So,
like
the
car
are
off-the-shelf
sandboxing,
but
in
general,
if
you
do
real,
full-fledged
sandboxing,
you
want
multi-process
architecture.
A
C
A
A
I
think
that
we
can
cover
through
sort
of
enhancing
that
section
we
had
on
on
package
management
as
one
of
the
needs
we're
going
to
talk
a
little
bit
more
about
like
common.
A
C
A
A
roadmap,
but
I
think
sharing
of
information
and
so
forth,
is
definitely
a
need.
C
A
A
Relevant
apis
and
cores,
I
think
where
we
would
cover
that,
so
it's
more
than
on
the
technical
side
to
say:
okay,
let's
figure
out
individually.
What
are
the
the
key
apis
and
like
is
it
is?
It
knows
one
of
our
technical
things
we
think
is
important,
is
integrating
more
with
the
web
api
than
we
are
already.
C
So
there
are
a
few
existing
stuff
with
the
node
and
better
api.
This
is
more
practical
these
days
than
it
once
was.
The
big
thing
here
is,
I
do
think
it's
a
need,
because
if
you
are
a
non-uh
sre,
basically
deploying
out
node,
things
takes
a
lot
of
your
time
in
your
job.
If
you're
forced
to
do
it,
there
are
some
things
you
can
do
like
doc,
pair
images
and
stuff
like
that
to
avoid
some
of
it,
but
you
still
spend
a
lot
of
time.
C
You
know
managing
distribution
compared
to
some
environments,
where
you
basically
drop
a
single
file
on
disk.
C
Yeah
so
and
anna
made
a
box
node,
which
is
probably
the
first
bundler
and
distributable
that
uses
the
embedder
api.
Maybe
we
could
just
talk
to
her
about
it.
A
A
Right
because
of
the
like,
the
native
modules
right.
A
A
B
Rather
than
like
diagnostics,.
C
It's
built
in,
but
there's
a
cost
to
go
over
the
marshalling
between
mode
and
vm
code
and
the
only
thing
we
can
do
faster.
There
is
there's
a
thing
called
fast
function
calls
in
v8,
which
is
experimental,
and
we
can
just
wait
on
that
they're.
A
lot
faster,
though.
A
A
A
C
So
I
would
say:
managing
concurrency
isn't
my
main
problem
having
written
a
decent
amount
of
web.
It's
actually
getting.
Data
between
threads
is
is
a
real
pain.
A
B
I
think
the
more
interesting
one
there
is
compile
the
executable
I'd
love
to
see
us
do
this.
I
don't
know
if
it's
it
will
do.
A
A
A
Take
leadership
and
package
managers
and
builder
bundlers
to
have
one
standard,
not
new
one.
Every
year
like
in
many
other
programming
languages,
I
think
we've
kind
of
covered
the
need
there
of,
like
you
know
we're
going
to
expand
the
the
package
manage
the,
but
the
thing
we
had
on
module
management
to
basically
say
it's
there's
definitely
a
need
to
have
a
package
manager
we
don't
need
to
get
into
like.
This
is
a
need,
not
the
solution
which
could
be
one
standard
or
multiple
together
or
whatever.
C
That's
go
ahead,
I
would
say
we
have
done
fairly
well
in
that
arena
these
days,
the
cost
of
compatibility.
A
A
I
think
that
kind
of
comes
is
covered
in
relevant
apis
right.
Are
you
but
it's
interesting
sorry,
just
getting
back
to
the
high
performance,
so
I
think
we've
covered
that
and
more
batteries
included.
So
I
think
that's
we
did
touch
on
adding
one
which
is
sort
of
that
sort
of
standard.
A
Okay,
so
I
think
we
have
having
gone
through
there.
We
have
a
few
suggestions
of
things
we
we
should
add
in
terms
of
the
like
the
needs
and
oop
wait
a
sec.
Maybe
I
forgot
no,
that
was
for
a
different
question.
Okay,
so
yeah
we've
gone
through,
we
can.
We
can
do
that
through
a
pr,
and
I
think
that
would
then
close
out
our
sort
of
review
of
the
feedback
we
did.
A
We
did
plan
to
want
to
work
on
a
blog
post
to
kind
of
summarize
the
the
information
we
pulled
out
of
that
so
I'll
probably
open
an
issue
to
do
that,
and
if
people
want
to
help
out
that
would
be
good.
Just
for
anybody
who
wasn't
here
at
the
beginning,
we
did
talk
a
little
bit.
There's
the
proposal
for
a.
A
I
can
get
there
a
mini
summit,
so
we
can
get
through.
You
know
a
few
of
the
things
we've
had
on
our
on
our
agenda
august
5th.
A
It
sounds
like
from
the
look
of
it
there's
quite
a
few
people
who
can
make
it
so
I
I'm
not
sure
everybody
who's
here
has
responded,
but
if
you
want
to
take
a
look
there,
that's
looking
like
the
date
I'll
I'll,
probably
try
and
schedule
for
that,
and
you
know
I
think
that'll
be
good
to
get
us
to
get
through
a
bit
more
stuff,
but
otherwise
I'll
say
thanks
to
everybody
who
made
it
today
and
for
helping
us
go
through
this
look
for
some
prs
in
terms
of
like
some
additions
to
the
the
constituencies
and
one
to
work
on
the
blog
post
and
we'll
see
everybody
in
github
and
in
the
next
meeting.