►
From YouTube: Open RFC Meeting - Wednesday, Dec 2nd 2020
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.
Thank
you.
Everybody
for
joining
another
mpm,
open
rc
call.
Today's
date
is
wednesday
december
2nd,
we'll
be
following
along
the
agenda
that
was
posted
in
issue
294
of
the
npm
rc's
repo.
I
have
copied
and
pasted
the
notes
link
enough
times
that
you
should
all
have
it
and
feel
free
to
add
yourselves
to
the
meeting
notes.
Doc,
quick
reminder.
These
calls
and
all
communication
on
the
rc's
repo
and
all
the
mpm
levels.
A
Is
we
ask
that
you
please
acknowledge
and
that
you
abide
by
the
code
of
conduct
that
we
have
there
linked
from
fpmjs.com,
and
we
have
a
small
group
today,
but
I
want
to
quickly
make
a
couple
announcements
next
week
is
github
universe.
It's
happening.
I
believe.
A
Let
me
just
check
here.
I
believe
it
starts
on
the
tuesday
and
we'll
go
through
the
thursday
of
next
week.
So
that's
december,
8th
to
the
10th,
so
we
will
be
canceling
next
week's
openrc
call
and
we
will
potentially
be
considering
whether
or
not
to
do
one
more
rc
call
before
the
end
of.
A
We'll
let
folks
know
via
twitter
and
also
in
agenda
issue
itself,
hopefully
a
couple
weeks
before
it
would
happen.
One
other
quick
notes
as
well.
Here
we
continue
to
ship
the
latest
npm,
seven
releases,
usually
on
tuesdays
and
fridays.
A
A
Actually,
one
more
thing
to
be
mindful
of
the
node
project
is
running
a
binary
summit
for
the
next
two
days,
so
this
is
essentially
a
small
sort
of
working
group
collaboration
summit
on
the
concept
of
managing
and
updating
the
different
node
binaries,
and
so
I
believe
this
was
kicked
off
by
james
snell.
A
I
don't
have
the
issue
ready,
but
I
do
have
the
agenda
for
folks
if
they
like
I'll
copy
and
paste
that
in
chat,
we
can
leave
them
in
the
meeting
notes
but
yeah
folks,
if
they're
interested
feel
free
to
reach
out.
If
you'd
like
to
join
this,
we'll
be
discussing
sort
of
the
future
of
managing
non-binaries.
A
I
believe
folks
from
versailles.
I
think
it's
personal
folks
behind,
I
believe
it's
next
js
are
are
involved
as
well
as
some
of
the
package
manager
and
maintainers
are
gonna,
be
there
as
well
so
good
opportunity
to
discuss.
You
know
that
ecosystem
yeah.
I
think
that's
it
for
announcements
so
quickly.
If
you
want
to
move
forward
into
the
agenda
here,
we
have
issue.
The
first
item
here
is
issue
number
287,
the
rfc
for
add
no
voice
option
for
workspaces.
A
I'm
on
sure,
if
anybody
else
has
looked
at
this
in
the
last
last
week,
or
so
I
think
the
yeah.
The
action
from
this
was
essentially
that
we
want
to
do
a
deep
dive
on
hoisting
and
strategies.
Potentially,
we
could
do
that
before
the
end
of
the
year.
My
only
concern
is
that,
with
holidays
and
with
vacation
time,
I
know
that
we're
getting
less
and
less
folks
joining
calls.
So
potentially
we
might
want
to
punt
that
deep
dive
conversation
until
the
new
year.
I
also
wanted
to.
A
C
But
I
think
early
january
is
probably
going
to
be
a
better
time
for
the
time.
A
Can
you
just
take
the
note
that
I'll
create
a
maybe
a
poll
for
this?
Oh
looks
like
jordan's
jumping
on
I'll,
create
like
a
poll
for
this,
to
determine
a
good
time,
probably
in
the
new
year,
for
for
a
deep
dive
on
on
sort
of
strategies
and
or
this
flag,
and
by
that
time
I
should
have
the
rfc
written
as
well.
D
Was
that
the
hoisting
one
yeah
yeah
yeah
did
I
miss
some
discussion
on
it?
Sorry.
A
No,
we
were
just
saying
that
this
was
something
that
we
wanted
to
do
at
deep
dive
on.
So
we
were
planning
deciding
to
plan
essentially
like
a
meeting,
probably
in
the
new
year
to
have.
D
D
Causing
all
dependencies
at
the
root
to
be
available
to
work
spaces
is
a
bug
farm
and
is
never
what
people
actually
want.
Even
though
it's
the
way
node
modules
behaves,
and
I
think
that
it
would
be
really
nice
if
workspaces
came
up
with
an
alternative
way
to
share
dependencies.
That
didn't
also
inflict
that
node
modules
hierarchical
implicitness
on
workspaces
right
and
then.
D
A
Cool,
so
moving
on
from
that,
we'll
essentially
take
the
action
to
to
yeah.
If
we
can
just
note
that
we'll
we'll
essentially
do
it
there
yeah
that's
great,
so
moving
on
to
pr
number
279,
the
rc
for
the
default
command,
which
I
know
last
last
week,
isaac
mentioned
he
had
sort
of
walked
back.
A
I
think
this
concept,
our
idea
and
we,
I
think
if
my
memory
is
correct
here,
we
also
decided
that
you
know
there
was
an
opportunity
for
us
to
improve-
and
I
think
isaac
said
as
much
here
in
his
comment
in
the
last
hour
and-
and
I
see
that
also
jordan-
you
responded
to
that.
That's
essentially,
you
know,
there's
an
opportunity
here
to
improve
the
default
experience
without
having
to
create
like
a
mechanism
that
can
be
configured
for
what
the
default
behavior
is.
A
D
C
E
Yeah,
I
think
what
someone
also
came
up
with
was
like
a
shorthand
binary
like
npr,
which
would
just
be
like
a
shorthand
for
npm
run
script,
which
I
think
is
not
yet
mentioned
in
the
discussion
there.
The
question
a
bit
is
like:
is
it
worth
the
effort?
How
much
effort
is
it
to
maintain
another
binary.
A
Yeah,
so
that's
a
a
good
good
discussion
point
there's!
Actually
you
know
we
may
have
talked
about
that
like
tomorrow
or
or
in
the
next
couple
days
at
the
binary
summer
that
they're
having
that
we're
gonna
have
like.
Essentially
in
the
note
project
yeah
like
maintaining
in
another
binary,
I'm
guessing
this
maps
would
map
one-to-one
with
npm
run
similar
to
the
way
that
npm
or
mpx
maps
one-to-one
with
npm
exec.
A
We
don't
want
to
actually
maintain
a
separate
depth
dependency
here,
like
we
did
with
mpx,
and
I
think
historically,
the
only
reason
why
that
was
created
as
far
as
I
could
find
from
docs
was
originally
because
we
didn't
know
if
we
were
actually
going
to
pull
that
into
npm.
That's
why
mpx
like
became
a
separate
dependency
but
yeah,
potentially
shipping
an
npr
bin
is
an
option.
I
think
that's
a
separate,
separate
rfc
though,
and
I
think
I've
I've
noted
before
that.
A
That's
something
that
probably
I'll
take
some
time
to
bring
to
the
floor
and
ask
if
it's
something
we'd
want
to
do.
We
also
just
don't
want
to
start
stealing
all
like
the
name
spaces
for
potential
bins
like
I
don't
think
that
makes
sense
either.
This
might
be
one
of
the
one
case
that
would
make
maybe
make
sense,
since
people
just
tend
to
really
not
want
to
write
the
word
rotten
for
whatever
reason.
A
I
see
a
few
folks
have
jumped
on
and
I'm
just
going
to
copy
and
paste
the
meeting
notes
again,
so
I
know
that
zoom
chat
doesn't
usually
show
your
history
so
feel
free
to
add
bradley
jordan
isaac
feel
free
to
add
yourselves
to
the
meeting
notes.
We
have
small
agenda
today
so
also
leave
lots
of
time
at
the
end
here
for
any
discussions
or
topics
that
may
not
have
been
put
on
the
agenda
as
well.
A
So
currently
we
were
just
discussing
pr
number
279,
so
the
the
default
command
as
like
I
saw
you
added
some
notes
there
not
sure
if
you
want
to
speak
to
it
at
all.
B
Yeah,
I
did
add
some
notes.
I
think
the
kind
of
the
status
of
this
implementation
is
very
easy.
Some
pretty
significant
hazards
that
we
don't
really
have
great
answers
for.
So
really,
I
think
where
it's
where
it's
sitting
is.
B
We
should
definitely
just
make
npm
help
search
a
little
smarter
and
have
it
show
you
if
there
are,
if
there's
a
a
run
script
option
for
the
thing
that
you
typed,
that
may
just
like
make
the
problem
go
away
and
it
can
just
kill
this
or
it's
probably
just
going
to
sit
in
limbo
until
somebody
comes
out
of
the
woodwork
and
says
yes,
I
really
really
want
that,
because
essentially
it's
just
sort
of
a
lot
of
us
trying
to
imagine
ourselves
wanting
a
thing
that
we
don't
actually
need
or
or
want
so
yep.
F
A
Do
that
right
now,
so
moving
on
to
issue
2.5.
So
again,
this
is
the
our
our
rfc
for
the
registry
protocol.
I
just
think
that
the
the
last
last
time
we
talked
about
this
there
was
the
action
item
just
to
make
this
into
a
proper
rfc.
I
don't
think
you've,
probably
gotten
any
time
in
the
last
week,
isaac
so,
but
I
do
see
that
there's
a
staff
update
did
you
want
to
maybe
speak
to
the
note
you
made
it
here
about
an
hour
ago.
B
Yeah,
so
the
the
main
thing
is
that
second
colon
there
in
the
which
you
can
see
in
the
description
in
the
title
of
the
the
request
for
the
rfc,
that
should
really
be
a
hash
sign
just
to
make
the
url
parsing
a
little
bit
easier,
but
other
than
that.
It's
really
no
objections
were
were
raised
about
it.
So
it's
kind
of
just
a
matter
of
doing
the
work
to
make
it
happen,
and
it's
pretty
straightforward
work,
albeit
a
lot
of
it.
B
So
again
I
mean
I
I'm
not
sure,
there's
too
much
more
to
discuss
we
just
kind
of
need.
We
have
the
action
item
to
write
an
rfc
and
then
we'll
probably
ratify
it
really
quickly
and.
C
Any
word
from
some
other
of
the
package
maintainers.
Maybe
we
should
poke
some
of
them
just.
A
B
B
A
And
and
yarn,
especially
when
it
comes
to
like
anything,
that's
like
a
protocol
like
that
like
this
is
this
is
going
to
work
similar
to
aliasing
right.
B
B
The
the
view,
the
vision
there
is
basically,
this
will
be
what
npm
colon
sort
of
de-sugars
to
so
all
of
the
places
where
we're
handling
aliases
will
will
basically
just
have
to
handle
account
for
the
fact
that
an
alias
might
also
specify
a
different
registry
and
essentially
treat
it
the
same
way
within
the
code
right
since
you
can
have
now.
You
can
have
something
that's
like
resolved
with
a
name
that
isn't
the
name
that
it
actually
lives
under
in
the
package.
A
Tree,
I
think
this
is
definitely
something
we
want
to
like
move
forward
with
early
in
the
new
year.
Any
other
comments
on
that
nope.
A
Okay,
moving
on
then
to
the
the
last
item.
We
have
and
then
I'll
open
up
the
floor
to
folks
that
may
want
to
bring
up
other
topics.
This
is
pr273,
so
this
is
the
workspace
I
guess
like
b3,
the
third
sort
of
rfc
around
workspaces.
I
think
this
was
a
holdout
from
last
week.
We
can
probably
remove
the
agenda
label
on
this
right
roy
unless
there's
something
new.
Oh,
I
see
actually
christian
added
a
comment
here
in
the
last
hour,
not
sure
if
you
want
to
speak
to
that.
E
Yeah
not
sure
well.
Well,
I
in
general,
I
find
difficult
to
say
what
is
needed
and
what
is
not.
I
think
learner
provides
a
nice
sort
of
base
set
here.
However,
it's
also
difficult
because
we
like
definitely
don't
want
to
re-implement
learner
right
and
some
of
the
things
I
came
across
were
like
something
like
an
init
command,
which
would
just
like
give
you
a
one-stop
shop,
access
to
yeah
initialize,
a
workspace,
and
another
thing
I
thought
of
was
something
like
for
each.
E
However,
that
would
not
be
config
management,
so
this
doesn't
really
fit
here.
C
Yeah,
maybe
some
more
context
now
that
christine
mentioned
like
we
actually
do,
want
to
implement
some
parts
of
learner,
but
not
everything
so
yeah,
one
of
the
things
that
when
we
had
the
first
conversation
with
daniel
from
learner,
one
of
the
things
we
really
want
to
focus
on
is
more
on
the
published
workflow
and
that's
something
that
we
don't
want
to
focus
on.
So
we
probably
won't
touch
that
part
for
a
very
good
time.
I
guess,
but
the
more
basic
kind
of
management
workflows.
C
A
Okay,
I
mean
I'm,
I'm
definitely
okay
with
using
the
rest
of
our
time.
I
know
we
have
about
a
half
hour
here
if
we
want
to
go
and
review
sort
of
the.
I
see,
as
I
said,
sort
of
doing
a
deep
dive
on
workspaces
today
would
be
good,
since
we
have
such
a
shallow
agenda.
A
G
A
A
Yeah,
so
we
do
have
like
the
I'm,
not
sure
if
you've
seen
recently,
we
opened
up
a
new
feedback
mechanism
like
mechanism.
Essentially,
so
if
you
go
to
github
npm
feedback,
it
might
be
a
good
way
to
like
kick
off
that
conversation.
Unless
you
have
like
something
something
like
specific
to,
maybe
like
the
rfc
process
and
or
like
the
npm
client
specifically
well,.
G
Is
that
what
you're
thinking,
I
think,
I
think
the
problem
for
me
is
we
need
to
standardize
across
package
managers,
so
all
right,
so
rfc
could
work
with
that.
A
Sorry,
I
I
I
know
what
you
mean
by
policies
now
you're
talking
about
like
the
the
work
that
you've
been
doing
with
node
like
for,
like
the
policy
sort
of
schema
and
the
files
yeah
right
right
right,
that's
a
little
bit
different.
I
thought
you
were
suggesting
more
like,
like
like
registry
policies
like
unpublished
policies,
not
policies
at
like
the
programmatic
level,
so.
A
So
we've
been
quite
active,
or
at
least
I
know
myself
and
and
roy
to
some
extent
have
been
coming
to
the
package
maintenance
working
group
sort
of
as
a
a
forum
that
we
find
to
be
sort
of,
like
you
know,
yeah,
what's
the
right
term
for
that,
like
a.
A
Yeah
sorry,
neutral,
neutral,
ground
and,
and
that's
sort
of
where
I
think
is-
it-
is
a
good
opportunity
to
bring
up
something
like
that.
I
know
that
I
think
the
recommendation
is
is
something
along
and
you
can
correct
me
or
point
us
in
the
right
direction.
They're
about
the
the
recommendation
is
a
field
for
like
a
package
permissions,
or
I
forget
the
name
of
the
field.
A
It's
like.
I.
G
A
A
C
There
is
some
experimental
work
that
landed
right
around
policy.
H
G
A
Right
so
it's
truly
getting
the
the
package
manager
to
adopt
and
respect
like
this
spec
and
these
fields
that
are
proposed
here.
A
Yeah
yeah,
if
you
start
an
issue
there,
and
that
will
will
definitely
be
there.
I
think
the
harder
part
has
been
trying
to
get
other
other
folks
to
join
like
from
yarn
and
pmpm
folks,
so
I'm
definitely
willing
to
like
coordinate
on
that.
We're
we're
also,
as
you
might
have
heard
like
we,
we
want
to
like
pull
in
before
we
like,
introduce
something
like
a
registry
protocol
on
our
end,
be
good
to
have
mile
and
zoltan
from
from
the
other
package.
Managers
essentially
have
a
say
in
that.
A
I
think
it'd
be
good,
that
we
try
to.
A
Much
as
possible,
so
yeah
appreciate
you
bringing
that
up
yeah
in
terms
of
any
other
topics.
B
Yeah,
I
have
a
well.
I
actually
have
a
question
on
this
thing
around
policies.
I
had
taken
a
look
at
this
and
I
didn't.
I
didn't
see
much
that
that
a
package
manager
would
have
to
do
differently
around
it.
I'm
curious
bradley
kind
of
from
your
point
of
view
is
there?
Is
there
some?
I
mean
it's
entirely
possible
that
I
just
kind
of
skimmed
it
and
missed
it.
B
So
I'm
I'm
kind
of
wondering
from
your
point
of
view
like
what
is
the
what's
the
buy-in
that
you
think
package
managers
need
to
have
or
like
what,
and
it
could
be
that
it's
sort
of
missing
from
this,
because
you
don't
have
that
buy-in
and
I'm
just
curious
if
there's
something
that
we
could
maybe
get
started
on
evaluating
like
to
make
that
more
productive.
G
Yeah
I
can
there,
there
are
multiple
levels
of
support.
We
could
look
at
doing.
Probably
the
big
one
is
like
there
was
a
blog
post
on
an
incident
about
a
malicious
package
today
and
if
you
were
to
install
that
policies
could
have
prevented
at
least
the
access
to
the
child
process
module
built
in
and
if
that
had
happened
at
install
time,
it
would
have
prevented
at
least
today's
particular
thing
so
really
we're
talking
about
at
install
time,
using
this
configuration
file
and
updating
it
to
match
what
you're
installing.
G
So,
when
we're
using
npx
today
it'll
list
what
modules
are
being
installed,
but
this
would
be
a
capability
to
list
hey
they're
about
to
use
these
potentially
dangerous
built-in
apis.
When
you
install
this.
B
Right
so
it
might
be
like
a
just
kind
of
flushing
that
out
like
it
might
be
like
a
a
prompt
before
we
run
a
script
or
a
bin.
To
like
ask
the
user
to
approve
the
use
of
like
fs
or
child
process
or
whatever.
G
Yes
and
then,
when
they
do
that
the
policy
mechanism
can
constrain
the
ability
of
modules
to
be
accessed,
and
so,
if,
for
some
reason
in
your
package.json,
you
don't
list
a
child
process,
you
could
not
access
child
process
from
that
module.
G
B
Yeah,
that
could
definitely
I
mean
I
could
okay,
so
that
that
does
make
it
more
clear.
Then
thank
you
where,
where
the
package
manager
might
get
involved
because
it'd
be
pretty
disruptive,
if
everything
just
stopped
working
in
npx
on
some
version
of
node
right,
because
when
that's
released,
we
can
assume
nobody
has
policies
like
defined
or
whatever,
and
we
certainly
don't
want
to
say
well.
F
F
B
Definitely
bring
it
up
in
the
in
the
package,
manager
or
package
maintenance
working
group.
I
think
that
that
is
kind
of
the
right
next
step.
I've
we've
certainly
so
we
have
had
some.
You
know
like
ideas
or
or
calls
for
in
the
past
a
way
to
a
way
to
define.
Like
you
know
what
things
does
this
module
try
to
do
at
install
time,
but
we've
there's
been
a
little
bit
of
work
kind
of
in
the
security
space
around
like
what
you
know.
B
We
we
install
something
in
a
like
a
private
container,
that's
very
locked
down,
and
then
we
check
if
it's
like
trying
to
access
networking
or
file
system
or
whatever
and
have
caught
quite
a
bit
of
malware
via
that
that
method.
But
what
could
be
really
interesting
is
like
I
don't
know
when
you
install
something
it
sort
of
halts
and
prompts
the
user.
The
downside
is
okay,
but
we
can't
do
that
in
ci.
B
We
can't
do
that
when
it's
not
a
tty
and
so
on,
and
we
would
have
to
cache
that
somewhere
to
say
well
you've,
given
this
thing
permission
in
the
past,
and
now
we
don't
have
to
prompt
you
every
time,
you're
running
your
tests
or
building
your
js
or
whatever.
A
I
searched
quickly
because
I
I
saw
a
tweet
on
this
a
while
back
and
and
this
will
be
the
last
note
I
have
on
this
thread,
but
I
saw
that
you
posted
something
along
the
lines
of
requested
permissions
as
being
a
field
bradley,
which
I
thought
was
actually
pretty
like
pretty
nice,
but
yeah.
We
can
definitely
unearth
like
the
how
how
this
could
actually
play
out
and
yeah
definitely
think
it's
it's
useful.
B
It
might
also
be
useful
to
surface
on
the
on
the
registry
or
the
or
the
npm
website
like
these
are
the
things
that
you're
going
to
be
prompted
for.
If
you
install
this,
I
think
this.
D
D
Oh,
I
want
to
see
what,
in
my
dependency
graph,
has
a
good
license
or
a
bad
license
depending
on
my
config,
and
I
similarly
could
say
well
what
in
what,
in
my
dependency
graph
like
what
is
in
my
runtime
dependencies
that
accesses
child
process
like
you
know-
and
it
would
also
be
interesting
if
a
package
could
say
that,
like
that,
the
it's
runtime
behavior
needed
certain
access,
but
it's
post
install
script
needs.
This
needs
different
access,
because
some
things
are
going
to
want
that.
D
Like
it,
you
know,
they'll
need
to
compile,
and
that
needs
certain
kind
of
post
install
access.
But
then
they
won't
need
any
of
that
access
at
runtime.
You
know
being
able
to
like
differentiate.
That
is
probably
also
useful
for
sure,
but
like
auditing,
your
graph,
essentially
to
determine
where
you
need
to
go
pr
in
some
policy
lists.
A
Awesome
cool,
so
if
we
want
to,
we've
still
got
about
20
30
minutes
here,
25
minutes
left,
we
could
do
a
bit
of
a
deep
dive
into
workspaces.
A
This
is
something
that
we've
had
hanging
open
for
a
while
now
and
we
want
to
get
started
early
into
the
new
year
with
work
around
this.
I
think
potentially
it'd
be
good
even
just
to
to
start
like
a
hackmd
dock,
which
I
I've
got
going
here
and
I
can
share
about.
You
know
the
proposed
I
think
api
and
for
I
think
I
think
what
we
would
want
to
do
is
talk
about.
A
You
know
how
this
looks
and
how
it
interacts
with
workspaces
and-
and
what
I
mean
by
that
is
the
and
I'll
share
the
rfc
itself
that
was
made
by
roy
essentially
running
commands
against
workspaces
and
and
being
able
to
filter,
filter
those
workspaces
and
and
how
to
essentially
like
what
what's
the
expected
result.
And
how
does
this
look.
A
Can
erasing
my
screen
yeah,
there's
nothing
crazy,
sensitive
on
here,
yet
awesome
so
yeah.
I
thought
we
we
could
go
through
this
and
see
where
you
know
we
still
have
some
decisions
to
make
or
feedback
to
give,
since
this
is
something
we
we
definitely
want
to
like
make
improvements
to
workspaces
starting
early,
jan
or
as
soon
as
we're.
We
feel
you
know
confident
that
we've
gotten
over
a
lot
of
the
hairy
bugs
and
and
sort
of
v7.
A
I
think
maybe
right
you
probably
have
the
context
of
where
we've
landed
on
this.
Yes,.
C
A
C
Pick
up
some
of
it,
the
the
one
thing
I
have
on
top
of
my
mind
right
now
from
where
we
left
the
discussion
last
time,
is
that
jordan
brought
up
one
point
in
the
about
groups
and
having
like
groups
of
workspaces
together,
and
I
remember
jordan
brought
the
point
that
he
would
like
to
have
a
way
to
also
define
them
in
the
command
line,
but
that's
something
we
were
kind
of
reluctant
to
add
any
like
glob
pattern
in
the
clay
like
would
like
to
support
it
only
on
the
package
jason.
D
D
So
I
can
see,
what's
going
to
publish
I'm
going
to
be
able
to
want
to
be
able
to
run,
you
know
an
arbitrary
command
that,
like
you
know,
audits
like
that,
like
modifies
my
markdown,
my
readme.md
file
or
something
like
like,
so
it
it's
just
not
going
to
work.
If
it's
limited
to
a
subset
of
commands,
it's
fine
if
you
say
that
like
there's,
50,
npm
commands
and
only
20
of
them
make
sense
to
run
in
work
cases.
D
That
seems
totally
reasonable,
but
there's
always
got
to
be
this
everything
escape
hatch,
where
I
can
do
something
and
do
whatever
I
want,
but
run
it
in
each
workspace,
because
it's
the
iteration
the
for
each
that
christian
was
mentioning
the
other
day
or
the
other.
You
know
discussion
about
like
that's.
What
I
need
to
be
able
to
do
is
I
want
to
abstract
a
way,
go
into
each
workspace
and
do
a
thing
essentially.
D
You
it's
sort
of
like
it
does,
but
it's
it's
unergonomic,
I
think,
to
have
to
sit
to
use
npm
exec
to
run
like
cat
or
a
git
command
in
each
workspace,
because
I'm
not
using
npm
exec
to
run
it
bare
on
the
terminal.
I'm
just
typing
the
command.
E
E
So
git
sub
module
for
each
does
exactly
that,
and
I
think
something
like
for
each,
which
would
even
be
called
the
same
as
what
you
have
in
git
sub
modules
would
do
exactly
what
jordan
wants.
D
C
D
But
I
think,
but
separately
I
like
what
christian's
talking
about.
I
would
love
to
bike
shed
the
name
not
now
on
this
call,
but
but
but
the
semantic
is
exactly.
I
think
what
I
want,
as
christian
indicated.
A
C
Oh,
it's
yeah
it's
using
the
options
there,
so
it
would
be
like
that
w
and
then
no
just
just
ntm,
exact
yeah,
then
the
dash
w
can
go
anywhere
right
like
and
just
the
name
of
the
workspace
or
group
of
workspaces
right.
C
And
then
whatever
command,
you
want
to
run
so,
but
I
see
projects
what
yeah,
but
I
see
the
syntax
christian
talking
about
here.
It
could
be
more
ergonomic
to
just
have
a
quick
way
to
run
something
in
all
workspaces
right.
C
D
C
Support
there
yeah,
I
think
it
does
fit
well
with
the
proposition
there.
It's
just
something
more
right
like
an
additional
api,
so
that
we
it's
easy
to
just
run
something
across
all
right,
yeah.
No,
it
might
be
the
darcy
it
might
be.
The
storage
is
a
good
name.
I
don't
I
don't
know
I
haven't
given
it
any
spot
yet,
but
no.
B
D
C
C
Yeah
the
workspace,
config
config
kind
of
argument.
We
landed
on
the
rfc.
Yet
now
it's
good,
because
it's
just
giving
like
the
standard
commands
like
the
the
feeling
that
the
workspaces
are
really
like
butane
now
such
that
you
can
just
specify
their
name
and
just
run
a
command
in
it
right.
But
it
was
more
targeted
to
that
use
case
and
not
so
much
in
the
use
case
of
running
something
across
all
ones.
D
I
don't
know
if
comma
separated
works,
because
commas
could
be
in
file
names,
but
like
the
the
okay
I
mean,
but
the
reason
I'm
bringing
that
up
is
because
then,
if
you
omit
an
argument,
if
you
just
say
dash
workspaces
by
default,
it
runs
everywhere,
and
if
you
then,
whereas
if
you
constrain
it,
you
say
where
these
these
work
spaces,
then
you
give
the
ability
to
without
supporting
globs.
It
would
either
be
a
single,
a
list
of
single
workspaces
or
a
list.
D
It
would
be
a
list
of
either
single
workspaces
or
alias
names.
Yeah.
B
D
B
B
A
list
in
the
cli
config
is
just
specify
it
multiple
times,
so
it
wouldn't
be
a
comma
delimited
like
we
don't
need
a
bike
shot
on
the
delimiter
here.
It
would
just
be
dash
dash
workspaces
equals
food
dash,
dash
workspaces
equals
bar.
That's
just
works
with
blah
blah
blah,
so
we
probably
want
something
a
little
shorter.
B
D
B
C
B
That
that
will
resolve
to
dash
w
true,
and
we
don't
want
it
to
be
both
a
flag
and
an
array
of
strings.
D
D
Here
like
what
what
is
gonna
be
most
clean
for
users,
both
even
the
ones
who
have
to
put
things
in
the
config.
But
I
guess
maybe
that's
what
you're
talking
about
that's.
B
Exactly
what
I'm
talking
about,
I
think
I
mean
we're:
we're
we're
bike,
shedding
kind
of
the
the
cli
design
and,
from
that
point
of
view,
like
yeah,
no,
we
I
don't
it's
not
good
to
have
a
thing
that
is
both
a
multi-specified
list
of
strings
and
a
boolean
flag
with
under
the
same
field.
It's
we
have
a
few
of
those
and
it's.
F
Horrible,
so
taking
one
step
back
and
maybe
also.
A
Don't
want
to
derail
like
this,
because
I
also
do
think
it's
it's
helpful
that
we've
even
just
uncovered
like
this,
but
in
terms
of
doing
things
synchronously
versus
asynchronously.
A
That's
another
like
consideration
that
I'm
not
sure
if
we
have
currently
like
parallelization
like
is
that
accounted
for
here
in
the
current
rc.
Is
that
something
that
we
want
to
consider
as,
like
you
know
a
flag
like
like
how
do
we
want
to
approach
that.
D
But
I
want
the
output
interleaved
and
I
want
the
overall
exit
code
to
be
intuitive,
based
on
the
exit
code
of
the
individual
commands,
literally,
the
only
two
things
that
I've
seen
in
the
entire
ecosystem
that
do
this
properly
and
reliably
are
just
in
lerna.
There's
some
program.
There's
some
packages
like
concurrently
and
parallel
shell
that
are
not
reliable
and
do
not
work
well
and
like
I
have
had
them
pass
ci
when
they
shouldn't
have
before.
D
For
example,
it's
a
big
ask
to
try
and
pull
that
paralyzed
parallelizable
command
running
and
output
interleaving
into
npm,
but
if
we
find
a
way
to
do
that,
that
would
really,
I
think,
be
the
difference
between
like
how
delightful
this
feature
is
versus
it's
just
a
nice
low-level
ability
right.
C
Ahead
and
run
maybe
to
just
pick
up
the
syntax
bike
sharing
there,
but
we
already
did
a
lot
of
work
like
we
had
the
poll
before
when
we
have
some
documentation
in
the
rfc
there.
So
like
we
kind
of
decided
to
not
go
with
the
top
level
s
for
this
kind
of
thing,
but
nothing
is
nothing
that
is
saddle
stone,
but
just
also
maybe.
B
It
simplifies
so
much
of
like
how
we
actually
present
this
to
users
and
how
to
differentiate
between,
like
I'm
doing
a
thing
versus
I'm
doing
a
thing
in
a
workspace
or
multiple
workspaces,
I
mean
we
kind
of
already
have
all
the
all
the
config
machinery
there
like.
B
B
Well,
it
doesn't
it's
not
just
the
implementation,
it
simplifies
the
interface
which
you
know
if
you
think
about
like
I
tend
to,
I
tend
to
use
as
a
proxy
for
like
how
hard
is
something
to
understand.
B
I
tend
to
use
the
like
how
hard
is
it
to
document
and
if
we
have
to,
if
we
have
to
go
through
all
of
our
all
of
our
commands
and
say
well,
if
you
do
dash
w
on
this,
then
it'll
run
it
on
the
sub
command
versus
having
to
just
document
it
in
one
place,
which
is
like
you're
running
npm
ws.
This
is
like
these
are
the
sub
commands
that
will
be
run
and
it
will
run
this
command
in
those
workspaces.
B
It's
like
it
kind
of
gathers
everything
under
one
umbrella
that,
from
there
we
have
npmws,
is
the
command
for
doing
stuff
to
workspaces
and
ws
can
take
this
set
of
of
second
arguments.
They
can
run
exec,
you
can
run
ad,
it
can
run
ls.
You
know.
B
D
D
You
can
make
all
the
workspace
prefixed
commands
when
there's
no
workspace
config,
you
can
make
them
just
do
the
thing
in
the
current
package
and
that's.
F
D
H
A
Okay,
just
to
be
mindful
of
time,
we
have
about
five
minutes
left.
So
is
there
any
other
actions
we
could
take
here
to
to
clean
up
the
initial
rfc?
Just
so
it's
reflected
some
of
this
stuff
is
reflected.
I
know
where
you've
been
editing
and
keeping
up
to
date
with
us.
B
A
Since
it
got
added
after
this,
rfc
was
created,
but
in
terms
of
the
go
forward
top
level
hazard,
just
adding
notes
here,
I
guess.
C
Yeah,
just
adding
some
notes,
because
I
think
this
is
the
probably
important
take
away
from
this
last
conversation.
If
we
want
to
to
change
the
way
we
were
driving
the
proposal
there,
I'd
like
to
document
it
again
because
yeah,
if
you
scroll
back,
is
this
beginning
of
filter
yeah
that
number
two
there.
C
Why
yeah?
Why
do
we
that
argument
thing
but
then
like
if
we're
doing
it
the
other
way,
we
should
probably
document
the
reasons
why
we're
doing
yeah.
B
Well,
and
so
the
I
mean
polls
are
great,
I
don't,
I
don't
think
it's
a
bad
thing
to
do,
but
if
we,
you
know
we
shouldn't
kind
of,
we
should
take
them
with
a
grain
of
salt,
because
when
you're,
when
you're
filling
out
a
pole,
you're
kind
of
imagining
like
what
is
the
you
know,
what's
the
one
that
seems
most
like,
I
would
guess
in
my
first
my
first
pass
here
with
it,
which
might
not
be
the
smartest
thing
right.
B
It
might
not
actually
be
the
one
that
is
going
to
be
the
least
hazardous
or
kind
of
the
most
intuitive.
When
you're
then
going
through
and
reading
a
script
and
having
to
know
like
what
is
this,
you
know
I
I'm
looking
at
like
a
dot,
github,
slash
workspaces,
slash
food.yaml,
like
what
is
this
thing
actually
running?
B
It's
it's
not
clear
that
npm
exec
will
run
against
all
my
workspaces
because
there's
a
npmrc
file
like
we
kind
of
have
all
of
these.
You
know
that
specifies
us
some.
Some
workspace
commands
like
if
we,
if
we
put
these
things
in
configs,
they're
kind
of
not
clear
at
the
spots
where
you
need
them
to
be,
and
I
don't
imagine
that
somebody
filling
out
a
poll
quickly
would
have
a
full
kind
of
appreciation
for
that.
A
Okay,
that's
good
good
use
of
our
our
time
here.
I
think,
as
I
know
it
before
a
few
folks
jumped
on
next
week's,
actually
github
universe,
so
we
probably
won't
run
a
open,
rc
call,
given
the
fact
that
the
the
two
time
slots
overlap-
and
I
guess
another
announcement
there-
is
that
our
colleague
miles
burns
will
be
doing
a
talk.
A
I
give
in
universe
about
npm
so
definitely
feel
free
to
to
book
and
and
carve
out
some
time
to
watch
his
talk,
and
we
will
be
for
sure
as
well
ourselves
we'll
take
away.
I
guess
these
three
action
items
roy
it'd
be
great.
If
we
can
update
the
the
this
roc
again,
it's
definitely
as
I've
said
before
something
we
want
to
start
tackling
in
the
new
year
and
so
the
more
we
can
get.
A
You
know
some
general
consensus
about
how
this
is
going
to
be
how
it's
going
to
work.
Then
you
know,
I
think
the
more
people
are
going
to
appreciate
and
actually
start
adopting
and
using
it.
I'm
very
interested
in
in
sort
of
the
paralyzation
conversation
like
how,
if
we
get
it
right,
we'll
make
jordan
happy
and
that's
a
good
thing
so,
but
yeah,
I
appreciate
everybody
jumping
on
again
today
feel
free
to
continue
to
edit.
This
talk
if
you'd
like
I'll
leave
it
open
for
a
bit
here.
A
I
copied
and
pasted
the
the
hackmd
reference
there
in
chat
and
we'll
be
posting.
The
the
meeting
notes
quickly
after
this
and
appreciate
everybody
jumping
on
today
feel
free
to
keep
giving
feedback
and
open
up
our
seas
in
the
rfc's,
repo
and
yeah.
We'll
talk
to
all
y'all
async
between
now
and
our
next
call.
So
thanks
ciao.