►
From YouTube: Open RFC Meeting - Wednesday, June 16th 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
openrc
call.
Today's
date
is
june
16th
or
wednesday
june
16th
2021.
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
number
399
and
the
npm
rc's
repo
I'll
copy
and
paste
for
everybody
that
just
joined
the
meeting.
Notes
doc
feel
free
to
add
yourselves
as
an
attendee
and
just
a
bit
of
housekeeping
quickly.
A
As
is
usual,
these
calls
and
all
communication
on
the
rc's
repo
is
covered
by
a
code
of
conduct
that
we
ask
folks
to
please
abide
by
the
synopsis.
There
is
please
be
respectful
as
folks
are
talking
raise
your
hand
if
you'd
like
to
jump
in
and
we'll
call
on
you
and
yeah.
Just
please
be
kind
as
as
normal.
A
The
desired
outcomes
of
this
call
is
to
ideally
move
features
forward
and
have
a
touch
point
with
community
on
features
they'd
like
implemented
in
terms
of
announcements.
This
week
I
don't
think,
there's
anything
you
know
I
had
queued
up.
Does
anybody
else?
Have
any
announcements.
A
As
usual,
we're
cutting
releases
weekly.
So
if
you
want
to
grab
the
latest
mpm
cly,
you
can
get
in
the
normal
ways.
Please,
you
know
try
out
v7,
continue
to
give
us
feedback
and
we're
trying
to
stay
on
top
of
our
issue
backlog.
So
that's
great!
A
So
moving
on
we'll
kick
off
things
earlier
in
the
week
our
team
identified
the
fact
that
there
are
still
sort
of
a
backlog
of
accepted
and
yet
not
implemented
our
skis
that
we
want
to
go
through
and
essentially
either
withdraw
or
queue
up
in
our
backlog
to
actually
be
executed
on.
A
So,
if
folks
are
okay
with
it,
I'm
going
gonna
share
my
screen
quickly
and
we
can
go
through
that
list
and
and
sort
of
have
a
bit
of
discussion
about
what
we
actually
want
to
potentially
actually
move
forward
with
or
or
withdraw
in
terms
of
execution
here.
So.
A
Okay,
can
folks
see
my
screen
yep
awesome,
so
the
first
rc
that
we
want
to
look
at
got
actually
implemented
or
accepted
about
three
years
ago.
This
is
the
idea
that
we
would
implement
something
like
a
npm
changelog.
A
B
B
Would
suggest
we
just
we
just
remove
it,
yeah
withdraw
it,
because
we
haven't
implemented
it
and
we're
not
very
likely
to
and
like
that
kind
of
stuff,
actually
kind
of
belongs
more
at
the
get
repo
level
I
feel
like
and
that's
happening
so
yeah.
I
I
don't.
I
don't
see
this
being
a
very
high
priority
thing
anytime
soon,.
C
C
It
already
is
right,
like
I
mean,
there's
a
couple:
different
file
names
that
are
used
and
npm
could
pick
one
and
some
things
don't
actually
provide
one
and
you
know,
but
like
yeah,
the
majority
do
use
like
changelog.md.
B
I
mean,
if
you
do
like
change
change,
log
just
bear
or
change
log
dot
star.
It's
that's,
usually
the
change
log
file
we
actually
removed
it.
At
I
mean
at
the
request
of
users,
we
removed
it
from
the
the
always
include
list
in
in
npm
pack
list,
because
they
can
get
kind
of
long
and
you
just
never
look
at
them.
So
why
have
them
in
your
node
models
tree.
A
So,
in
this
case,
this
would
essentially
remove
the
yeah
zero
zero
two
or
actually,
if
we
want
to
take
some
notes
here,
I
want
to
at
least
capture
and
and
roy
I'm
not
sure,
if
you're
taking
notes
here
but
want
to
capture
what
we
would
define
as
the
amendment.
A
So
in
terms
of
withdrawing
and
rfc,
I
think
we
created
sort
of
a
template
for
why
we
are
essentially
amending
or
we're
saying
that
this
is
no
longer
useful.
So
just
want
to
be
mindful
that
we
should
cue
that
up
either
as
an
action
item
to
write
that
and
move
it
over
or
we
can
decide
right
now.
The
reason
is
because
we
don't
think
that
this
is
useful
anymore.
C
Yeah
I
mean
I
don't
feel
that
strongly
about
it
right
like
if,
if
no
one,
and
especially
if
no
one's
planning
on
implementing
it-
and
I
certainly
don't
have
the
time
to
do
it
so
like
maybe
there's
a
difference
between
like
like
maybe
it'd,
be
useful
to
say
this
is
an
rfc
that
was
accepted
and
is
not
going
to
be
accepted
in
the
future
versus
or
is
like
no
longer
accepted
versus
one
that
this
is
accepted.
But
like
no
one's
going
to
work
on
it
like.
If
someone.
B
Yet
another
command
for
a
thing
that
I
feel
like
shouldn't,
really
be
npm's
job
and
it
also
sort
of
implies
some
potentially
like
what,
if
you
fetch.
B
Yeah,
there
are
certainly
some
that,
like
I'd,
probably
accept
an
audit
xml
report,
but
I
am
not
going
to
implement
it
myself
like
if
it's
just
a
matter
of
taking
the
audit
json
that
we
have
now
and
dumping
it
as
xml
I'd
be
like
okay
cool
like
if
you
need
this,
then
sure
send
a
pr,
but
it's
been
several
years
and
nobody's
piped
up
like
since
the
initial
report
nobody's
come
around
and
said
that
they
would
do
it
exactly
so
I
think
we
can.
I
think
we
can
withdraw
it.
I
guess
you
know.
B
Part
of
the
meta
conversation
here
maybe
is
like
accepted,
should
really
be
like
it's
kind
of
on
our
roadmap
like,
even
if,
even
if
we
don't
have
a
specific
date
yet
for
when
it's
going
to
be
shipped,
it's
a
thing
that
we
we
we're
sort
of
announcing
an
intent
to
build
something.
If
it's
unaccepted.
C
Yeah,
so
using
these
two
as
an
example
then
like
it,
I
don't
know
if
this
is
overkill
but
like
it
seems
like
making
a
folder
for
one
folder
for
the
changelog
one
and
a
different
one
for
the
audit
xml,
where
the
changelog
one
is
saying
like
no.
A
B
E
B
A
B
A
If
you
can
just
take
that
note,
moving
on
shallow
updates.
B
This
this
definitely
needs
review.
If
you
do
npm
update
some
name,
then
we
only
touch
the
things
by
that
name
and
any
edges
that
are
now
invalid.
After
the
update,
when
you
do
npm
update
without
any
names,
while
we
throw
away
the
entire
current
state
of
the
tree,
whether
it's
the
actual
tree
or
the
package.json,
and
just
sort
of
build
from
first
principles
and
then
turn
it
into
that,
so
shallow
updates
are
like
well,
no,
it's
not
shallowly
updating.
B
B
Installs
I
want
to
push
back
on
this
one.
I
don't
think
that
it's
particularly
useful
like
we
have.
We
have
the
sort
of
established
semantics
of
semver
with
pre-releases
and
the
carrot
already
kind
of
handles
the
right
state
of
like
oh
well.
This
is
carrot
is
like
give
me
the
things
that
the
author,
according
to
their
you
know,
understanding
of
december,
does
not
think
is
a
breaking
change.
B
And
the
way
that
we
have
the
established
some
semantics
of
pre-release
is
where
we
only
include
the
pre-releases
in
that
major
minor
patch
tuple.
I
I
think
it's
like
what
we
have
is
fine
again.
This
is
one
of
these
ones
where,
like
nobody,
has
complained
about
us
not
having
it
and
it's
a
strictly
cly
side
thing
so.
A
B
B
B
No
remove
this.
This
was
kind
of
half
implemented
in
npm,
5
and
6.
B
But
a
lot
of
the
a
lot
of
what
this
is
trying
to
do
is
handled
already
in
a
better
way
by
the
new
package,
lock
syntax,
the
new
package
lock
formatting
and
the
way
that
arborist
does
it.
So
the
like.
It's
talking
about
an
implementation
that
no
longer
exists.
A
So
we'll
draw
the
link,
changes
and
running
as
root.
This
was
also
implemented
already,
I
think,
based
on
what
we
talked
about
on
monday.
It.
A
The
uid
versus
gid
changes,
okay,
so
we
can
move
that
to
implemented
and
then
publish
prompts.
I
think
the
rest
of
these
have
been
more
recently
actually
accepted.
So
I
think
it
was
just
this
first
set
that
we
really
want
to
to
get
yeah.
A
F
A
Was
still
in
there
right,
but
it's
not
actually
supported
and
that
eventually
will
be
fixed
soon
when
we
have
our
docs
being
generated
from
the
config
itself
right.
So
it's
part
of
it.
It
already
is
yeah.
A
Awesome
cool,
so
next
up
was
actually
I
wanted
to
check
in
quickly
get
a
bit
of
progress
updates
on
some
of
the
action
items
we
had
from
last
week.
This
is
something
that
I
think
I'll
do
more
going
forward,
especially
because
we're
doing
these
calls
weekly
so
having
like
an
ongoing
list
of
action
items
just
to
check
in
and
make
sure
that
we're
actually
following
up
on
those
things,
I
think,
would
be
good.
A
So
last
week
we
identified
unfortunately
zb
couldn't
make
it
but
gave
a
quick
update
in
the
issue
itself
for
his
items.
He
said
specifically
he's
dug
up
and
is
looking
at
our
breast
itself
and
he's
gonna
spend
some
time
to
actually
create
the
pr's
might
be
good
if
we
can
actually
get
somebody
to
to
pair
with
them
based
on
time
zones.
It
would
be
nice
to
see
if
we
can
get
somebody
to
actually
work
with
him,
based
on
the
fact
that
I
know
he
wants
to
make
some
changes.
A
Add
some
information
back
into
the
audit
json
so
and
then
roy.
If
you
want
to
give,
maybe
a
quick
update,
I'm
not
sure
if
you're
going
to
get
time
this
week,
maybe
to
turn
the
npm
ad
rric
into
a
real
rfc.
Is
that
something
that
might
happen
this
week?.
D
Right,
it's
possible,
but
a
lot
of
not
on
the
top
of
my
priorities
for
the
week,
so
maybe
we'll
just
stay
for
next
week.
A
Okay,
keep
it
open
and
then
the
last
one
was
I
know:
tierney
you've
had
the
npm
audit
licenses
pr
open
for
a
while,
so
I've
I've
been
trying
to
push
you
and
roy
together
or
I'm
being
suggesting
that
you
and
I
should
get
together
at
some
point
to
help
kick
things
off
there
or
anybody
from
our
team
to
to
support
that
so
I'll
keep
those
on.
A
Since
I
don't
think
that
you've
gotten
a
chance
to
work
on
that,
yet
I'll
keep
those
on
the
radar
for
next
week
as
well
so
cool.
Let's
move
on
then
to
the
actual
first
actual
rrfc
issue:
398
roy.
This
is
the
top
level
command
to
manage
package
json.
I
don't
think
we've
talked
about
this
yet
so
would
you
like
to
give
a
quick
synopsis
of
what
this
is.
D
Sure
yeah,
I
believe
you
floated
the
idea
a
few
times
already
so
yeah.
This
is
basically
a
command
to
kind
of,
like
centralize,
all
the
management
of
the
package,
json
in
a
single
top
level
command.
So
right
now
we
have
a
bunch
of
commands
that
already
manage
your
your
package.json
data,
for
you
like
npm,
install
uninstall
right.
They
will
all
make
sure
to
manage
the
dependencies.
D
So
recently
we
introduced
set
script.
It
was
one
of
the
old,
more
old
accepted
rfcs
was
implemented
by
someone
in
the
community,
so
we
were
happy.
We
shipped
that
in
kim
seven,
but
we
also
kind
of
wanted
to
think
moving
forward.
A
D
Way
to
kind
of
handle
the
rest
of
it
right,
like
so
there's
a
way
of
managing
set
the
scripts
the
way
of
managing
dependencies
to
some
extent
we're
also
managing
workspaces.
Now,
with
npm
in
it
using
a
workspace
configuration,
you
will
also
automatically
add
workspaces
entries
to
your
workspaces,
configuration
so
yeah,
so
this
is
basically
a
top
level
command
to
kind
of
centralize,
all
the
rest
and
yeah.
I
believe
there
is
a
bunch
to
be
discussed
here,
especially
on
both
syntax.
D
B
B
Just
posted
a
suggestion
there
and
basically
basically
mirror
what
we
can
do
with
npm
config
get
set
and
delete,
so
npm
pkg
set
will
take
a
dot,
separated
key
and
then
an
equal
sign
and
a
value.
All
is
one
positional
argument,
so
you
can
set
multiple
things
all
in
one
command
invocation,
npm
pkg
get,
can
take
one
or
more
keys
which
can
again
be
dot,
separated
values
and
we
just
dump
the
json
stringified
value
and
npm
pkg
delete
which
can
get
you
know
one
or
more
dot
separated
keys
and
we
just
delete
those
fields.
B
C
B
Well,
so
right
now,
npm
config
doesn't
support
any
dot
separated
fields,
but
only
because
our
config
is
a
flat
object
right.
It's
like
forced
to
be
a
flat.
B
C
So,
personally,
not
that
many,
like
there's,
probably
20
fields
in
my
biggest
ones,
but
more
like
when
I'm
browsing
just
trying
to
see.
What's
there,
then
I
could-
or
if
I'm
in
like
a
workspace-
and
I
do
you
know
whatever
the
I
haven't-
memorized
the
npm
workspaces
equivalent
yet
but
whatever
the
equivalent
is
of
learn
it
exec.
C
B
A
Scar,
I
see
you've
had
your
hand
up.
Did
you
want
to
jump
in.
F
Part
of
this
address
is
just
worried
about
deep
objects
and
the
dot
notation
solves
that.
But
when
you
bring
up
config,
it
reminds
me
we
do
have
now
they're
deprecated,
but
we
do
have
config
items
with
dots
in
them.
So
that's
why.
F
A
Yeah,
like
I
would
say,
let's
match
whatever
yeah
npm
view
does
npm
config
does
and
then
in
terms
of
power
matching
yeah.
I
don't
have
any
opinion.
Jordan.
C
Yeah
I
mean
that
was
why
I
brought
up
git
because
they
might
their
decisions
might
be
something
to
to
follow
in
the
sense
that
I
think
they
have
a
lot
more
abilities
to
get
multiple
things
than
to
set
multiple
things,
and
I
suspect
that
that
we
may
end
up
coming
to
a
similar
conclusion
about
the
like
foot
gun
nature
of
setting
multiple
things,
but
like
at
the
least.
If
we're
going
to
deviate,
it
seems
from
that
it
seems
worth
doing
that
intentionally.
So
it
could
I'm
just.
C
A
True,
I
guess
so
like
I'm
facing
my
like
assumptions
on
how
we
can
move
forward
quickly,
based
on
like
what
we
already
have
implemented
like
in
view
and
in
config
right
so
like
like
doing
taking
it's
like
almost
taking
two
steps
back
by
going.
Oh,
like
what
does
git
do
and
how
can
we
map
to
that
when
we've
already
like
made
in
it
like
when
we've
already
implemented
something
some
way?
Why
don't
we
just
match
what
we're
doing
and
those
other
commands
right.
C
Yeah
and
I'm
not
speaking
to
the
implementation
or
the
exact
spelling
of
commands
or
the
exact
incantations
more
just
like
what
are
the
capabilities.
Git
config
has
are
those
capabilities
that
we
can
or
should
match
can't.
Should
we
exceed
them?
Should
we
not
you
know,
but
yeah?
I
see
your
point
for
the
rest
of
it.
Yeah.
A
C
A
C
Yeah
but
like
I'm
sort
of
trying
to
advocate
not
redesigning
a
solved
problem,
even
if
you
know,
because.
A
A
B
Yeah
view
view
support,
set.
A
I
would
love
to
see
this,
like
specifically
because
of
the
more
complex
workflows
that
we're
trying
to
support
with
workspaces.
I
think
it
makes
a
ton
of
sense
for
you
to
be
able
to
quickly.
E
A
E
I've
also
been
doing
some
just
basic
articles
on
esm
this
week,
and
one
thing
that
would
be
nice
is
to
be
able
to
go
through
and
set
type
module
on
all
my
packages
and
like
see
what
breaks
or
like
you
know.
If
I
want
to
switch
from
some
eslint
config,
I
don't
know
from
airbnb
to
something
like
standard.
E
You
know
that's
an
easy
way
to
change.
Well,
can
you
would
you
be
able
to?
Would
you
be
able
to
change
a
command,
or
is
this
just
adding
something
new.
A
A
V8
for
set
script,
because
it's
essentially
redundant
and
yeah
so
you'd
be
able
to
for
any
scripts,
you'd,
be
able
to
do
pkj
set
and
then.
E
No,
this
sounds
this
sounds
super
useful,
like
I
can
also
I
mean
I.
I
have
worked
with
enough
different
microsoft
teams
that
manage
large
swaths
of
modules,
whether
they're
internal
usage
or
external
usage
that
would
like
you
know.
I
worked
with
brian
tarlston
on
some
stuff
a
while
ago
of
like
hey.
We
want
to
update
all
this
this,
like
one
line
in
every
single
package.
Here,
good
luck
like
it,
it
becomes
nasty.
So
this
is.
This
is
angry
like
this
is
excellent.
I'm
very
excited
for
this.
A
A
Cool
moving
on
then
to
number
390
npm
publish
should
fail
when
files
are
misconfigured
and
package.json
are
missing
in
the
config
for
package.json.
A
I
don't
think
aladdin
was
able
to
join,
but
I
think
the
just
a
high
level
overview
of
what
the
ask
here
is
and
the
rrfc
is,
if
you've
defined
a
files
array,
a
bunch
of
files
in
package.json,
and
you
go
to
do
a
publish
if
those
files
don't
exist.
Their
hope
is
that
we
should
be
erroring
out
or
we
should
be
throwing
an
error
when
you
go
to
essentially
pack
thoughts,
feelings,
I'll,
share
the
link.
Okay,.
C
I
mean
it
seems
like
you've
explicitly
if
you've
explicitly
put
an
item
in
an
include
list
and
that
include
list
isn't
a
shareable
list
like
a
shared
config
or
something
extended
from
somewhere
else.
Then
you
would
always
want
an
error
when
that
inclusion
like
when
the
thing
you're
trying
to
include
is
missing,
and
I
think
this
meets
all
those
criteria.
A
B
A
Yeah,
I
was
gonna
say
it
is
a
breaking
change,
but
you
could
potentially
do
something
similar
to
what
we
have
with
engine
strict.
So
we
could
be
like
file
strict.
We
could
make
it
a
warning
by
default
and
that
wouldn't
be
a
breaking
change.
We
could
ship
that
in
a
minor,
but
then,
if
you
want
to
error
out,
maybe
we
could
put
it
behind
a
flag,
so
like
publish
npm
publish,
could
have
like
a
flag,
something
along
the
lines
of
like
file
strict
or
something.
B
A
Cool
okay,
so
maybe
we
can
give
the
feedback
we'll
backlog
the
work
to
make
this
a
warning
by
default
and
then
like
we're,
okay
with
in
v8
like
shipping
it
as
an
error.
The.
B
So,
just
getting
into
the
weeds
a
little
bit
on
this
like
when
we
put
that
warning
in
place.
It's
it's
ever
so
slightly
tricky,
because
your
files
list
can
be
something
like
lib
and
there's
nothing
in
the
npm
pack
list
called
lib.
Instead,
I
have
lib
slash
blah.js
right
because
lib
is
a
folder.
C
B
Well,
it
gets
extra
weird
too
right,
because
if
you
have
something
in
your
files
list,
that
has
like
a
brace
comma
section
right.
So
if
I
have
my
files
is
lib,
slash,
open,
curly,
brace,
foo,
comma
bar
closed
curly
brace.
Well,
what
if
I
got
foo,
but
I
didn't
get
bar
right
and
the
and
the
expansion
of
that
glob
says
specifically.
No.
There
are
two
things
here:
it's
not
zero
or
more
it's
both
of
these
it's
an
or
right
or
or
it
could
be
like
from
an
incision
effectively.
B
C
I
think
the
brace
expansion
there's
like
there's
a
difference
between
the
star
and
not
right,
because
if
there's,
if
there's
stars
in
there,
then
zero
is
acceptable.
But
brace
expansion
alone
is
not
a
star.
So
if
you
just
had
lib
slash,
curly,
brace,
foo,
comma
bar
curly,
brace,
that's
two
items:
that's
just
a
shorthand
for
two
explicit
strings
in
your
list,
and
so
I
would
expect
that
to
error.
If
either
one
was
missing
right.
B
But
this
gets
okay.
This
gets
very
quickly
like
mind-bogglingly
complicated
unless
we
say
that
everything
in
the
every
glob
in
the
files
list
has
to
match
either
the
parent
directory
or
a
file
in
the
pack
list.
B
Right,
so
what
if
I
have
like,
I
mean
brace
expansions,
get
pretty
complicated.
There's
also
like
question
marks,
there's
stars
there's
you
know
the
at
section
things
the
plus
section
things
like
we.
We
support
the
full
breadth
of
bash
four
style,
globs.
C
E
C
B
There's
there's
two
different
you're
mixing
two
different
semantics:
the
first
one
is
brace
expansion,
as
it's
done
by
bash
on
the
command
line,
but
what
this,
the
the
glob
semantics,
that
files
lists
and
ignore
files
use
is
more
in
line
with
how
git
ignores
work,
so
brace
expansion
effectively
is
just
used
to
say.
B
Does
this
particular
file,
I'm
looking
at
match
any
of
the
things
in
this
brace
expanded
list
and
then
you're
right?
I
mean
in
a
strictly
technical
point
of
view.
Brace
expansion
is
separate
and
happens
prior
to
globs,
which
is
why,
if
you,
if
you
dig
into
the
implement
details
of
mini
match
and
node
glob,
they
actually
separate
out
brace
expansion
prior
to
doing
the
globs
on
all
of
the
path
parts,
because
you
know
true,
glob
sections
can't
include
slashes,
whereas
brace
expansion
can.
C
B
But
that's
not
how
git
ignore
does
it.
So
if
we
wanted
to
say
well,
I
shouldn't
you
know
if
we
want
to
say
like
which
files
does
this
particular
entry
in
my
files
list
which
files
on
this
does
this
refer
to,
like
that
that
entry
was
satisfied
because
there's
something
that
satisfies
it,
like
the
the
simple
way.
B
Well,
git
doesn't
warn
you
if
there's
something
in
your
git
ignore
that
doesn't
exist
right.
So
it's
it's
right
like
what
we're.
What
we're
talking
about,
adding
is
kind
of
a
net
new
functionality
that
lists
on
us,
so
we'd
have
to
figure
out
exactly
what
that
what
those
semantics
mean
just
be
mindful
gar.
I
know
you've
had
your
hand
up
for
a
while.
F
F
I
think,
based
on
this
pr
saying
I
expect
these
things
to
be
here
which
wasn't
really
the
original
intent
of
glob,
so
that
we've
got
a
kind
of
a
square
peg
around
hole
problem
here.
So
that's.
I
think
why
the
implementation's
tricky
is
because
glob
solved
a
different
problem,
and
so
now
trying
to
make
it
solve
the
inverse
problem
is
not
intuitive.
B
Definitely
is
exactly
what
you're
saying
like:
if
the
file
doesn't
exist
then
great
like
I
should
pretend
it
doesn't
exist,
but
the
implementation
as
it
is
now
in
npm
pack
list,
is
actually
quite
different
when
it
encounters
a
directory
with
a
package.json.
B
It
basically
replaces
its
read
file.
Sorry,
it's
read,
dir
call
as
it's
doing
that
exploration.
It
replaces
its
reader
call
with
expand
all
of
these
globs
and
those
are
the
things
that
I'm
going
to
kind
of
view
on
the
next
pass,
and
if
there
are
directories,
then
I'll
continue
reading
through
them
yeah.
I
just
want
to.
B
A
So,
just
the
time
box
things
we
only
have
about
15
minutes
left.
I
would
encourage
everybody
that
had
opinions
there
to
add
some
comments
back
to
the
rrfc
itself
and
also,
if
we
can
capture
not
just
in
the
meeting
notes,
but
maybe
also
give
a
sense
of
what
we
could
do
in
terms
of
action
items
moving
forward
in
terms
of
throwing
a
warning.
A
And
then,
potentially
in
v8
throwing
an
actual
error,
I
think
that
that
would
be
great
to
capture
that,
but
yeah
encourage
folks
to
keep
the
conversation
going
in
the
async
and
the
issue
itself
want
to
move
on.
I
had
here
originally
in
the
agenda.
There
was
a
item
there
for
defining
shared
verse,
not
shared
depths,
which
we
dropped
the
agenda
label
last
week,
so
just
to
tell
folks
that
I
updated
that
removed
that
from
the
agenda
and
moving
on
then
to
the
pr
343.
A
This
is
the
auto
switching
context
based
on
current
working
directory.
I
want
to
get
to
this
and
potentially
the
the
next
rc
specifically.
So
if
we
can
time
box
this
to
about
five
minutes,
that'd
be
great
roy,
I'm
not
sure.
If
there's
anything
to
update
here,
maybe
you
can.
D
Someone
basically
suggests
saying
that
that
maybe
we
can
just
warn
a
message
or
something
telling
the
user
well,
we
should
just
run
this
command
from
the
top
level,
using
the
workspace
config
that
that
that
is
a
valid
or
anything,
I
think,
to
kind
of
improve
on
the
problem
and
yeah,
and
this
other
person
commented
on
it
saying
basically
like
a
very
custom
setup
where
you
might
have
nested
workspaces,
and
it
would
be
a
shame
if
we
were
to
break
that.
D
I
think
I
think
jordan
or
someone
else
might
have
alluded
to
that
in
the
previous
discussions
on
this
on
this
rfc
so
yeah,
I
think
you're
yeah.
To
sum
up
darcy,
I
know
you
mentioned.
We
probably
should
clean
up
and
update
the
rfc,
but
I
kind
of
yeah.
I
want
to
make
sure
we
capture
the
sentiment
here.
D
Which,
I
believe
is
we
add
a
new
configuration
option
right
that
we
point
we
have
to
kind
of
manually
point
to
workspace
room,
so
we
could
either
put
that
into
another
npmrc
file,
or
one
of
the
suggestions
that
I
personally
like
is
maybe
just
reading
from
the
package
jason.
We
already
made
the
workspaces
configuration
we
made.
D
B
A
B
Option
which
might
be
worth
considering
it's
a
little
more
magical,
but
it
might
be
better
which
is
like
when
we,
when
we
reify
and
there's
a
workspace
there,
we
create
some.
We
put
something
in
the
workspace
node
modules
folder,
which
indicates
the
route.
A
Agree
that
that's
okay,
I
just
wanted
to
make
sure
that
we're
saying
that's
an
option.
We
agree.
We
don't
want
to
go
with
that
option,
because
it's
a
bad
idea
now
you're
saying
the
other
kind
of
magical
option
could
be
while
we
could
nest
a
file
or
something
in
in
node
modules
right
to
want
to
dump
the
tree
yeah.
Okay,
no!
I
would
okay
so
folks
on
the
call.
If
you
were
given
those
I
I
would
not.
A
Personally,
I
don't
like
that
option
of
the
magical,
node
modules
I'd
rather
it
be
somewhere
like
either
an
npm
rc
file
or
the
package
json
as
roy's
just
identified
I've.
I
consider
those
to
be
the
two
options
that
I
I
think
are
personally
more.
B
Well,
no,
it's
not
because
in
in
order
to
put
something
in
your
node
modules
tree
like
you
have
to
take
some
action,
you
have
to
reify
at
the
root
of
the
project
right.
So
when
I,
when
I
run
npm
install
in
my
workspace
root,
it'll,
add
that
workspace
root
link
to
all
the
workspace
children
right
then,
if.
A
C
Well,
and
and
for
what
we've
talked
about,
there's
like
the
two
mental
models
right
one
is.
I
want
my
child
workspace
to
act.
To
always
know
it's
part
of
a
big
workspace,
but
the
other,
which
is
one
I
tend
to
use
more
often
is.
I
want
my
child
workspace
to
act
as
if
it
were
in
a
repo
by
itself
and
so
like
putting
it
in
pmrc
gives
me
the
ability
to
change
that
setting,
and
it
also
gives
us
the
ability
to
pick
the
default.
We
think
most
people
will
want
yeah.
A
C
C
D
D
So
let's
say
you
have
workspace
a
workspace
b,
you
write
and
you
have
the
root.
So
if
you
place
an
npmrc
file
under
a
under
workspace
a
then
you
can
like
the
only
I
mean
you
can
set
a
bunch
of
options
there.
If
you
want
right,
like
you,
can
copy
the
npmrc
from
the
root
and
place
there,
but
only
add
workspace
root
pointing
to
your
project
folder.
D
B
B
Does
it
know
that
I'm
in
a
workspace
or
not
like
what?
How
many
steps
have
to
happen
in
order
for
it
to
understand
that
the
folder
I'm
in
is
actually
not
the
npm
prefix?
It's
a
workspace
so
putting
walking
up
the
tree
satisfies
that
use
case
right,
like
there's,
no
way
that
it
can
ever
not
know
that
I'm
in
a
workspace,
because
we're
always
going
to
find
whatever
workspace
we're
in.
Unfortunately,
it's
too
aggressive
it'll
find
the
workspaces
it
shouldn't.
B
If
there's,
if
there's
a
a
indicator
that
we
place
in
the
workspace,
the
first
time
we
reify
like
a
like
a
link
in
node
modules,
or
something
like
that,
then
that
is
then
you
get
that
behavior
right.
I
run
npm
install
on
the
route
and
then
I
cd
into
a
workspace
and
I
start
doing
stuff,
and
it
knows
I'm
in
a
workspace.
C
C
D
B
Then
it
could
be
in
the
checked
into
the
kit,
repo
you're
unlikely,
to
check
in
the
package
lock
from
the
workspaces,
though
you'd
put
it
in
the
route.
So
unless,
unless
you're
saying
that
we
put
it
in
the
workspace
package
lock
like
the
package
lock
entry
for
each
work,
shell,
child
workspace
just
says
workspace,
root,
equals
block
and
then.
C
B
Right
yeah:
we
could
also
put
that
npmrc
there
by
default.
That's
right.
A
B
Another
possibility
is
that
we
we
place
that
npm,
that
dot
npmrc
file
in
the
workspace
children
in
the
workspace
targets,
if
it's
not
present
well,
that
would
be
a
new
command.
C
D
B
Yeah
the
downside
of
putting
it
in
the
in
the
package
json
is
that
we
use
that
in
other
places,
and
you
can't
then
override
it.
If
it's
not
present
means
you.
C
C
A
Directory
structure
like
like
yeah,
there's
no
reason
to
yeah.
Okay,
we
only
have
a
few
minutes
left.
I
want
to
maybe
try
to
close
this
out
to
give
us
some
like
what
do
we
want
to
go
forward
with?
I,
I
personally
am
a
proponent
of
all
the
suggestions
jordan
made,
including
the
npm
workspaces.
D
Yeah,
I
can
definitely,
if
you
want
there's.
I
think
this
might
be
a
good
solution
like
I
can
definitely
revamp
the
rfc.
I
had
the
suggestion
of
having
the
npmrc
file
for
now
for
each
nested
workspace
and
we
can.
We
can
continue
the
conversation
after
after
it's.
The
rfc
itself
is
updated.
A
A
I
also
just
would
got
off
a
call
with
the
folks
from
korea
react
up
who
have
been
using
yarn
for
a
while
workspaces
and
said
that,
like
yarns
implementation
is,
I
think,
the
initial
conceptual
model
that
you
had,
which
was
like
the
auto
inferring
root
space,
the
roots
work
space
so
or
and
or
they
have
like
a
depth
way
to
define
it
within
the
child
as
well.
I
think
within
similar
to
what
you
your
second
suggestion
as
well,
so
there's
a
way
to
essentially
like
create
that
connection.
A
So,
okay,
we
only
have
about
a
minute
left,
so
we're
not
going
to
probably
be
able
to
get
to
the
other
item
that
I
did
want
to
get
to
which
is
nilfs
where
config.
I
believe
we're
at
the
point
that
we
want
to
ratify
this.
It's
just
the
name
is
less
than
appetizing
yeah
yeah.
A
A
B
So
for
exact,
it's
the
package,
location.
F
A
A
There's
no
pushback!
No,
if
you've
got
any
time
which
I
don't
know.
If
you
do
because
I
know
you've
got
a
chock
full
day.
Maybe
we
can
move
forward
on
this
later
in
the
week,
update
it.
Okay,
I'll
get
it
updated,
awesome
cool!
I
we're
over
time
now
apologize
for
any
folks
that
came
for
any
of
the
topics
that
we
had
towards
the
end
of
the
agenda.
Hopefully
we'll
get
to
those
next
week
and
yeah.
A
Thank
you
all
for
jumping
on
today,
and
hopefully
we
can
keep
the
conversation
going.
Async
and
I'll
see
you
next
week
sounds
good.