►
From YouTube: Open RFC Meeting - Wednesday, Nov 25th 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,
welcome
everybody
to
another
npm,
open
rfc
call
today's
date's
wednesday,
wednesday
november
25th
we're
going
to
be
following
along
in
the
hackending
talk
that
I
will
copy
and
paste
here
for
you
to
add
yourself
to,
and
the
original
rfc
issue
for
this
agenda
was
created
in
issue
number
293.
A
apologize
for
getting
the
agenda
up
late,
so
I
think
we
have
a
little
bit
lower
attendance
than
usual,
also
because
the
holiday,
as
was
known
before
the
call
so
just
quick
reminder
of
these
calls,
we
ask
that
you
please
be
kind
and
and
that
you
follow
their
code
of
conduct
on
the
calls
and
also
in
the
rc's
repo
themselves
and
depending
on,
if
more
folks,
don't
jump
on
today
might
be
a
quick
call.
A
Our
agenda
looks
very
similar
to
last
week's
as
well,
so
we
might
be
able
to
go
into
these
and
and
maybe
give
some
feedback
in
real
time
and
want
to
open
up
the
floor
also
for
for
any
announcements.
If
there
are
right
now.
A
I
guess
the
one
announcement
is
that
there
is
holidays
coming
up
this
week,
so
I
know
that
a
lot
of
folks
are
out,
including
some
folks
on
our
team,
so
we
may
not
have
the
regular
3-4
releases
in
a
week.
We
might
only
have
one
or
two,
so
you
know
expect
expect
a
little
bit
of
a
slowdown
over
the
next
two
days
or
next
couple
days,
but
I
think
a
few
of
us
canadians
will
still
be
online,
so
we
will
be
around
awesome,
so
kicking
things
off.
A
The
first
issue
that
was
actually
on
here
was
an
item
that
we
took
a
lot
of
time
for,
in
last
week's
session,
issue
287
the
rfc
for
adding
the
no
voice
option,
which
is
essentially
a
config
that
yarn
supports
today.
I
think
if
I
can't
remember
where
we
left
off,
I
don't
believe
we
want
to
support
this,
as
is-
and
I
think
that
might
have
been
the
sentiment
I
was
picking
up
on
last
week
and
that
we
would
like
to
do
a
deep
dive
is
that
is
that
accurate?
B
From
christian,
yes
yeah,
I
think
it's,
I
think
it
might
be
worth
digging
into
that
a
little
bit
deeper,
but
I,
I
also
feel
like
the
the
the
actual
like
decision
to
be
made.
There
is,
is
still
a
little
bit
premature.
While
we're
you
know
kind
of
sorting
out
some
some
basic
behavior
stuff
around
workspaces
but
yeah.
I
could
suggest
a
sort
of
a
a
plan
if
that
makes
sense.
A
Yeah
like
I,
so
I
guess
I'm
I'm
just
wondering
like
because
on
the
last
call
I
kind
of
was
trying
to
get
gauge
whether
or
not
we
wanted
to
implement
this,
as
is
like,
as
is
implemented
in
yarn,
and
it
didn't
seem
like
that,
like
that's
I'm
trying
to
like
say
like,
should
we
open
another
topic
specifically
for
hoisting
and
and
strategies
versus
keeping
this
open
for
now,.
B
You
know
the
positively
worded
hoist
option,
or
or
even
like
strategy,
option
yeah
yeah.
I
think
that
would
be
that
that's
kind
of
what
I
was
going
to
suggest.
If
we
just
care
about
hoisting,
it
should
be
an
option
where
the
the
default
is
true.
You
can
set
it
to
false
or
you
can
set
it
to
an
array
of
things
that
should
be
hoisted,
in
which
case
nothing
else
will
be
hoisted.
B
However,
if
we
also
wanted
to
say
well,
this
workspace
needs
to
be
installed
with
global
style,
and
this
workspace
needs
to
be
installed
with
legacy
bundling,
and
this
workspace
needs.
You
know,
ignore
peer
deps
like
legacy
peer,
deps
or
or
whatever.
Then
I
think
that
gets
a
little
bit
more
interesting
and
does
sort
of
suggest
like
a
a
strategies,
object
where
you
can
specify
a
particular
workspace
and
then
what
strategies
it
should
be
using.
A
Interesting,
I
hadn't
imagined
it
at
the
workspace
level.
More
so
just
like
at
the
project
level
like
the
root
level
like
you
would
only
define
that
and
that
way
like
we
could
essentially
support
like
no
hoist
first
and
then
down
the
line.
If
we
wanted
to
elaborate
like,
like
essentially
codify,
like
the
other
flags
into
like,
like
bundle
legacy
bundling
and
like
global
style,
all
into
a
single
like
strategies
config
along
with
no
hoist
like
then
like,
we
could
do
in
a
staged
or
like
phased
approach
right
so
like.
B
Yeah,
the
other,
the
other
thing
that
I
was
kind
of
thinking
through
it
might
be
good
to
just
talk
through
like
even
if
we
said,
okay,
we're
gonna
make
it
so
that
you
can
hoist.
I
have,
I
have
a
workspace
with
a
bunch
of
packages
and
there
are
two
that
I
don't
want
to
hoist.
B
A
Yeah,
I
think
it's
an
all
or
nothing
type
thing
for
me
like
that's.
Why
the
the
way
that
this
is
presented
in
the
way
that
I
guess
it's
supported
today
in
yarn
like
I
don't
necessarily
agree
with
like
having
individual
strategies
for
how
you
know
for
your
project
like
I
would
imagine
it's
all
or
nothing
right,
like
yeah,.
B
For
hoisting
at
least
yeah
it's,
it
really
should
just
be
a
boolean
that
defaults
to
true,
and
you
can
set
it.
You
can
set
hoist
false
if
you
don't
want
it
to
be
hoisted,
and
if
we
see,
if
we
see
no
hoist
with
an
option,
then
we'll
just
be
okay
hoist
up
voice
false
the.
B
C
B
It
would
it
would
potentially
map
to
global
style,
but
even
there
not
really,
I
I
think
I
think
we
actually,
I
think,
hoist
might
actually
be
kind
of
a
different
animal
in
a
way
because
hoisting
is
more
like
how
do
I
want
this
project
of
workspaces
to
behave
and
strategies
are
more
like
well.
When
I
install
in
this
app,
I
need
to
ignore
peer
deps,
and
when
I
install
on
that
app,
I
need
to
do
global
style
or
legacy
bundling
or.
B
They're
yours
right,
like
they're,
they're
your
other
projects
and
presumably
you
know
what
they
need,
whereas
just
random
dependencies.
You're
fetching
from
the
registry
are
like
not
yours,.
B
A
Dependency
that
you've
got
like
cit
exists
for.
C
A
B
The
from
the
lerna
team
as
well,
that
might
be
really
useful
and
potentially
also
somebody
who's
really
knowledgeable
with
yarn
workspaces
and
uses
them.
A
Yeah
yeah
jordan
had
like
good
input
based
on
like
his
work
with
enzyme.
I
think
he
had
a
bunch
of
experience
with
this.
I
think
it
was
enzyme.
C
Airbnb,
maybe
just
the
one
suggestion
before
before
the
deep
dive
we
could
maybe
put
together
a
pr
with
our
potential
rfc
that
just
put
some
of
these.
You
know
isaac
some
of
these
ideas.
You
already
have
like
raw
ideas,
kind
of
like
at
least
in
shape,
so
that
we
can
talk
about
them
ahead.
Yeah
that'd
be.
B
A
No,
it's:
okay,
okay,
we
have
a
small
group
and
a
small
agenda
and
we
all
wear
many
hats.
It's
okay
strategies,
except
if
you
want
the
notes
written
a
specific
way,
I'm
probably
not
gonna.
Do
it
the
way
you
want
it.
So
that's
the
only
problem
cool.
So
if
there's
nothing
else
on
that,
we'll
keep
this
open
for
now.
Then,
since
we'll
use
it
as
a
reference
as
well.
In
probably
those
discussions,
yeah.
A
Yeah
until
we
have
something
else,
that's
like
a
a
new
like
artifact,
yeah
cool,
so
mood
on
then
the
pr279
rc4
default
command.
I
forget
where
we
left
this
off
last
week,
but
isaac.
I
think
you
just
were
going
over
essentially
the
details
of
this
right.
B
Yeah
yeah,
I
I
kind
of
I
kind
of
presented
it
and
and
walked
through
sort
of
what
the
rfc
is
requesting
comment
on
and
also,
I
think,
essentially,
I
was
taking
the
position
in
the
discussion
of
like
the
one
most
opposed
to
it,
which
is
ironic.
A
B
Of
people
being
able
to
shoot
themselves
in
the
foot
with
it
it,
it
does
open
a
door
for
us
to
either
be
very
limited
in
adding
new
commands,
or
you
know,
really
upset
people
when
we
add
new
commands
and
ruin
their
workflows.
So
right,
you
know,
essentially,
even
if
we,
even
if
we
very
clearly
broadcast
every
single
time
like
hey,
there's
a
command
coming.
It's
going
to
be
here
in
this
version
like
if
you're
using
this
as
you're.
You
know
we
could
search
the
registry
for
anything
using
that
script.
B
Name
like
we're
still
going
to
break
somebody
yeah.
It's
still
going
to
be
somewhat
disruptive
if
they're,
relying
on
that
being
the
kind
of
default
command.
Whereas
if
help
is
the
default
command,
nobody's
really
upset.
If
we
add
that
command
it's
just
now,
it's
going
to
start
working
and
before
it
would
have
told
you
what
things
to
do,
or
you
know,
search
the
docs
for
it.
So
yeah,
the
other.
The
other
kind
of
interesting
caveat
is
like
people
getting.
B
You
know
sharing
sharing,
commands
that
just
work
like
they
just
run
npm
build
you
all
you
need
is
for
somebody
to
put
that
in
a
make
file
and
it
works
on
their
machine
and
we
kind
of
are
opening
the
door
for
this
sort
of
situation.
It
works
for
me
that
thing
and
then
there's.
B
Yeah
yeah
yeah
yeah.
That
being
said,
the
the
other,
the
other
objection
and
the
other
kind
of
reason
why
this
might
be
worth
kind
of
pairing
back
a
bit
so,
rather
than
having
a
default
command,
we
could
make
the
the
default
help
behavior
a
little
more,
a
little
more
interesting
or
reasonable
or
helpful.
So
if
you
run
npm
build
and
we
see
that
there's
a
run,
there's
a
script
named
build
and
there's
no
command
name
built.
B
Well,
we
could
just
sort
of
suggest
that,
rather
than
running
the
help
right,
we
could
say
like
hey,
there's
a
script
name,
build
do,
do
you
mean
to
run
npm
run,
build
right.
A
B
You
want
to
you
know:
do
you
want
to
have
the
help
docs
for
search
for
build?
We
could
even
present
those
two
things
as
an
option
interactively
if,
if
it's
a
tty
right
the
so
somebody
runs
npm
build
it
says,
do
you
mean
npm
run
build
yes
or
no
yeah?
If
they
say
no,
then
we
print
the
help.
B
The
other
another
thing
I
was
thinking
was
just
sort
of
what
do
we
do
with
the
like
when
you
run
npm
with
no
arcs?
This
is
something
that
I
think
has
really
somewhat
changed
in
sort
of
the
expected
behavior
of
node
cli
apps
over
the
years.
You
know
when
when
npm
was
created,
it
was
pretty
normal
if
like,
if
you
run,
if
you
run
curl
with
no
args
it'll
like
give
you
the
the
usage
banner
for
how
to
use
curl.
If
you
run
tar
with
no
args,
it's
like
that.
B
It's
the
same
kind
of
thing.
The
only
thing
that
was
kind
of
different
was,
like
you
know.
Some
of
the
stock
like
like
ls,
will
do
something
with
no
args
or
make
will
like
search
for
a
make
file.
But
over
the
years
again
like
now,
almost
every
test
runner
and
every
build
thing
and
linter
like
if
you
just
run
eslant,
it
doesn't
tell
you,
oh
you,
you
need
to
run
eslant
file,
name
it'll,
be
like
yeah
cool,
I'm
going
to
find
all
the
javascript
files
and
yes
like
them,
for
you
right
and
same
thing.
B
If
you
run
tap
or
just
with
no
args
it'll
like
find
your
tests
and
run
them.
So
I
think,
like
the
default,
behavior
of
npm
is
sort
of
uninspiring.
It
doesn't
like
it
just
lists
out
all
the
commands
and
the
npm
version
and
says
this
is
a
package
manager.
You
run
it
with
commands
like
right.
B
A
All
right
christian,
I
see
you
have
your
hand
up.
Did
you
want
to
jump
in
as
well.
D
So
a
couple
things
adding
to
that.
I
think
if
we
ran
a
script
by
default,
if
we
found
it,
we
would
still
limit
ourselves
concerning
new
commands.
That
we
might
want
to
add
later,
like,
for
example,
like
build,
would
be
gone
forever
and
I
think,
to
kind
of
counter
the
the
impact
a
little
bit.
Someone
last
week
actually
suggested
having
something
like
npr,
which
is
like
npm
run.
A
Yeah,
I
I
think,
yeah.
I
brought
up
the
npr
idea
last
last
week
for
sure,
but
I
think
what
isaac
was
also
mentioning
here
like
it
sounds
like
we
could
improve
the
help
search
experience.
A
It
sounds
like
they're
like
we
can
take
this
rc
and
and
modify
it
so
that
it's
like
we're
not
we're
updating
the
default
experience
to
be
something
that's
more
useful,
more
helpful,
like
it's
more
similar
to
roy's
project
like
ntl,
which
truly
like
you,
could
look
at
and
and
say,
hey,
there's
a
lot
of
good
stuff
in
there
that
we
could
be
pulling
in
to
the
default
help
experience.
A
I
guess,
like
the
default,
like
help,
search
experience
right
like
help
me
find
what
I
like
the
command
I
meant
to
run,
and
then
I
can
run
it
quickly
right.
I
I'm
yeah,
I'm
way
more
and
I
push
back
like
a
a
month
or
two
ago
when
this
feedback
came
in
in
a
different
place,
not
in
rrc
but
yeah,
like
the
idea
that
we
would
box
ourselves
in
in
terms
of
future
commands
is
probably
the
biggest
hazard
and
and
mostly
for
the
community.
A
If,
if
somebody
starts
sharing
like
hasn't
configured
the
default
away
from
help
search-
and
they
share
like
a
command
that
they
run
on
a
regular
basis
with
someone
and
it
works
for
them,
doesn't
work
for
the
other
person
like
we're
causing
confusion.
A
So
that's
the
only
concern
I
have
really
and
I
think
it's
it's
better
to
be,
like
I
don't
know
more
verbose,
like
I'm,
okay
with
being
more
verbose
or
finding
ways
that
we
can
like
reduce
the
friction.
If
people
don't
like
reading
run,
let's
find
another
way
for
them
to
do
that
without,
like
also
clobbering
like
our
our
namespace.
A
So
I
think,
like
npr,
like
a
new
binary
like
that,
we
could
ship
like
might
help
with
that,
and
literally
like
it's
alias
for
npm
run
like
that's
all
it
is
that
could
help.
People
might
appreciate
that,
and
then
you
know
explicitly
that
when
you
run
apr,
you're
doing
you're
running
anything.
That's
in
in
your
in
your
scripts.
Again,
people
like
to
point
out
that
we
support
other,
like
top
top
level
commands
that
are
associated
with
scripts.
Like
start
test.
A
You
know,
which
is
unfortunate,
I
think,
but
like
that's
just
like
his
historical
precedent,
so
like
I
don't
I
can't
imagine
what
we
would
do
and
start
at
least
has
some
default
like
fallback
behavior,
whereas
like
test
is
truly
just
whatever
you
put
there
so
yeah,
I
would
say
that
we
should
have
like
the
the
standard
that
going
forward
if
we
like
there
should
be
some
behavior
to
the
command
that
you're
running
like
explicit
behavior,
that
we
can
document
for
the
command
to
a
sub
command
that
we
we
introduce
and
not
just
allow
arbitrary,
like
sub
commands
to
be
created.
A
B
I
mean
I,
I
think,
that's
fine,
but
then
that
does
mean
basically
just
throwing
this
rfc
out
saying
no
and
moving
on
with
something
different
right
like
because
it
because
the
the
thing
is
what
what
you're
saying
is:
let's
not
do
a
default
command
option
which
is
fine
like
I'm.
You
know.
B
B
Why
we
have
this
process
right
to
slow
us
down
when
we're
about
to
do
something
a
little
reckless,
but
otherwise
I
probably
would
have
just
shipped
it
as
for
like
why
we
have
why
we
have
like
start
stop
restart
test,
and
we
don't
have
anything
else
like
the
simple
reason
for
that
is
that
in
lions,
the
package
manager
that
I
used
when
I
was
at
yahoo,
there
was
a
like
a
short
list
of
scripts
that
you
could
define
and
it
had
some
built-in
commands
and
those
were
the
only
scripts
that
ever
got
run.
B
There
was
no
arbitrary
run
script
command
and
in
the
first
version
of
npm
there
wasn't
either
like
there
was
a
short
list
of
script
names.
You
could
run
that
were
either
like
event
hooks
or
very
specific
tied
to
a
very
specific
command.
As
we
added
when
we
added
run
script,
people
started
using
for
all
kinds
of
stuff
as
like.
A
kind
of
basic
like
like
make
file
like
make
type
replacement
for
a
lot
of
javascript
projects,
but
so
I
yeah
yeah.
It
runs
whatever
stop
it.
B
Yeah-
and
it's
like
the
cost
of
ripping
them
out
is,
is
greater
than
the
benefit,
so
we're
not
gonna
do
that,
but
doesn't
mean
we
have
to
open.
B
It
doesn't
mean
that
anything
should
have
the
same
treatment,
yeah
and,
and
it
doesn't
mean
that
we
don't
regret
it
like
I
kind
of
do
it
would
have
been
better
to
just
say
no,
you,
you
can
run
run
script
and
you
can
make
it
whatever
you
want,
but
there's
no
special
behavior
for
starter.
Stop
you
know,
so
I
think
that's.
B
A
It
does
make
sense
like
some
common
workflows
and
when
we
start
to
think
of
npm
supporting
people's
common
like
workflows,
we
want
to
help
them
actually
like
run
those
scripts
in
easily.
That's
why
I
think
it
makes
sense
that
a
bunch
of
those
commands
exist
like
like,
like
install
and
test
see
it
like
npm
it.
I
think
that's
great,
like
npm
tit
like
like,
I
think
it's
great
like,
but
I
don't
know
how
many
people
use
it.
A
I
just
think
that,
like
those
kinds
of
like
workflows,
make
sense
to
me
like
like
combining
two
things
together
and
if
we
can
do
more
of
that
in
the
future
like
find
better
ways
to
like
help,
people
run
complex
sort
of
like
combinations
of
scripts,
which
this
starts.
The
yeah
I
mean.
B
B
A
lot
of
at
the
time
I
sort
of
imagined
that
you
know
well,
if
you're
starting
up
a
server,
you're
gonna
have
to
save
the
pid
somewhere
and
then
like
background
it.
So
you
need
a
stop
command.
That'll
like
look
up
the
pid
and
kill
the
server
or
whatever,
and
then
you
know,
and
then
lo
and
behold
like
vms
and
then
containers
got
super
cheap.
But
now
everybody
just
you
know
you
just
kill
the
whole
machine
when
you
need
to
restart
it.
B
A
Okay,
so
in
terms
of
this,
then
have
you
like
talked
to
yourself
out
of
this,
are
we
still
like
debating
whether
we
should
be
doing
this?
Are
we
should
we
keep
this
open
for
now?.
B
I
well
I
mean
I
think,
with
such
a
small
group,
we
probably
shouldn't
be
making
any
kind
of
like
actions
unless
they're,
really,
you
know
uncontroversial.
I
think
I
think
wes
was
like
the
biggest
champion
for
this
thing,
so
it
would
probably
be
good
for
at
least
somebody
to
be
like.
Yes,
I
want
give
somebody
a
chance
to
be
like
yes,
I
want
this
and
here's
why?
B
A
A
B
They
they
want
to
be,
they
want
to
be
able
to
run
npm
build
and
have
it
run
their
build
script
right
or
run
npm
land
figure
it
out.
I
know
that
would
be
nice.
That
said
like,
and
I
think,
if
it
was
configurable
most
of
those
developers
would
be
fine
right
they'd.
They
would
set
the
config
once
and
it
would
behave
the
way
they
want
and
it'd
be
no
big
deal,
that's
kind
of
the
biggest
argument
for
it.
B
A
Yeah
yeah.
D
Between
the
screens
for
like
an
npr
sub,
well,
it's
it's
more
like
an
another
binary
right.
So.
B
Once
all
things
are
considered-
and
we
get
some
fresh
air
on
this
topic,
then
maybe
npr
will
be
the
thing
I'm
making
public
radio
jokes.
A
Yes,
yeah
and
welcome.
B
To
thank
you.
I'm.
A
Yes,
there
could
be
a
lot
of
npr
jokes
so,
but
what
we're
talking
about
is
essentially
like
there
is
user
land
out
there
like
tooling,
and
I
know
again
I'll-
keep
pointing
back
to
roy's
project
as
something
that
like,
oh,
we
could
actually
improve,
like
npr
could
be
more
than
just
npm
run
an
alias
or
npm
run,
but
there
could
be
some
nice
like
behavior
there,
which
I
think
overlaps
with
the
improvements
we
would
want
to
make
to
help
search
right,
like
those.
C
Things
I'm
not
so
sure.
I
also
wanted
to
share
a
thought
about,
especially
the
like
adding
new
binaries,
like
not
so
sure
about
like
how
much
on
board.
I
do
because,
like
if
you
compare
like
you,
don't
see,
get
like
adding
new
binders
for
every,
like
common
workflow
right
like
and
a
lot
of
people
have
like
gco
alliance
defined
in
your
in
their
terminal
to
just
get
checked
out
right.
So
maybe
that's
a
better
way
to
steer
the
community
right
like
like.
C
Yeah
right
like
then,
then
you
can
have
like
be
as
as
evolved
as
you
want
right
like
and
then
maybe
you
can
point
them
yeah
you
can
even
default
to
mtl.
Then
you
get
the
interactive
interface.
If
you
want
right
or
something
like
that,
but
yeah,
I
don't
know
if
I
really
on
board
with
the
adding
of
new
binaries,
but
that
I
think
that's
a
whole
new
discussion
and
just
improving
like
that
default
health
output.
C
It's
just
very.
A
Yeah
christian,
you
have
your
hand
up.
I
know
you.
D
D
Maybe
something
we
could
do
would
also
be
like
npm,
just
yeah
configures
your
shell.
Accordingly,
if
you
want,
I
think,
visual
studio
code.
Does
this
and
like
webstorm
does
this?
They
have
like
little
tools
to
get
to
have
like
little
shortcuts
in
the
terminal
itself,
which
I
think
would
be
nice
enough.
A
Interesting,
okay,
yeah.
So
in
terms
of
this,
I
think
we'll
keep
it
open
for
now,
like
as
isaac
said,
we
don't
have
a
large
enough
group
today.
I
think,
to
make
any
like
sweeping
decisions,
so
I
think
I
might
want
to
put
together
something
for
npr
specifically
because
I
like
the
name,
but
also
because
I
think
that
would
add
value
and
and
and
maybe
to
christian's
point
they
just
made
it's.
You
know
I
found
a
lot
of
people
are
getting
in
into
development.
A
You
know
the
beginner
and
intermediate
group
are:
are
the
ones
that
often
times
are
having
the
hardest
time,
navigating
this
tooling
in
the
tooling
landscape,
and
so
like
less
configuration
and
more
like
good
defaults
and
like
if
there's
a
binary
there,
that
will
help
some
tooling
author
allow
for
them
to
quickly
and
easily
like
run
some
some
things
to
get
like
their
apps
started
their
app,
bundled
their
app
like
built.
You
know,
I
feel
like
there's
a
good
reason.
A
Why,
like
we
might
want
to
do
that
so
versus
asking
like
new
folks,
especially
like
new
and
intermediate
developers,
to
like,
be
configuring,
everything
and
aliasing.
All
these
commands,
I
think
that
you
get
into
that
later,
into
into
sort
of
your
development,
so
that
that's
what
I
would
feel
like
this
would
be
aimed
at
anyone
today
that,
like
uses
npm,
quite
often,
I
don't
think
runs
into
this
issue.
They
can
quickly
alias
and
probably
have
a
lot
of
configuration
in
place
for
for
optimizing
their
workflow,
so
cool.
A
So
moving
on
to
issue
275
the
registry
protocol,
rc
or
rrfc,
have
we
decided
to
move
this
into
a
proper
rfc
now
isaac.
I
know
you've
like
put
a
lot
of
effort
into
this
discussion
without
much
feedback.
Yet.
B
Yeah,
it
should
probably
be
a
a
proper
rfc.
I
just
kind
of
haven't
gotten
around
to
writing
up
the
spec.
I
think
it's
somewhat
uncontroversial
and
the
rfc
would
be
more
for
documentation
and
planning
purposes
than
for
any
actual,
like
comments,
I
think
it
kind
of
is
it's
everybody's
sort
of
like
yeah
that'd,
be
great.
Go
do
that
when
we
talked
about
it
before,
and
it's
really
just
a
matter
of
like
a
lot
of
typing
to
make
it
work
yeah.
So
writing
the
spec
will
help
us.
A
Okay,
so
moving
on
then
pr
and
rfc
273,
so
the
npm
workspace
is
configuration
management.
So
this
is
your
rfc
roy,
I'm
not
sure
if
anybody's
actually
commented
on
this
and
we
didn't
get
to
it
last
week,
as
far
as
I
remember.
C
No
yeah
and
yeah
it
was
pretty
much
a
raw
sketch
of
an
idea
when
I
first
presented
it
right
and
it
hasn't
evolved.
Much
yet.
To
be
quite
honest,
so
I
think
we
mentioned
last
time
for
people
to
engage
and
try
to
leave
feedback.
C
But
if
I
remember
correctly
yeah
we
had
that
feedback
from
jordan
there
in
which,
like
listing
the
workspaces
like
that,
that's
very
straightforward
and
the
non-conver
controversial
right
but
like
adding
and
removing.
I
think,
there's
still
more
polishing
to
be
done
in
that
spec.
A
Right,
okay,
I
remember
now
christian,
you
have
your
hand
up.
D
Yeah
roy,
I
just
wanted
to
ask
since
we're
such
a
small
group
like
what
are
you
actually
aiming
for
like?
Are
you
aiming
for
replacing
learner,
or
just
like
I
don't
know,
the
base
level
commands
that
learner
already
provides
or.
C
I
was
more
aiming
for
it
just
providing
an
interface
so
that
the
user
don't
need
to
manually
tweak
the
package
json
right,
similar
to
how
like
install,
will
place
your
dependencies
there
right
for
you.
So
no
the
there
was
any
more
for
that
kind
of
thing,
not
necessarily
yeah
trying
to
take
care
of
everything,
especially
since
we
have
that
other
rfc
going
on
for
the
other
for
running
commands
and
doing
no
other
kind
of
workflows
around
workspaces
right.
A
C
That's
a
good
question,
though,
for
this
one
I
haven't.
I
did
I
didn't.
Do
the
big
research
work
like
in
the
beginning
of
workspaces
right,
this
one
was
more
collecting
kind
of
like
a
few
of
the
sentiments.
Some
of
the
feedback
from
the
issues
folk
have
been
posting
in
the
cli
repo
when
actually
playing
with
workspaces
like
because,
basically
right
now,
what
the
support
we
have
is
very
foundational
right,
like
basically
just
being
able
to
install
workspaces
in
place
along
with
your
stall
tree.
C
C
Rfc
right
for
running
the
commands
across
the
workspaces
you
define,
so
this
one
was
something
that
was
not
described
there,
which
is
handling
the
config
itself
right,
like
just
handling
like
being
able
to
add
or
remove
a
workspace
automatically
so
yeah
it
was
more
from.
I
was
approaching
from
that
point
of
view.
A
A
Yeah,
we
should
probably
bubble
up
yeah.
We
should
probably
bubble
up
and
try
to
ratify
or
or
move
forward
with,
the
other
workspaces
rfc
pretty
soon,
since
we
want
to
get
working
on
that
come
in
the
new
year.
I
know
I
know.
B
C
Like
think,
even
taking
back
that,
rfc
would
be
more
like
next
year,
right
early
next
year,
jumping
back
into
the
the
working
with
workspaces.
The
running
commands,
yeah.
A
A
So
just
like
that
as
well
here,
okay,
moving
on
then
to
unless
there's
anything
else,
you
want
to
add
there
roy
on
the
config
management
piece,
all
good
cool,
so
moving
on
to
272,
add
preferred
dev
field
to
package
json.
I
think
I
don't
think
we've
done
anything
here
on
this.
I'm
not
sure
if
this.
B
B
Just
because
installing
something
has
appear
is
something
you
should
really
only
do
like
if
you
kind
of
know
what
you're
doing,
but
nevertheless,
like
you
know,
if
eslint
had
preferred
dev
like
they're,
going
to
be
kind
of
shouting
at
you
when
you
install
something
that
maybe
shouldn't
be
a
dev
it
just
in
practice
like
with
preferred
global,
like
these
things
are
just
kind
of
not
not
as
helpful
as
people
think
and,
and
you
find
all
of
the
edge
cases
right
away
where
something
actually
shouldn't
be
installed
as
a
dev
app.
A
Okay,
so
we'll
just
leave
it
open
for
now.
I
guess-
and
I'm
just
gonna
remove
it
from
the
agenda
for
next
week
then,
and
let
folks
add
comments
if
they
want
to
okay
and
the
last
item
on
the
agenda
that
we
had
was
rc
217
aggregate
per
package
per
organization.
This
is
essentially
the
preceding
pr
to
the.
I
think
the
registry
protocol
work
that
you've
done
isaac
now.
A
B
A
Action
item
there
cool
is
there
anything
else
that
anybody
wanted
to
bring
up
on
the
call
christian
anything
from
your
end
no
well,
I
can
give
you
all
12
minutes
of
your
life
back
your
time
back
then,
and
appreciate
y'all
jumping
on
we'll
post
the
the
meeting
notes
here
in
a
few
minutes
after
the
call
and
hopefully
see
everybody
next
week,
and
hopefully
you
have
a
good
holidays
if
you're
taking
time
off
and.