►
From YouTube: Open RFC Meeting - Wednesday, March 3rd 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live,
welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
march.
The
3rd
2021
we'll
be
following
along
the
agenda
that
was
posted
in
the
mpm
rfcs
repo.
It
was
issue
335,
so
pretty
packed
agenda.
A
Today,
I've
copied
and
pasted
the
hackamd
note
stock
if
you'd
like
to
add
yourself
as
an
attendee
and
just
pasted
it
there
and
chat
again
as
well,
quick
housekeeping
again,
these
calls
are
meant
to
ideally
push
forward
and
hopefully
improve
the
state
of
the
mpm
client
and
our
open
source
projects
and
also
are
an
opportunity
for
us
to
communicate
and
talk
about
improvements
that
the
community
would
like
to
see
happen,
and
we
ask
that
everybody
be
mindful
and
and
thoughtful
as
others
are
speaking.
A
Please
raise
your
hand
if
somebody
else
is
speaking
and
I'll
call
on
you
there's
a
code
of
conduct
that
we
expect
everybody
to
abide
by,
which
is
linked
in
the
issue
that
we
posted
for
this
agenda
and
feel
free
to
read
it.
If,
if
you
haven't
already
any
announcements
that
folks
have.
A
If
not
no
announcements
for
this
week,
we
can
dive
right
into
the
first
item.
It
doesn't
look
like
porta
was
able
to
join
us,
but
the
first
item
in
the
agenda
is
the
pr
or
rfc
332,
so
yarn
style,
command
script,
bin,
lookups,
I'll
just
copy
and
paste
the
issue
itself
based
on
the
fact
order's.
Not
here
did
somebody
else
want
to
potentially
add
context
here.
I
know
jordan
you've
jumped
into
this
isaac.
I
know
you've
also
communicated
and
gives
given
some
feedback.
A
I
know
I
also
have
some
thoughts,
but
I
haven't
actually
put
pen
to
paper.
Yet
jordan
did
you
want
to
go.
B
Yeah,
this
is
worthless.
One
right.
C
Yeah
yeah,
unfortunately,
it
looks
like
wasn't
able
to
jump
on,
but
yeah.
That's
fine.
B
B
I
forget
the
exact
order,
but
it
will
run
one
of
a
foo
script
or
a
local
foo
binary,
and
I
don't
even
know
if
it
falls
back
to
the
global
or
not,
but
it's
certainly
at
least
one
of
those
two
and
so
folks
can
type
yarn
eslint
whatever,
and
it
works
the
same
as
if
you
typed
npx
eslint
whatever
or
if
you
have
an
eslint
script,
it
works
the
same
as
npm
run,
eslint
whatever
and
it
like
npx.
B
It
avoids
the
need
to
like
have
the
double
dash
argument
in
order
to
pass
arguments
onto
the
script
and
so
on.
So
the
request
is
essentially
to
be
able
to
do
that
with
npm,
to
be
able
to
type
npm
foo
and
have
it
either
run
a
foo
script
or
a
local
foo
binary.
B
Maybe
the
global
binary
I
don't
know
and
and
that
the
request
itself,
like
the
desire,
seems
fine
to
me.
The
concerns
that
I
have
are
I
mean
one
of
them
is
that
it
means
that
basically
adding
any
new
top
level
npm
command
becomes
december.
Major,
because
if
I
have
a
foo
script
and
suddenly
npm
8,
you
know
our
new
version
of
npm
adds
an
npm
foo
command.
Like
let's
say
I
had
a
script
called
build,
which
is
a
common
name,
and
then
we
decide
there's
already
npm
rebuild.
B
Maybe
we
make
an
npm
build
right
and
at
that
point
that
would
break
anyone
who
was
relying
on
npm
build
calling
their
script,
and
the
reverse
is
true
as
well.
It
would
break
anyone
who
expected
npm
build
to
run
npm
build
if
it
started
running
the
script
instead,
so
the
it
kind
of
like
smushes
together
a
bunch
of
of
domains
in
a
way
that
seems
convenient,
because
it
is
convenient
for
the
common
case,
but
it
has
a
lot
of
magic
and
implicitness.
A
Yeah,
I
think
we've
discussed
this
a
couple
times
like
in
different
forms
as
well,
and
I
see
wes
and
nilf
and
roy
all
giving
you
thumbs
up
there,
jordan
agreeing
with
the
essentially
your
your
view
of
this.
I
personally
also
think
it's
probably
better
for
us
to
be
explicit
here,
I've
flown
or
oh,
actually,
what
I
was
able
to
join
how's
it
going
did
you
want
to?
Maybe
I'm
not
sure,
if
you're
listening
in
to
jordan's
synopsis
of
of
your
rc,
but
we
want
to
give
you.
A
You
know
the
floor.
If
you
want
to
speak
a
little
bit
more
about,
I
know
you
have
some
data
around
your
own
usage
of
commands
as
well,
which
was,
I
think,
what
led
to
this
rfc,
but
would
love
to
hear
from
your
own
own
voice.
Sure.
D
Yeah
you
I
mean,
to
some
extent
almost
everything
I
have
to
say.
I
have
conceptually
already
said
on
that
rfc
there's,
there's
not
really
any
anything
other
than
like.
You
know.
This
is
just
a
general
workflow
that
I
use
all
the
time
and
when
I
started
when
I
wrote
a
post
about
why
I
was
still
using
yarn,
a
bunch
of
people,
even
in
microsoft,
started
reaching
out
and
been
like
yeah.
D
We
well
we're
interested
in
moving
to
npm,
and
this
is
something
that
would
be
great
if
you
can
at
least
try
and
push
and
see
like
I
get
that
it
is
definitely
like
a
breaking
change
on
your
side
so
like
trying
to
find
ways
to
minimize
the
risk
is
just
something
that
I'll
be
thinking
about
for
a
while.
I
I
don't
expect
it
to
be
rubber,
stamped.
E
Yeah,
it's
it's!
Actually,
it's
actually
worse
than
just
making
that
every
every
command
is
a
breaking
change.
It's
every
command
absolutely
has
to
be
a
breaking
change
like
no
matter
what
other
sort
of
affordances
we
add
to
it,
because
somebody
adding
a
new
bin
to
a
package
that
you
install
could
could
inadvertently
break
a
workflow
have,
and
so
I
mean
this
is.
E
This
is
something
that
I'm
I'm
sure
that
yarn
just
deals
with
and
says:
okay!
Well,
every
every
new
command
is
a
breaking
change
like
that's
how
it
is
or
they're
just
comfortable
with
those
those
being
breaking
within
a
non-severe
major.
D
E
Right,
you
have
your
hand
up,
I'm
not
sure
how
I'm
not
sure
how
they
handle
adding
new
commands,
because
there
have
been
new
commands
added
within
yarn
one.
I
think
it's
probably
just
yellow.
G
Something
yeah
how
do
like
just
from
a
fundamental
software
development
standpoint.
This
scares
me
because,
when
you
mix
like
I'm
a
cli,
I
have
things
you
can
do,
and
I
have
users
able
to
do
things.
I
have
to
name
space
that
otherwise
like
what,
if
they
want
to
run
an
install
script
right,
one
of
their
scripts
called
install
and
they
want
to
have
npm
run.
Install
right.
That's
the
ambiguity.
G
A
Over
my
hand,
wes
did
you
want
to
give
some
feedback
or
actually
order?
Did
you
want
to
like
rebuttal
to
that.
D
I
mean
you
know:
I've
never
expected
that
sort
of
behavior
from
yarn.
There
is
a
very
obvious,
you
know
the
script,
the
things
that
come
with
the
the
package
manager
come
first
and,
like
you
know,
the
fallbacks
are
pretty
obvious.
What's
what's
going
to
happen.
H
Sure
I'll
I'll
actually
address
that,
probably
on
jordan's
behalf,
since
jordan
originally
pointed
out
the
problem
with
that.
So
whether
or
not
npm
scripts
comes
first.
If,
if
a
user
has
a
build
script,
which
is
highly
common
and
npm
adds
a
build
script,
which
would
normally
be
a
minor
that
is
now
a
breaking
change
for
that
end
user
right,
because
it
would
run
npm's
build
over
their
build.
So
it's
still
a
breaking
change,
even
if
right,
the
the
the
npm
scripts
come
first,
and
that's
just
to
address
that
that
workflow.
H
My
question
was-
and
I
don't
see
this
referenced
in
the
issue,
but
one
other
possible
approach
would
be
to
for
this
to
be
a
change
in
npm,
runs,
behavior
or
or,
alternatively,
to
add
another
top-level
command
that
adds
this
new,
this
new
functionality.
So
it's
not
that
we
would
be
remo,
never
having
a
namespace.
We
would
still
have
a
namespace.
It's
just
that
namespace
would
behave
like
yarns,
unnamed,
based
behavior,
and
that
would
be
one
way
that
would,
yes
explicitly
sorry
lots
of
corrections
there
right
explicitly
delineated.
H
Yes
right
so
it
would
separate
the
the
behavior
of
npm
build
from
npm
exec
build
or
npm
run,
build
or
whatever
we
you
know
want
to
call
it,
and
then
that
build
would
be
the
yarn
style
which
would
run
it
would
be
npm,
run
tsc
and
you
wouldn't
need
to
have
a
tsc
command
in
your
package
json.
It
would
just
find
the
binary
that
you
installed.
B
B
You
know,
I
suppose
there
could
be
somebody
who's,
relying
on
the
fact
that,
like
if
the
script
doesn't
work,
it's
you
know
it
isn't
there.
It
doesn't
work
but
like
we
could
always
provide
an
npm
config
argument
that
that
controls
that
behavior,
that
turns
it
off
for
the
people
who
actually
care
about
that
that
that
seems
really
great
and
then
the
the
only
other
ergonomic
wart.
B
I
think,
because
I
think
typing
npm
foo
versus
npm
run
foo
when
you
didn't
have
to
make
a
script,
is
effectively
identical
right
like,
but
the
the
only
remaining
ergonomic
work
really
is
the
dash
dash
requirement
that
if
I
type
npm
run
eslint
and
it
just
invokes
the
eslint
binary
and
I
want
to
pass
an
argument
to
with
npx
and
yarn,
I
just
start
passing
arguments
with
npm
run.
I
have
to
if
it's
a
double,
if
it's
a
regular
argument
that
just
goes
through.
B
B
If
there
is
then
that
combination
of
two
improvements
to
npm
runs
seems
like
it
would
provide
users
with
all
of
the
delight
that
orta's
looking
for
without
running
into
all
of
the
implicitness
and
maintainability
concerns
that
those
of
us
that
some
of
us
are
reacting
to,
or
at
least
most
of
the
delay,
because
it's
still
a
couple
extra
characters.
G
Yeah,
having
npm
run
do
that
we
still
the
safety
of
the
warning.
If
you
don't
have
it
installed
right,
so
that's
kind
of
our
guard.
There.
A
G
Just
to
speak
to
your
command
line,
parsing,
we
are
in
the
process
of
kind
of
re-architecting,
our
config
works
and
separating
the
concerns,
and
it
was
not
outside
the
realm
of
possibility
to
get
to
the
point.
Where
run
scripts.
Excuse
me,
args
parser
is
just
like
yeah.
I
accept
everything
and
pass
it
along
kind
of
a
thing.
So
that's
not
that's
not
to
make
a
break.
What
you
suggested
there.
A
So
I
noted
in
the
comments
here
as
well
and
I'm
trying
to
take
notes,
as
I
go
along
here
for
folks
noted
in
in
the
chat
specifically,
that
is
the
shorthand
and
the
alias,
also
like
a
big
part
of
this
as
well
like
just
the
e
like
the
developer.
A
Experience
like
that
seems
to
be
something
that
comes
up
each
and
every
time,
not
just
like
the
functionality
here,
but
it's
also
just
like
the
k
number
of
characters
that
I
write
if
we
can
save
that
for
developers
like
that
is
a
an
improvement
as
well
like.
Is
there
also
like
an
aspect
of
this
that
it's
like
that's
what
we're
looking
to
solve
for
as
well
like
that,
so
it's
not
just
that
you
have
this
behavior
and
I
think
jordan
summarized
it
well
and
I'll.
Try
to
take
notes
here
after
on.
A
That
is
that
if
we
can
improve,
runs,
npm
run
script
like
to
have
this
improved
behavior
and
then
put
it
at
least
in
my
opinion,
like
the
only
way
to
like
make.
This
better
is
also
to
introduce
a
new
binary.
A
At
least
that
is
essentially
mapped
to
that
and
again
I've
been
holding
off
on
creating
that
rfc
itself,
but
it
it
essentially
is
one
of
those
things
that
has
come
up
time
and
time
again
that
we're
avoiding
and-
and
I
feel
like
the
only
way
to
like
make
this
better
and
actually
improve
this
experience.
For
for
users,
it
would
be
to
do
that
map
that,
to
this
improved
run
script.
A
That
essentially
has
this
logic
and
behavior
and
npm
top-level
commands
are
npm
top-level
commands
mpx
is,
is
executables
binaries,
and
then
this
new
we
don't
have
to
use
npr,
because
unless
you
love,
you
know
soft-spoken
radio
we
can
use
whatever
the
name
is.
If
there
was
a
nice,
you
know
a
new
binary
that
essentially
mapped
to
this
behavior
like.
Would
that
solve
this
or
or
is
it
truly
that
we
really
want
npm
this
to
be
this
all-encompassing
thing
like
for
you
or
to
like
because
you're
this?
A
This
is
your
rfc
like
what
would
you
think
of
that
as
the
approach
where
we
create
a
new
rfc
asking
or
promoting
the
idea
of
having
a
binary
that
maps
and
then
also
introducing
new
behavior
to
run
script?
I
guess
that
would
be.
D
Could
work
in
part
like
for
people
that
don't
use
npm
very
regularly?
I
think
npx
is
still
like
considered,
like
ex
you
know,
doing
external
command.
I
think
adding
a
nuke
wait.
Maybe
I'll
restart
this.
I
don't
think
it's
a
blocker
if
it's
just
npm
space
r
space
tsc
is
maybe
the
right
way
to
phrase
this.
I
don't.
I
don't
think
the
like.
D
The
complete
ownership
of
global
namespace
is
probably
like
totally
like
a
blocker
for
for
my
conceptual,
like
usage
in
this
case
like,
if
run,
took
into
account
like
binaries,
and
it
was,
as
short
as
just
adding
an
extra
r
ahead
of
that.
D
That
is
totally
acceptable
to
me,
and
that
could
just
be
a
case
of
changing
what
ron
does
and
you
know-
maybe
I
assume
there's
an
alias
for
that-
that
sort
of
single
letter-
I
don't
strictly
know
but
yeah-
an
alternative
where
it
is
another
command
that
just
executes
like
this
in
the
global
scope
instantly.
That
would
be
that'd,
be
a
solid
win.
E
Yeah,
I
was
just
I
was
just
clarifying
that
the
the
thing
we're
contemplating
here
is
npm
run,
would
also
fall
back
to
locally
installed
bins.
If,
if
there's
no
script
by
that
name-
which
I
think
is
a
pretty
reasonable
thing,
I
always
end
up
creating
an
eslint
script.
That
just
is
eslint
specifically
for
this
reason,
so
it'd
be
pretty
nice
to
have
that
there.
The
the
question
I
erased
was,
I'm
not
sure
off
the
top
of
my
head.
H
E
Yeah
you're
right,
you're,
right,
you're,
right,
okay,
I'm
sold
it's
summer,
major
the
yeah
on,
unlike
you
know,
do
we
add
npr
as
another
external
command.
I
think
that
actually
npx
was
a
mistake.
It's
it's
a
mistake
that
we
preserved,
because
we
didn't
want
to
just
like
rip
it
out
and
not
have
it
there
anymore,
but
the
right
answer
was
to
create
an
npm
exec
command,
and
if
somebody
wants
to
run
npm
exact
with
three
characters
instead
of
five,
then
they
add
a
bash
shortcut
and,
like
that's,
really
easy
to
do.
A
So,
okay,
I
have
opinions
on
that,
but
I
don't
know
who
was
first
but
wes
and
michael
our
car.
Sorry,
your
hands
are
up
west.
Did
you
wanna
go
first
guard.
G
This
is
sember
major
and
I
think
it's
it's
an
opt-in
right
like
your
flag
for
for
npm.
We
can
get
this
in
seven.
If
we
accept
it
as
something
you
opt
into
that's
more
typing,
I
can
fix
that
with
an
alias
just
like
my
copy
command
as
a
dash.
I
that
I
always
add
right.
I
can
just
alias
npm
run
if
I
need
that
and.
H
I
originally
raised
my
hand
just
to
make
sure
that
it
I
said
that
it
was
december,
but
as
I
was
thinking
about
that
it
could,
you
could
have
the
behavior
behind
a
flag
to
opt
in.
I
think
that
starts
to
see
what
you
were
saying
there
with
your
your
flag
that
you
posted
in
the
chat-
and
my
question
was
going
to
be.
Is
this
going
to
be
a
change
to
the
npm
run
scripts
package,
because
that
that
would
definitely
also
be
a
breaking
change
there?
H
I'm
actually
relying
in
a
couple
of
cases
where
I,
where
I
try,
catch
that
and
do
my
own
behavior
around
it.
So
if
you
change
the
behavior
in
in
that
package,
I'll
I'll,
it
will
be
a
change
to
your
users
for
that
as
well.
E
It
would
definitely
be
a
breaking
change
in
and
kimchi
run
script.
If
we
wanted
to
do
it
there,
we
could
still
make
the
breaking
change
in
in
that
package
and
then
pull
it
into
npm,
seven
and
just
disable
it
or
whatever
pass
the
flag
through
somehow
a
lot
of
ways
to
skin
that
cat.
I'm
not
I'm
not
worried
about
that.
G
G
A
B
G
I'm
coming
from
a
place
of
the
same
kind
of
confusion
right
as
so
like.
We
have
three
layers
here
right
us
as
npm
providing
commands.
We
know
we
own
a
run.
A
package
is
now
providing
commands.
It
can
run
if
you're
in
that
repo
running
npm
run,
and
then
we
have
this
third
layer
of
see.
We
we've
we've
got
three
things
and
we've
we've
agreed.
We
need
to
separate
the
first
two
we're
still
conflating
the
second
two.
B
G
Well,
no,
we
are
confusing
the
two
here.
What
npm
run
eslint
can
either
run
something
that
local
package
has
given
me
or
go
run
eslint
right.
It's
the
same
problem.
The.
B
B
A
E
Which
is
a
which
is
a
pretty
major
shift,
and
I
I
think
so
gary
I
feel
like
you're.
You
are
touching
on
something
that
is
a
really
unfortunate
ambiguity
with
npm
exec
as
it
currently
stands,
which
is
there's,
there's
three
things
it
could
be
doing.
It'll
first,
try
your
local
node
module
dot
bin.
Then
it
will
try
your
global
globally
installed,
node
modules,
bins,
and
then
it
will
fetch
the
package
from
the
registry
and
put
it
in
a
temp
location
and
run
that
and
that's
weird
it
would
be
nice.
E
I
think,
to
have
a
a
command
which
is
just
like.
I
just
run
the
local
one.
Only
and
if
it's
not
there
then
fail.
We
do
have
a.
We
do
have
a
way
in
you
know.
At
least
there
is
a
way
in
npm
exec
that
if
it's,
if
it's
not
installed
globally
or
locally,
then
it
will
prompt
you.
So
we
kind
of
close
that
loophole
a
bit
but
yeah
it's
if
it
can
be
either
local
or
global
and
there's
no
command
to
say
only
run
the
local
one.
E
Then
that's
sort
of
unfortunate
and
that's
the
state
right
now.
So
I
just
want
to
be
mindful.
A
H
Sure
so,
actually
pele,
I
don't
know
if
you
want
to
talk
about
what
you
were
saying
in
the
chat,
because
it's
related
to
to
what
I
was
going
to
say
not
to
put
you
on
the
spot,
but
I
think
I'll
go
ahead.
Yep.
J
Well,
so
I
think
that
since
every
package
can
publish
a
binary
of
any
name-
and
I
mean
if
I'm
used
to
go,
go
in
and
and
and
run
a
script
of
a
certain
name
in
in
my
projects
and
then
suddenly,
I'm
in
a
project
and
I'm
like
trying
out
and
thinking
okay,
this
is
gonna.
This
is
gonna.
Work,
like
you
know,
run
even
even
if
running
npm
tests
like
mpm
run
test
and
all
of
a
sudden
one
of
my
modules
has
one
of
my
dependencies
has
published
a
test.
J
It
could
be
a
way
to
to
actually
get
people
to
run
code
that
they
wouldn't
want
to
like,
wouldn't
want
to
run
because
you
can
insert
if
you
get
a
hold
of
a
popular
package
that
many
people
depend
on,
then
you
could
insert
a
command
there
and
there's
also
stuff
like
in
typical
github
actions
commands
that
you
can
have
something
like
mpem
run,
build
if
present,
and
I
mean
depending
on
how
you
do
it-
it
feels
that
it
could
result
in
similar
concerns
as
there
as
you
voiced
for
top
level
commands
like
an
mpm
build,
would
be
a
summer
major
because
it
could
conflict
with
a
an
existing
command
that
yeah
I'm
just
concerned.
B
Without
this
capability,
what
people
will
do
is
run
npx
which,
like
or
they'll,
run
the
you
know.
I
guess
without
this
capability
and
only
using
npm
they'll
do
npm
run
if
they're
intending
to
do
a
script
and
they'll
do
npx
if
they're
intending
to
do
a
binary,
but
that
doesn't
allow
like.
That
means.
B
You
have
to
have
a
different
command
for
both
use
cases,
and
then
npx
also
means
that
if
they
have
like
they
could
have
something
globally
installed,
that
they're
expecting
to
run,
and
then
a
local
thing
hijacks
that
right,
if
you
have
create
angular
or
you
know,
create
react,
dapper
or
ember
cli
or
something
globally
installed,
as
many
people
do
or
yeoman,
and
then
you
have
a
local
dependency
that
just
makes
that
declares
that
as
a
binary,
npx
will
already
hijack
it
and
that's
already
what
people
are
doing
and
if
people
didn't
have
npx,
then
what
they
used
to
be
doing
is
put
node
modules,
dot
bin
in
their
path,
which
is
much
worse,
and
so
there's
like
all
of
these
are
like
the
the
vulnerability
you're
talking
about.
B
H
So
I
think,
and
we
should
probably
go
to
tyranny,
but
I
just
wanted
to
mention
that
is
specifically
the
rce
vector
I
was.
I
was
referencing
when
I
said
that's
an
rce
is:
is
somebody
just
randomly
in
a
popular
transitive,
adding
a
common
build
target
and
then
using
that
as
their
malicious
entry
point
and
to
jordan's
point?
Yes,
there
is
already
these
problems,
but
adding
new
interfaces
on
top
of
these
problems
is
not
necessarily
the
right
solution.
H
If
we're,
if
we're
concerned
about
that
problem
in
a
real
sense,
we
should
probably
revisit
a
bit
some
of
the
conversations
about
like
how
those
bin
scripts
are
registered
today
and
and
and
solve
some
of
those
problems
as
well
in
whatever
new
feature
we
introduce.
So
we
both
improve
the
security
and
the
usability
at
the
same
time,
because
I
think
we
can
achieve
that
yeah.
K
Just
the
one
thing
I
wanted
to
say
there
is
like,
in
the
case
of
it
being
potentially
exploited
by
like
a
module,
popular
module,
that's
hijacked.
I
I
think
we
there's
other
problems
and
like
that
is
one
path,
but
I
don't
think
that
providing
paths
for
abuse
of
a
hijacked
module
is
like
should
be
excluding
features
because
like
if
a
popular
module
is
hijacked,
there's
other
plenty
of
other
problems
already
there
and
that's
just
like
an
avenue
that
could
be
used.
D
Yeah
one
of
the
ways
that
yarn
has
sort
of
solved
some
of
these
kinds
of
problems
is
by
not
allowing
transitive
dependencies
to
be
able
to
actually
run
commands
when
they're
in
the
global
name
space,
it's
called
the
unstrict
mode,
and
that
that
has
caused
me
to
update
a
lot
of
package
jsons
in
the
past,
which
is
you
know
useful
in
that
in
context.
D
I
think
I
think
everybody
is
generally
on
the
same
page
in
terms
of
updating
my
rfc,
I
might
just
hold
off
until
either
someone
on
the
mpm
side
either
has
a
say
in
like
what
you
all
think
is
the
right
direction.
A
Appreciate
that
feel
free
to
update
the
the
notes
I
took
apologize,
it
was
they
were
sporadic
if
folks
feel
like
they
aren't
accurate,
definitely
add,
add
context
that
I've
lost.
A
If
so
and
again,
thank
you
so
much
order
for
for
bringing
this
up,
there's
other
other
cool
ideas
that
I
know
you're
pushing
for
as
well,
especially
in
the
typescript
space,
so
install
with
types,
interesting,
cool,
so
moving
on
then
quickly,
because
I
know
we
spent
a
lot
of
time
on
that.
But
I
thought
it
was
useful
roy,
I'm
not
sure
if
you've
got
a
little
monster
you're
having
to
deal
with
right
now,
yeah.
L
On
workspaces,
I
can
give
a
quick
update,
yeah
so
yeah,
just
maybe
a
little
bit
of
an
update,
yeah,
I
guess
from
what
we've
been
discussing
last
week.
L
So
basically
we
had
a
little
bit
of
back
and
forth
within
the
team
here
and
we're
kind
of
tending
to
go
back
to
the
place
we
were
in
the
beginning.
I
know
when
we
started
exploring
the
implementation
we
started,
leaning
more
towards
having
a
workspace
top
level
command
within
the
cli,
but
now
we're
kind
of
back
into
the
config
approach.
L
Basically,
so
either
you
use
a
command
line
argument
or
a
config
for
either
filtering
for
a
specific
workspace
or
setup
nested
workspaces
or
all
of
your
workspaces,
with
like
a
generic
dash
dash
workspaces
option
so
yeah.
I
started
just
fleshing
out
this
document
based
on
the
work
we
personally
did
in
the
rfc
to
identify
and
categorize
the
different
types
of
commands
that
the
client
needs
to
support.
L
So,
the
rationale
being
that
we
had
already
identified
the
basically
the
as
a
category
on
one
of
the
categories,
like
all
the
install
commands
right
and
basically
in
that
context,
like
we
figured
out
well,
it's
basically
the
same
thing
as
having
workspaces
option
is
true.
Right,
like
install,
is
currently
already
aware
of
workspaces
right,
like
it
links
them
into
place
and
all
of
the
other
related
install
commands.
L
So
we
could
kind
of
get
by
get
around
like
the
the
complications
of
that
by
just
saying
that
the
other
categories
like
they
basically
have
workspaces
as
false
by
default,
so
so
that
your
other
commands
like
still
behave
as
expected
today.
So
any
other
commands
like
here
are
the
written
from
the
dependency
tree.
L
But
up
here
we
have
the
standard
category
which
behaves
similar
to
just
sitting
into
a
workspace,
folder
and
executing
that
command
there,
so
yeah
this
one
would
be
more
likely
to
break
if
we,
if
we
were
to
just
assume
workspace,
is
true
by
default.
So
basically,
the
difference
being
today,
if
you
just
run,
let's
say
in
pm,
docs
very
simplistic
command
here
in
the
top
level,
it
would
output
result
for
the
docs
reference
of
the
top
level
package
json.
L
But
if
you
mean
to
run
across
all
the
workspaces,
then
it
would
do
the
same
as
cd
into
each
one
of
the
folders
and
updating
the
outputting.
The
result
for
each
of
the
workspaces
there
so
assuming
workspace
is
true
for
all
the
commands
is
not
really
a
solution
right,
it's
problematic,
so
a
way
to
get
around
it
is
having
workspaces
being
false
by
default
in
all
the
other
commands,
and
basically
only
in
the
install
family
of
commands.
Have
it
been
true
by
default.
L
So
I
I'm
starting
to
put
together
a
bunch
of
examples
here,
just
to
kind
of
make
sure
we
do
the
exercise
of
thinking
through
each
one
of
the
commands.
How
they
behave
like
this
is
another
example
that
it
will
look
up
the
current
folder
package.json
to
try
and
compare
the
current
direct
folder
against
the
the
package
published
by
the
same
name.
So
here
is
an
example
of
running
it
in
the
top
level,
then
I'm
just
have
a
fork
of
a
bread
here
that
I'm
doing
a
little
bit
of
tweaking.
L
L
This
here
will
just
run
for
the
top
level,
as
you
would
expect
today.
But
if
you
try
to
filter
by
a
specific
workspace
name,
then
it's
running
the
task
for
that
work,
that
specific
workspace.
L
If
you
try
and
run
yeah
here,
I
missed
the
the
command
from
the
example,
but
if
you
try
and
run
for
all
the
workspaces,
then
you
get
the
output
for
all
the
workspaces.
In
the
context
of
the
test
command,
so
yeah
that's
pretty
much
where
I
stopped
and
I
wanted
to
provide
the
update
and
just
hear
if
there's
feedback.
A
I
appreciate
you
sharing
that
we'll
probably
have
some
demos
by
next
week
for
sure
and
yeah.
I
think
what
should
be
highlighted
here
in
what
you
said
was
just
as
we
flushed
out
the
category
the
categories.
I
think
that
this
became.
A
We
just
became
aware
that,
like
this
was
the
right,
I
think
the
right
design
and
was
kind
of
where
we
started
and
then
we
I
know
that
we
scope
things
to
a
workspace
command
and
then
we're
going
back
a
little
bit,
at
least
with
the
design
of
this,
but
I
think
yeah,
the
categorization
and
basically
saying
what
each
command
is
going
to
do
was
what
highlighted
this
has
changed.
So
I'm
not
sure
if
anybody
else
has
any
comments,
but.
E
Maybe
isaac
yeah,
I
I
know
we
were
going
back
and
forth
on
the
top
level,
top
level
command
versus
a
flag
to
kind
of
opt
into
workspace
awareness,
and
then
this,
where,
where
we
ended
up
landing,
was
no
top
level
command,
no
no
flag.
Just
if
there's
workspaces,
we
do
workspace
things,
because
it's
probably
what
you
want
and
it's
what
we're
doing
anyway
for
a
bunch
of
commands.
E
So
with
that
in
mind,
we
we
do
have
to
figure
out
kind
of
what
it
means
to
use
the
dash
w
flag
as
a
filter.
So
if
I
want
to
install
only
in
one
workspace
and
not
refine
my
entire
tree,
like
there's
some
there's
some
kind
of
arborist
work
that
that
needs
to
be
cleaned
up
there,
which
could
also
actually
help
us
help
us
avoid
repeating
some
of
the
bugs
that
we've
had
in
the
global
space
where
we
do
a
similar
sort
of
filtered
install.
E
So
we
don't
have
to
install
every
single
thing
when
you
install
one
global
package,
the
the
other
challenges,
the
other
challenging
ones,
are
exec
and
run
script
because
you
you,
wouldn't
I
wouldn't
want
to
run
npm
exec
eslint
and
have
it
just
run
eslint
50
times,
because
I
have
50
workspaces.
I
would
want
to
just
run
it
once
in
the
top
level,
unless
I
specifically
said
run
it
in
these
three
workspaces,
similar
with
npm
test
or
any
other
run
script.
E
So
those
ones
probably
do
need
a
little
bit
more,
a
little
bit
more
careful
thought
for
the
ones
that
look
in
the
package
json
like
very
pretty
much
covered
like.
If
you
give
it
a
workspace
argument,
then
it
will
use
that
package.json
instead,
it'll
be
effectively
the
same
as
npm
docs
dash
prefix
equals
packages,
foo.
E
So
yeah
it's
I
like
where
this
is
landing
it.
It
feels
like
a
satisfying
resolution
and
then
also
we
keep
the
top
level
workspace
command
if
we
ever
do
want
to
say
well,
here's
a
here's,
a
special
command
for
initializing,
a
new
workspace
or
for
adding
a
workspace
or
removing
one
or
renaming
it.
Or
what
have
you.
H
H
I
think
there
is
a
solution
in
my
mind,
whereas
it
would
be
if
you
run
that
and
the
top
level
package
jason
does
have
a
lint,
you
know
eslint
script,
then
it
would
run
that
instead
of
cding
into
every
directory
in
that
it
by
default
again,
obviously
we
should
have
flags
that
make
it
do
one
or
the
other
explicitly,
and
and
yet
he
had
all
that
stuff,
but
by
default
I
I
think
you
know
it'd
be
pretty
straightforward
to
just
say
like
what.
H
L
Yeah,
I
think
I
think
that's
safer,
at
least
the
way
I
see
it
now,
drawing
the
examples.
I
think
the
safer
route
is
just
to
say:
workspaces
are
it's
just
false
by
default
right
for
all
the
other
commands,
except
for
the
install
commands,
which
already
is
handy
now,
the
family
of
install
commands
ci?
What
have
you
like?
They
are
already
taking
workspaces
into
consideration
today,
so
they're
the
equivalent
of
having
workspaces.
True,
all
the
other
commands,
on
the
other
hand,
like
it's
the
equivalent
of
having
workspaces
false.
L
E
E
Also,
I
think
this
was
my
labeling
yeah,
there's
also
the
the
ls
command,
I
think,
needs
a
little
bit
of
of
workspace
awareness,
because
right
now
it
just
shows
your
top
level
packages
by
default,
and
so
it
shows
each
of
these
workspaces
as
links,
but
it
doesn't
show
their
dependencies
and,
I
think
like
it
should
be
showing
the
dependencies
of
my
projects,
which
is
the
dependencies
of
my
route
and
the
dependencies
of
my
workspaces
and
similar
for
like
outdated
right.
It's
another
one.
E
L
L
I
don't
know
what
yeah
I
don't
know
if
it's
considered
a
breaking
change.
I
know
I
know
some
folks
are
more.
L
Yeah,
like
from
the
example
isaac
just
gave
like
because
essentially
workspaces,
it
means
it's
your
code
too
right,
so
you
care
about
their
dependencies,
so
either
is
just
basically
proposing.
Okay,
npmls
should
already
print
the
dependencies
and
the
dev
dependencies
for
workspaces
too.
That's
which.
L
E
Yeah,
I
don't
know
if
that's
the
best
idea,
I
mean
we
it's
kind
of
marked
as
experimental
anyway,
and
that
would
make
it
more
useful.
I
think
everybody's
sort
of
expecting
workspaces
to
change
in
some
dramatic
ways
along
the
the
v7
time
frame.
So
as
long
as
we're
not
like,
like
the
case
for
it
being
a
opt-in
or
semver
major,
I
think
would
be
well
here's
this
here's.
This
reasonable
use
case
that
somebody
has
where
they're
using
npmls
and
if
we
start
printing
those
additional
lines
it
will
break
them.
E
I'm
not
sure
that
that
exists
for
ls
for
for
this
kind
of
change
that
I'm
proposing
or
for
outdated.
It's
just
we're
going
to
start
showing
them
a
little
bit
more
data.
Pretty
audit
too.
A
Right
right
getting
a
bit
in
the
weeds
here,
but
I
think
you
also
have
a
comment
and
let's
maybe
after.
H
That
or
something
yeah,
my
only
comment
was
I
don't
well,
you
might
see
it
as
experimental
and
while
it
might
be,
I
don't
imagine
most
users
are
going
to
see
it
the
same
way
and
as
soon
as
they
start
using
it
and
they're
like
oh
great.
Finally,
I
can
switch
and
then
we
break
them
not
going
to
be
a
great
experience.
H
A
Okay,
I
want
to
quickly
move
on
because
we
have
a
bunch
of
other
items
here,
moving
to
and
and
feel
free
to
add
comments
and
feedback
to
the
updated
rfc.
The
that
roy's
still
working.
C
A
If
you
have
any
other
sentiments
for
sure
it
sounds
like
the
action
item
there.
Initially
roy
was
also
that
you're
going
to
continue
to
update
that
over
the
next
week
with
other
examples,
other
specific
examples
for
each
command.
So
so
item
number
four:
the
rc
325
run
pre
post
install
scripts
on
a
single
package,
installation
I
think
we've.
This
has
come
up
a
couple
times,
not
sure
where
we've
landed
with
this
or
if
there's
a
separate
rc
to
be
made.
E
Yeah,
I
think
we
need
a
node
modules,
has
been
mutated
script
hook,
life
cycle
event.
G
E
Itself,
regardless
of
where
it's
implemented
like
the
user,
should
be
able
to
put
a
you
know:
a
mutation,
a
script
stop
mutation
right,
it
gets
run
before
and
after
you
know,
with
a
pre
and
post
whenever
we're
making
any
kind
of
change
to
the
package
tree.
That
would
solve
this
without
conflating
what
the
install
and
post
install
scripts
are
used
for.
G
G
That's
the
fundamental
thing
they
want
right,
so
it
isn't
even
as
a
developer,
thinking
about
it,
I'm
not
thinking
about
it.
As
my
node
module's
been
mutated,
I'm
thinking
about
it.
I
need
this
to
run
when
I
have
been
installed
versus.
I
need
this
to
run
when
I
am
installing
packages,
and
I
think
that's
the
for
the
developer
experience-
that's
the
way
we
need
to
make
this
look
and
the
way
we
need
to
think
about
it.
E
Yeah,
so
we
we
run,
we
run
the
pre
and
post
install
scripts
when
you
run
npm
install
with
no
arguments,
because
that's
sort
of
like
I
need
to
get
to
the
state
where
I
have
been
installed
is
is
what
this
looks
like.
It
is
an
ambiguity
it
was.
It
was
not
an
ambiguity
initially
in
npm
and
when
we
started
doing
local
installs
it
became
one,
but
what
they
actually
want
is.
E
I
have
installed
a
dapp
or
I've
updated
a
depth
or
I've
removed
a
depth
and
have
that
run
your
pre
and
post
install
scripts,
which
just
make
just
takes
the
existing
ambiguity
and
makes
it
worse.
E
E
G
Is
this
going
to
overlap
a
lot
with
the
install
script
right?
Because
when
you
run
mdm
install
this
is
going
to
run.
E
Yes,
it
will,
but
it
will
also
not
run
when
you're
installed
as
a
dependency,
and
it
will
run
anytime
you
you
basically
any
time
you
call
arborist
refi,
so
any
add,
remove,
update
audit
fix
anything
that
makes
any
kind
of
change
to
the
package
tree.
Will
fire
off
this
script
mutation
observers
exactly.
H
Wes
yeah
one
use
case
now
that
you're
saying
this
approach
that
I'm
wondering
do
you
think
you
could
see
it
solving
this
as
well
would
be
the
I
have
some
internal
apis
that
I
want
to
call
before
people
install
anything
again,
not
just
a
bear,
install
but
another
package
and
then
be
able
to
inspect
the
tree.
Do
you
think
there's
a
way
and
then
make
recommendations
like
hey?
I
see
you're
trying
to
install
this,
but
like
actually
we
have
platform
recommendations
that
say
you
should
be
adding
the
previous
major
version.
H
Yet
do
you
see
exposing
the
hooks
there
or
like
anything
that
we
would
be
able
to
safely
modify
on
the
user's
behalf?
The
request
right
like
if
I,
if
I
know
that
when
they
say,
react
at
17
well,
this
app
doesn't
use
react
at
17
and
we're
positive.
We
don't
want
somebody
to
accidentally
install
that
automatically
switch
it
to
16
or
something
right
like.
E
H
Okay,
that's
an
abort
okay,
which
is
probably
reasonable.
I'm
just
you
know.
I
was
thinking
outside
the
box
and
when
you
mentioned
the
pre
script,.
E
So
the
the
what
we
could
do,
I
actually
one
of
the
things
that
came
up
last
time
we
talked
about.
This
was
like
it's
kind
of
challenging
to
get
the
the
list
of
changes
in
any
kind
of
reasonable
way,
but
I
I
think
there
may
be
a
way
to
do
it.
I
I
would.
E
I
would
like
to
kind
of
create
a
new
rfc
and
bike
shed
a
little
bit
on
that,
because
you
want
to
be
able
to
run
this
script
prior
to
the
tree
being
mutated
and
have
some
idea
of
what
mutations
are
being
made
so
because
otherwise
you
can't
do
exactly
what
you're
saying
right,
you
don't
you
don't
know
that
react.
17
is
being
installed
until
you
have
installed
it.
E
You
could
run
a
post-mutate
script
that
crashes
in
that
case,
and
then
we
have
to
roll
back
the
entire
install
it's
a
lot
more
efficient
to
just
crash
pre-mutation
right
and
then
post
mutate
scripts
could
just
be
the
case
where,
like
oh,
I
need
to
update
my
git
ignore
to
ignore
this
path,
or
this
should
be
a
bundled
depth.
So
let
me
like
make
sure
it's
there
or
something
like
that.
H
Yeah
exactly
what
I'd,
what
I'd
really
love
to
be
able
to
do
is
say
like
hey,
arborist,
here's,
here's,
a
here's,
a
file
when
I
tell
you
to
include
it,
include
it
and
then
pass
me
the
arborist
tree,
and
then
I
can
do
whatever
I
want
to
it
and
then
pass
it
back
and
then
it
would
execute.
You
know
on
with
the
rest
of
the
refi.
E
That
that
makes
every
security
clackson
in
my
brain
go
off,
because
now
I
right
point,
but
now
I
can
put
one
file
on
your
machine
that
hijacks
every
install.
I
guess
I
could
do
that
anyway,
if
I
could
put
files
on
your
machine,
but
it
is
it
is
that
is
kind
of
some
spooky
action
at
a
distance.
L
A
Supposed
to
be
mindful
time,
we
have
about
five
minutes
left
guy.
I
want
to
give
you
a
couple
minutes
or
two
just
maybe
give
a
quick
update.
If
there
is
any,
I
don't
think
there
are
days
yeah.
I
know
the
next
two
rfcs
think
there's
was
take
away
the
last
time
we
talked
about
them
for
us
to
go
essentially
backlogged
the
work
of
adding
the
ability,
the
capability
for
the
cli,
I'm
not
sure
if
we
actually
have
backlog
tickets.
Yet,
though,
so
we
can
discuss
that
offline,
backlogging
tickets.
A
To
actually
add
this
support,
because
I
think
what
we
said
was
we're
decoupled
here
from
the
actual
registry
implementation.
If
we
pass
multiple
tags
and
the
cli
supports
passing
along
multiple
tags,
at
least
in
the
case
of
pr
and
rc319,
that
that
other
registries
could
go
and
implement
this
if
they
wanted
to.
Is
that
accurate
summary
of
what
we
sort
of
talked
about
last
time,
at
least
for
319.,
that
we
could
go?
Do
this
work
and
would
be
couple
years.
G
Yeah,
the
the
no
tag
thing
we,
I
think,
are
still
on
the
how
to
declare
it
the
multiple
disk
tags
for
a
publish,
I
think
works,
maybe
out
of
the
box
and
for
updating,
there's.
No,
the
regis.
None
of
the
registries
support
that
we
basically
have
to
be
a
cli
just
batches.
Those
requests
right
and
there's
no
rollback.
E
Okay,
for
anything,
that's
going
to
be
batching
up,
multiple
requests
to
the
registry
that
that
should
be.
That
should
basically
be
a
blocker
for
us,
like
it
needs
to
be
a
single
atomic
put
to
the
registry.
Otherwise,
we
run
into
really
gnarly
race
conditions.
A
E
That's
not
matching
up.
That's
not
matching
up
multiple
rights
to
the
same
package.
Right
yeah,
that's
true!
That's
true!
Okay,
yeah,
but
that's
a
good
point.
We
should
talk
about
something
new
yeah
multi-publish
for
multiple
packages
would
be
really
really
nice,
especially
if
it
was
also
a
single
atomic
write.
A
H
A
Okay,
with
one
about
three
minutes
left
isaac,
did
you
want
to
give
a
quick
update
to
the
registry
protocol?
Can
we
land
this?
Can
we
or
was
there
any
work
that
was
left
to
be
done
here
so.
E
I
did
I
did
make
another
pass
at
this
and
and
kind
of
combed
through.
I
improved
some
of
the
examples
and
justifications
based
on
the
feedback
from
mayell
and
zoltan.
E
The
the
big
functional
thing
that
I
added,
which
I
think
is
kind
of
essential,
is,
if
you
have
a
dependency,
that
is
a
registry
specifier,
and
it
has
dependencies
that
are
just
disk
tags
or
versions
or
ranges.
Those
also
basically
have
to
be
resolved
against
the
same
registry.
You
pulled
that
thing
out
of
because
otherwise
you
can.
You
can
very
easily
run
into
naming
conflicts,
which
is
the
same
problem
that
we
have
right
now
with
installing
private
packages
from
tarballs
and
it
it
opens
the
door
for
more.
E
You
know:
name
name,
jacking
type
of
security
problems,
so
yeah,
so
that's
in
there
now
zoltan's
pushback
on
it
was
that
he
he
really
wanted
to
see
kind
of.
What
is
the?
What
he
wants
to
see
is
a
a
way
to
define
either
in
config
or
package
json,
a
like
you
know,
short
name,
which
d
sugars
to
a
particular
registry.
E
E
E
We
assume
that
that's
the
case
all
throughout
the
system,
if
we
start
being
able
to
kind
of
dynamically
or
configurably,
add
new
ones
that
that
gets
us
into
a
really
interesting
and
tricky
bit
of
a
bit
of
issues,
especially
if
it
can
be
set
in
the
package.json
file,
because
now
it
can
actually
dynamically
change.
What
those
things
point
to
as
we're
resolving
the
package
tree.
E
So
there's
there's
a
lot
of
subtlety
and
foot
guns
in
that,
but,
honestly,
like
I
think
this
particular
rfc
is
like
it
solves
the
original
problem
that
we
were
trying
to
solve
with
it,
it's
straightforward
to
implement
yeah.
I
think
that
we
should
ratify
it.
A
So
we're
at
time,
right
now
so
and
and
the
fact
that
there
was
some
like
within
last
couple
days.
There
was
a
couple
comments.
I
think.
Maybe
we
keep
it
open
for
one
more
week
is
that
is
that,
okay,
with
you.
E
A
Cool
so
appreciate
the
folks
everybody
that
jumped
on
today
apologize.
We
still
left
a
few
things
on
the
table
that
I
know
that
we're
we're
trying
to
get
to
so
I'll,
try
to
re-prioritize
those
for
next
week
but
yeah.
Thank
you
all
for
for
jumping
on
today
and
hopefully
see
you
next
week
same
time
same
place,
cheers
cheers.