►
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
Okay,
so
we're
live
for
the
node.js
technical
steering
committee
meeting
for
august
27
2020
we'll
be
following
the
agenda
as
posted
in
the
issue
in
the
tse
repository,
except
that
we
may
handle
things
a
little
bit
out
of
worse
since
we
have
a
guest
for
one
of
the
issues
before
we
get
started
on
the
tagged
issues.
Does
anybody
have
any
announcements
that
they'd
like
to.
A
A
Nobody
else
has
the
announcements.
I
would
I'll
mention
one
that
as
we
probably
let
you
know
in
one
of
the
earlier
ones.
The
second
director
representative
vote
was
open.
For
the
last
week
we
had
a
number
of
good
candidates
and
I
was
re-elected
as
the
the
not
re-elected
but
actually
elected,
as
as
the
second
director
representative,
which
last
year
was
the
node
representative,
but
I'll
still
be
acting
in
that
in
that
role.
A
A
So,
let's
move
on
to
the
tagged
issues,
the
first
one
that
we
have
agreed
to
get
started
on
is
the
issue
number
904
in
the
tc
repo,
which
is
the
package
manager
manager,
discussion
and
I
think
james.
You
were
the
one
who
put
that
on
the
agenda
and
we
have
mail
who's
going
to
help.
Take
us
through
that
as
well.
So
I'm
not
sure
how
you
want
to
kick
that
one
off
james.
B
C
Sure
so,
for
a
bit
of
context,
I've
been
working
on
yarn
since
2017,
so
a
bit
more
than
three
years
now
and
one
of
the
problems
that
we've
had
for
all
this
time,
where
people
that
were
mentioning
to
us,
I'm
using
this
package
manager,
because
it's
by
default
or
not
so
it's
difficult
to
use
anything
else
really,
and
that
was
something
that
we
couldn't
really
influence.
So
that
was
a
bit
frustrating
for
us.
C
As
you
can
imagine,
and
over
time
it
actually
became
a
problem,
because
something
that
we
don't
often
realize
is
that
package
managers
are
not
really
up
to
users
to
choose.
They
are
up
to
projects.
C
So,
for
example,
I
contribute
to
a
lot
of
of
projects
on
data,
and
some
of
them
are
configured
to
use
yarn,
and
in
this
case
I
just
use
yarn
in
order
to
install
dependencies
and
just
do
whatever
I
want,
but
some
others
are
also
using
npm
and
in
this
case,
as
a
user
as
a
contributor,
I
cannot
just
say
no.
I
want
to
use
yarn
because
the
to
the
the
choice
of
package
manager
from
which
a
project
has
been
configured
has
been
made
by
the
lead
maintainer
of
the
project.
C
So
if
I
use
yarn,
I
will
have
some
very
slightly
different
behaviors
that
mean
that
I
will
not
be
able
to
contribute
efficiently
to
the
product
and,
conversely,
if
a
project
is
configured
to
use
yarn,
then
using
npm
will
lead
to
slightly
different
behaviors,
slightly
different
feature
set,
and
it
means
that
it
will
be
a
subpar
experience
to
contribute
on
the
product.
So
what
I
mean
by
that
is
that
the
question
is
not
which
package
manager
is
the
best.
That's
a
question
that
no
one
really
needs
to
to
ask.
C
So
a
few
months
ago
I
tried
to
start
an
experiment
called
the
pmm
for
package
manager
manager,
and
I
wanted
to
show
a
bit
how
it
works
and
how
I
think
it
could
solve
a
bit
this
problem.
So
if
that's
fine,
I
will
share
my
screen
to
make
a
quick
demonstration.
C
Yes,
okay,
cool!
So
I
have
this
install
source,
node
added,
so
I've
built
a
version
of
node
from
the
trunk
that
contains
this
tool
that
I'll
call
a
pnm.
I
will
quickly
show
how
it's
done,
but
the
pr
is
very
small.
C
Basically,
the
id
is
that
in
this
version
of
node
it
ships
with
a
few
extra
binaries
inside
the
bin
folder,
so
you
can
see
one
from
for
pnpm,
pmpx,
yarn
and
yarn
pkg
and
the
exact
same
npm
as
usual
are
used
so
for
now
this
only
affects
yarn
and
pnpm,
and
something
interesting
is
that
let's
say
that
I'm
in
a
temporary
folder-
and
I
just
want
to
use
a
npm
init
and
things
will
work
as
you
would
expect.
C
A
new
npm
project
is
created,
but
now
let's
say
that
I
want
to
create
a
yarn
project
here
when
you
will
run
young.
So
if
I
make
a
vision,
it
goes
into
the
yarn
that
is
shipped
with
with
not,
except
that
it's
not
the
real
yarn.
It
goes
into
a
wrapper
that
will
see
that
there
is
no
package
manager
configured
for
the
current
product
and
when
it
detects
this,
it
will
ask
the
user.
Do
you
want
to
use
yarn
inside
this
project?
C
Do
you
want
to
set
it
to
yawn,
1.22.4
and
the
user
can
just
say
yes
and
then
it
will
download
the
the
1.22.4
release
inside
a
folder
on
the
user
home
folder
and
make
it
available
for
use.
So,
for
example,
here
if
I
go
into
the
packet
that
doesn't
here,
I
will
see
that
my
package
manager
has
been
configured
to
you
to
be
a
young
1.22.4.
C
Something
interesting
is
that
a
lot
of
people
have
this
wrong
assumption
that
they
can
use
a
package
manager
instead
of
another,
and
things
will
probably
just
work
and
that's
inexact
because,
as
I
mentioned,
package
manager
often
have
very
slightly
different
behaviors
in
various
places.
So
using
one
side
of
the
other
doesn't
work
with
a
pmm.
C
What
happens
is
that
if
we,
for
example,
if
I
try
to
run
pnm
pnpm,
install
pmm
will
catch
the
call
and
will
tell
that
the
current
project
has
been
configured
to
use
yarn
and
the
same
would
happen
if
let's
say
that,
I'm
creating
a
new
project
here.
C
Here
I
try
to
run
a
pmpm,
so
I
can
emit
it.
It
downloads
it
on
demand.
Then
it
runs
it
and
after
that,
if
I
try
to
use
yarn
it's
the
same
thing,
it
will
tell
me
that
this
project
is
configured
to
use
pnpm,
so
the
users
cannot
just
use
the
wrong
packet
manager
by
mistake
because
yeah
they
will
be
prevented
to
do
so.
C
C
So
I'm
on
five,
five,
three,
but
now
inside
the
packet
that
json.
Let's
say
that
I
want
to
actually
use
five
four
eleven
and
now
I
run
pnpm
version
and
this
time
pm
will
detect
that
the
version
is
not
the
same
and
it
will
transparently
download
and
set
up
a
pnp
m5411
to
be
used,
and
that's
also
critical,
because
one
of
the
things
that
we
noticed
inside
yarn
was
that
one
of
our
best
features
was
this
yarn
path
configuration
setting
which
allow
a
user
to
define
the
path
where
the
yarn
version
is
located.
C
By
doing
this,
they
were
able
to
store
the
yarn
version
directly
inside
the
repository
so
that
everyone
inside
their
organization
was
always
unsure
that
they
were
using
the
exact
same
yarn
binary,
and
that
was
critical
because,
for
example,
let's
say
that
we
wanted
to
make
an
update.
We
just
needed
to
update
this
one
file
and
people
were
able
to
upgrade
transparently
just
by
pulling
from
the
trunk
and
by
sorry,
and
this
workflow
is
exactly
the
same
thing
with
pmm.
Since
the
package
manager
version
is
stored
inside
the
package.json.
C
C
I
made
a
pmm,
so
it's
a
completely
open
source
inside
the
the
arcanist
pmm
repository
and
I've
detailed
a
bit
the
exact
workflow.
There
are
various
ways
to
build
the
project
to
build
the
project
to
try
it
yourself.
C
There
is
a
configuration
file
so
that
each
package
manager
is
accounted
for.
Adding
a
new
one
means
updating
these
configuration
file,
which
would
be
embedded
within
the
version
of
pmm
inside
each
node
release
by
default.
If
no
package
manager
is
mentioned.
C
For
example,
let's
say
that
I
remove
the
pnpm
field
here
I
can
run
all
package
manager,
except
that
the
version
that
will
be
used
will
be
the
one
that
will
be
configured
by
default
inside
the
manifest
so
yeah
and
finally,
as
for
the
implementation
inside
node
itself,
it
really
only
takes
modifying
the
tools
install.py
file
in
order
to
add
the
new
shames
to
yarn
the
onpkg
pnpm
and
pnpx,
which
can
be
factored
with
npm
and
npx.
C
So
it's
not
a
large
work
in
term
of
technical
challenges,
it's
mostly
more
it's
mostly
in
terms
of
workflows.
C
I
think
I've
shown
most
of
the
tools.
So
if
you
have
any
feedback.
B
You
questions
just.
I
just
wanted
to
make
sure
it's
clear
so
regards
to
npm
this
also
installs,
the
npm
client.
So
instead
of
shipping,
the
npm
client
with
the
node
distribution,
we
ship
pmm
instead
and
then
npm
is
downloaded
the
first
time
you
use
it.
Yeah.
C
So
the
the
npm
case
is
really
entirely
up
to
you,
the
ideally.
Yes,
that
would
be
the
case,
so
npm,
yarn
and
pm
would
all
be
part
of
the
same
rubber
pmm,
but
if
you
prefer
to
keep
using
to
keep
distributing
npm
by
embedding
inside
your
distributions,
I
mean
that's
fine
by
me.
That's
really
just
the
only
difference
between
integrating
npm
inside
kmm
or
not
so
there
will
be
two.
The
first
one
is
that
npn
will
not
be
inside
the
release,
so
it
might
break
a
few
things
for
your
users.
C
A
C
Check,
for
example,
if
I
do
reach
on
yawn
it
goes
into
this
file
and.
C
Which
is
a
sim
link
to
leave
now
models
pmm,
disk,
yonder
gs,
and
if
I
open
this
file,
it
is
calling
the
pmm
rubber
for
with
the
argument's
yarn
yarn,
which
allows
it
to
detect
that
he
needs
to
download
the
package
manager
yarn
and
run
it
with
the
binary
yarn.
So
if
we
go,
for
example,
in
plp
x,
it's
the
same
thing,
except
that
it
calls
the
package
manager
pnpm
with
the
binary
pmpx.
D
E
Just
something
in
general,
this
concern
seems
well
to
me,
and
I
have
observed
similar
things
like
projects,
data
bounds
to
specific
package
managers
and
they
basically
limit
their
ability
to
choose
a
package
manager
by
the
user.
And,
moreover,
this
idea
of
adding
an
installer
for
those
property
managers
seems
very
good
to
me,
but
I
have
some
concerns
about
the
details.
E
One
of
them
is
that
we
probably
shouldn't
download
anything
without
user
confirmation,
and
the
second
one
is
that
the
format
looks
a
bit
strange
in
the
engines
and
because,
for
example,
now
someone
couldn't
specify
a
yarn
version
inside
the
engine's
field
and
with
this
format
they
could
specify
yarn
version
in
two
places
in
the
jeans
fields
like
in
the
pm
and
in
yarn.
So
I
think
that
probably
this
perhaps
this
should
be
a
separate
package.
E
Json
field
that
releases
acceptable
package
managers
to
use
with
this
project
and
engines
should
specify
the
ratios
for
those
package
managers.
C
Yeah,
I'm
not
fixed
on
energize.pm,
so
if
something
else
is
more
suitable
and
entirely
fine
with
it,
it
was
really
just
same
thing.
The
name
of
the
project,
pmm,
is
really
just
don't
replace,
holder
and
feel
something
else.
E
It
will
be
possible
to
specify
your
version
two
ways:
one
inside
engines.pm
and
one
inside
engines
that
yarn.
E
Sorry
watch
if
someone
specifies
that
yarn
or
npm
could
be
used.
C
No,
you
cannot
do
this.
Jan
and
npm
have
a
lot
of
differences,
especially
when
you
work
on
them.
You
start
to
see
that
and,
for
example,
just
for
one
simple
thing:
npm
currently
doesn't
support
workspaces.
They
might
eventually
support
them,
but
the
implementation
may
be
slightly
different
and
the
feature
set
will
be
also
different.
So
using
a
yarn
or
npm
has
never
been
a
supported
use
case
for
us.
We
really
recommend
that
you
either
completely
use
your
own
or
completely
use
npm,
but
don't
mix
them
because
otherwise.
E
Yes,
but
watch
if
the
project's
developer
switch,
that
down
to
the
user.
Sorry,
water,
that.
C
So
I'm
really
only
mentioning
the
case
of
developers
maintain
a
separate
project.
So
let's
say
that
you're
planning
a
project
for
from
someone
and
want
to
contribute
on
it.
Then
you
need
to
follow
the
tool
that
they
are
using
to
develop
this
product.
So
let's
say
that
they
configured
their
repository
to
use
yarn.
Then
you
should
use
yarn
and
even
if
you
prefer
to
use
impm,
then
you
should
still
use
your
and
that's
the
same
reason
why
you
wouldn't
replace
eslin
by
ef,
just
because
you
prefer
it.
C
And
similarly,
if
the
repository
is
configured
to
use
npm,
then
you
should
use
it,
even
if
you
prefer.
As
for
users,
let's
say
that
you're
writing
yourself
a
project
and
that
you're
that
you
want
to
use
a
library
that
is
published
on
the
npm
registry.
C
C
Horizon
all
your
transitive
dependencies
engines.pm
field
will
be
ignored.
Yes,.
C
So
when
you
publish
a
package
on
the
npm
registry,
you
should
make
sure
that
it
will
work
on
all
packet
managers,
regardless
of
the
one
that
the
consumers
will
use
in
general.
It's
pretty
easy.
The
main
difference
in
package
managers
are
mostly
when
you're
developing
with
them,
for
example,
workspace
or
client
only
feature
in
that
you
only
have
used
them
from.
Within
your
repository.
You
never
publish
workspaces
to
the.
C
E
G
Yes,
I
have
two
questions.
First,
one
when
you
execute
yarn
for
the
first
time,
for
example,
it
will
ask
you,
if
you
want
to
install,
is
it
possible
to
non-interactively
install
yarn,
for
example,
if
you
are
building
a
docker
image,
you
will
not
be
able
to
answer.
Yes.
C
So
the
offline
case
is
also
something
that
should
be
possible.
It's
not
yet
implemented,
but
the
way
I
would
see
that
happen
is
that,
for
you
would
have
a
comment
that
would
download
a
specific
version
of
a
package
manager
under
a
table
version
that
you
would
store
anywhere
you
want,
and
then
you
would
have
another
command
that
would
install
the
package
manager
that
is
stored
inside
a
table.
C
C
C
So
I'm
not
sure
that
using
a
private
registry
would
be
easy,
because
then
you
have
a
configuration
to
configure
like
tokens
things
like
this,
but
that's
something
that
we
can
discuss.
G
F
B
I
was
thinking
you
know
one.
I
might
it's
an
excellent
point.
I
I
I
was
thinking
that
for
this
that
particular
case
having
it
where
you
know
pmm
can't
you
know
you
can
instruct
it
basically
to
download
these
to
the
local
cache
in
separate
later
or
have
it
point
to
a
local
cache
of
where
these
things
are
at
rather
than
using
this
using
this
configuration
that
could
be
a
configuration
on
pmm
itself
that
the
user
has
to
do
locally
right,
so
either
command
line,
option
or
whatever
for
pmm.
B
C
Just
for
example,
that
could
be
something
like
yarn
at
one
that
would
be
stored
inside
your
own
tdz.
Then
later
you
would
download
it
from
my
private.
C
So
this
kind
of
workflow
would
be
generic
enough
to
work
in
a
lot
of
cases.
The
user
would
have
the
responsibility
of
calling
curl
in
order
to
install
the
package
manager
version
that
they
would
want
to
use.
I
think,
as
long
as
we
can
work
with
standing
a
packet
manager
from
an
archive,
then
there's
a
lot
of
possibilities
that
are
adam.
C
Sure
the
pm
store
is
just
to
download
this
in
a
standard
way,
so
that
you
don't
have
to
care
about
how
to
generate
the
archive.
But
if
you
prefer
to
bundle
them
yourself
and
also
the
tgz
wherever
you
want,
the
hydrate
function
will
work.
Just
fine.
A
Okay,
so
what's
the
difference
like
I'm
just
trying
to
understand,
if,
if
somebody
wanted
to
use
pmem
today,
could
they
just
do
you
know
npm
install
pmm
and
then
it
would
work
exactly
the
way
you've
you've
shown
or
is
there
some
some
aspect
to
this?
That
only
comes
if
it's
integrated
with
node
itself.
C
So
one
big
aspect
is
that
it
will
just
work
for
everyone.
That
is
not,
as
I
mentioned,
the
big
problem
that
I've
met
in
the
ecosystem
was
people
that
wouldn't
not
use
yarn,
because
npm
is
by
default,
and
so
it
might
not
seems
a
bit
trivial.
But
the
reality
is
that
they
are
locking
themselves
out
of
an
option
just
because
it's
more
complicated
for
them
to
integrate
young
within
their
their
infrastructure.
C
And
I
think
that's
something
that
we
shouldn't
be
able
to
help,
because
if
it's
more
difficult
for
them
to
install
yarn,
it
means
also
that
it's
more
difficult
to
them
for
them
to
contribute
to
projects
that
use
yarn
and
that's
a
problem,
because
we
want
to
make
it
easier
for
everyone
to
contribute
to
other
projects
in
the
javascript
ecosystem.
A
C
Is
it
it
should
be
on
par
with
with
the
npm
install,
but
there
is
already
a
lot
of
a
fair
amount
of
people
that
find
it
strange
that
they
have
to
use
an
npm
install
in
order
to
install
yarn.
Personally,
I
don't
have
a
problem
with
that.
That's
even
the
thing
that
I've
put
inside
the
documentation
to
just
use
this
comment,
but
every
now
and
then
we
see
parts
on
twitter
mentally,
hey.
Well,
it's
weird!
C
So
it
it
turns
out
that
it's
actually
a
blockers
for
somebody.
C
Another
thing
is
that
it
would
also
make
it
easier
to
support
specifying
the
exact
package
manager
that
you
want
to
use,
which
is
a
good
feature
that
we
want
force
to
to
use
because,
in
our
opinion,
the
there
is
no
re.
Sorry
yarn
introduced
the
concept
of
a
log
file
and
it
became
widely
widespread.
But
ironically,
there
is
the
very
first
dependency
of
a
project
that
is
not
very
locked.
Yet
it's
the
packet
manager
itself.
C
The
package
manager
is
not
part
of
the
log
file
and
by
having
an
engines.pm
file
or
any
other
field.
Sorry,
it
would
allow
us
to
log
the
package
manager
and
finally
have
an
environment
that
would
be
completely
self-contained.
C
E
No,
I
left
comments
in
the
chat
and
I
will
move
that
to
give
up.
B
So
you
know
so
going
back.
You
know.
One
of
the
reasons
I
want
to
definitely
want
to
put
this
on.
The
agenda
is
that
I
mean
the
idea
is
that
this
would
be
added
to
the
node
distribution,
and
there
are
other
two
approaches
we
could
take
where
we
continue
to
ship,
the
the
npm,
client
and
pmm
or
the
alternative.
Is
we
ship
pmm
and
allow
the
income
client
to
be
installed
with
pmm?
B
You
know,
so
you
know,
obviously,
that
you
know
the
latter
changes
kind
of
the
default
out-of-the-box
behavior
for
for
node
users.
So
it's
got
to
be
something
that's
carefully
considered,
but
the
way
that
it's
this
has
been
done.
If
they,
you
know
the
first
time
somebody
does
an
npm
install
it's
going
to
go
off
and
and
grab,
and
you
know
and
download
that
you
know,
with
the
caveat
of
you
know
they
may
need
to
approve
the
download.
B
So
it
does
change
some
of
that
user
experience.
But
personally,
I
think
it
changes
it
for
the
better,
but
that
is
the
decision
that
we
need
to
yeah.
We
need
to
come
to.
A
A
Okay,
so
let's
move
on
to
the
other
issues
which
are
tagged
for
the
agenda.
The
next
one
is
simpler
and
faster
readables,
async
iterator.
A
A
Context,
if
not,
I
guess,
as
a
you
know,
as
a
as
a
back
port
of
that
december
major
level.
Pr,
you
know
if
people
can
go,
take
a
look
that
would
be
great.
A
Otherwise,
unless
there's
anything
else,
people
want
to
discuss.
We
can
move
on
to
the
next
issue,
which
is
rename
default
branch
for
master
domain
or
something
similar
number
33
834.
That
one
really
is
there
as
a
reminder
that
you
know
we
we
want
to
do
that.
We
were
waiting
on
some
additional
tooling
from
github.
A
G
Github
added
a
new
feature
to
choose
the
default
range
for
new
repositories,
and
I
think
we
should
change
it.
I
don't
know
if
anyone
did
it
yet.
A
A
G
H
A
H
B
H
B
Right
we're
not
getting
any
existing
one:
okay,
yeah.
A
H
B
A
A
Okay,
well
then,
let's
that's
anything
else
on
that,
one
that
people
want
to
mention
before
we
move
on
or
slowly.
You
know
doing
things
like
turning
that
on
and
and
trying
out
switching
some
of
the
existing
repos.
F
A
Okay,
if
not,
let's
move
on,
I
I
would
propose
we
move
to
the
blm
convert
to
button
3306
and
then
get
then
loop
back
to
the
discussion
of
the
unhandled
rejections.
Does
that
sound
good
to
people
yeah,
and
we
probably
should
time
box
both
of
these,
because
we
want
to
keep
at
least
10
minutes
for
a
private
section
at
the
end,
so
the
the
black
lives
matter
convert
to
button
3306
is
whoever
added
that
to
the
agenda
here.
A
G
G
Yes
miles
mentioned,
he
liked
the
cohen
approach
better,
and
that
was
the
extent
of
the
discussion.
Basically.
A
A
Okay,
that
makes
sense-
and
I
guess
you
know
it's-
we
can
go
from
there.
So,
okay,
so
then
the
other
issue,
which
is
audit,
google,
account
access.
I
know
rick
rich
had
pinged
pinged.
The
issue
brian
said
that
he
would
take
a
look
at
that
soon,
but
I
don't
think
it's
done
yet.
So
we
should
just
leave
that
on
and
then
let's
loop
back
to
the
change
default
dash
and
handle
rejections,
do
you
want
to
take
that
one
mary.
A
G
Four
hundred
and
something
responses,
I'm
not
sure
if
everyone
had
time
to
read
through
the
his
responses.
There
is
a.
C
G
G
I
agree,
especially
if
we
can
correlate
the
responses,
for
example,
correlate
the
the
default
that
users
chose
with
the
use
case
that
they
are
working
mostly
on.
So
maybe
you
should
postpone
for
the
next
meeting.
A
G
G
A
Okay,
that
sounds
good,
so
that
gets
us
to
through
all
of
our
issues
that
were
tagged.
I
think
this
time
we
should
skip
strategic
initiative
updates.
I
didn't
see
too
many
in
the
in
the
issue
and
we
want
to
keep
some
time
for
the
private
section.
So
at
this
point,
unless
anybody
has
something
that
you
think
we
should
cover
before
we
close
out
the
public
session,
we'll
go
ahead
and
do
that.