►
From YouTube: Open RFC Meeting - Wednesday, April 7th 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
A
And
we're
live,
welcome
everybody
to
another
npm,
open
rc
call.
Today's
date
is
wednesday
april
7th
2021
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
362
and
the
mpmrc's
repo.
A
I
will
spam
the
meeting
notes
dog
for
folks
feel
free
to
add
yourselves
as
attendees
and
yeah.
Just
a
quick
reminder
and
acknowledgements.
A
A
Hopefully
we
can
have
good
discourse,
also
just
quick
announcements
for
ourselves.
We
are
continuing
to
ship
new
releases
weekly,
so
we
cut
a
release.
Last
week
we
are
currently
at
7.8
of
the
mpmcli,
so
hope
folks
are
staying
up
to
date
and
giving
us
feedback
any
other
announcements
from
folks
things
happening
in
community.
A
No,
if
not,
then
we
can
dive
right
into
the
agenda
today.
The
first
rc
we've
got
is
356..
The
npm
audit
fix
provides
overrides
rebecca.
I
know
you
brought
this
up
and
I
think
we
had
a
good
discussion
internally
about
almost
a
month
back
now.
Did
you
want
to
give
maybe
like
a
little
bit
of
an
overview
of
what
this
is.
B
B
It
hasn't
been
officially
accepted
yet,
but
it's
verging
on
that
and
then
and
then
and
then
work
can
happen
on
that
and
overrides
are
something
you
know
this
got
into
thinking
about
the
problem
of
hot
patches,
basically
like
if
you
have
a
security
pad.
B
If
you
have
a
security
problem
where
you
need
to
provide
a
hot
patch,
because
the
package
isn't
maintained
anymore
or
you
know
it's
five
major
versions
moved
on
and
the
next
dot
release
was
already
released
for
the
one
that
has
a
problem
and
like
you,
you
can't
just
you
know
easily
do
a
a
a
new,
a
new
simver
compatible
release
to
fix
the
problem,
so
probably
more
of
a
problem
when
the
maintainer
is
just
unavailable,
which
happens
a
lot
with
older
modules.
B
B
Normally,
the
audit
advice
is,
you
know,
switch.
You
know
switch
to
this
version.
If
it's
a
minor
bump
or
you
know,
here's
a
major
bump
and
you'll
have
to
figure
that
out
on
your
own,
with
the
override
we'd
be
saying
well,
this
is
simver
incompatible,
but
we
assure
you
that
it
will
in
fact
work.
B
So
that's
the
idea.
That's
the.
B
A
B
So
the
idea
is
twofold:
one
is
that,
like
this
becomes
a
kind
of
advice
that
can
show
up
in
the
audit
report
and
then
the
second
part
is
the
audit
fix
when
it
sees
this
advice
can
can
apply
it
to
your
package.
Json.
A
Right
so
it's
all
like
a
resolver
as
well
like
there's
like
yeah
two
pieces,
there's
the
advice
or
like
the
the
overrides
that
we
support.
So
is
the
intent
also
that
how
do
we
add
these
to-
and
I
haven't
done
a
good
job
at
reviewing
this.
But
how
would
we
add
the
recommendations
in
the
in
that
endpoint
or
how
do
you
create
like.
B
So
the
if
you
so
yeah
you'd
have
to
look
at
the
end
point
and
I
haven't
gone
into
that
in
the
rfc
yet
because
I
wanted
to
go
and
like
play
with
it
and
see
it
because
I
want
to
because
any
any
addition
to
it
needs
to
like
still
continue
to
function
with
the
existing
things.
But
you
get
back
a
list
of
actions
to
take
and
each
of
the
actions
have
a
type
associated
with
them
for
the
kind
of
action
it's
taking.
B
So
we
could
introduce
a
new
type
as
one
possibility.
So
right
now,
they're,
like
you
know,
essentially
it's
you
know:
simver
miner,
simver,
major
and
review
manual
review.
Those
are
the
three
types
that
are
in
use
right
now
to
the
best
of
my
knowledge,
and
so
this
this
might
involve
introducing
a
fourth
type.
B
B
I
do
worry-
and
this
is
my
same
worry
about
override,
so
I've
noticed
now
having
looked
at
a
ton
of
yarn
projects
that
use
overrides,
that
they
grow
stale
really
fast,
like
the
you
put
them
in
for
the
the
quick
fix,
because
that's
the
whole
point
right.
You
know
it.
You
need
a
quick
fix
right
but,
like
nobody
goes
back
and
reviews
them.
B
I
found
projects
at
work
that
have
had
overrides
in
place
for
like
two
years
or
so
whenever
I
don't
know
actually
how
long
it's
existed
in
yarn,
but
I
I
remember
seeing
one
commit
that
was
over
a
year
old
that
added
an
override
and
it's
like
that's
locked
back
and
and
no
matter
what
you're
doing,
because
it's
an
override
it's
a
it's
a
hard
pin.
You
knock
out
your
your
lock
file.
B
So
I
just
want
to
make
sure
we
we
consider
that
if,
if
that's,
what
we're
going
to
move
forward
with
related-
and
I
just
want
to
add
this
on-
because
I
think
this
is
important-
this
problem
is
not
just
a
security
problem.
Security
is
probably
the
most
impactful
part,
but
how
you
update
dependencies
is
something
that
we
have
some
pretty
bad
workflows
around
today
in
general.
B
A
I
don't
know
who
was
first
turner.
B
Yeah
yeah
I've
got
a
direct
response
which
is
so
yeah,
so
yarns
overrides,
or
I
forget
what
they
call
them.
Resolutions
are
not
the
same
work
pretty
differently
than
the
way
npm
and
pnpm
work.
Pnpm
is
almost
but
not
quite
the
same
as
npms,
but
the
the
main
difference
here
is
that
in
yarn
you
give
it
a
package
name
or
a
path
to
a
package
name
in
your
dependency
tree
and
say
anytime,
you
see
that
package
name
or
that
that
you
know
or
that
deeper
you
know.
Has
this
parent?
B
Has
this
parent?
Has
this
parent
replace
it
with
this
specific
version,
npm
you're,
saying
anytime,
you
see
this
package
name
at
this
specifier
and
so
for
these
kinds
of
overrides.
I
would
do
it
for
the
specific
version
that
we're
patching,
and
so
that
means,
if
a
if
a
parent
module
wants
a
more
recent
version
than
than
the
one
that
you
have
an
override
for
the
update
will
actually
happen.
B
It
won't
block
the
update
from
happening,
because
it's
only
only
if
something
at
like
if
we
are
saying
three
3.1
is
3.1.0,
is
has
a
security
issue
and
it's
fixed
in
you
know.
You
know
this
special
hotfix
and
somebody
does
an
install
that
now
asks
for
you
know
3.5
of
that
package.
They'll
just
get
3.5
of
that
package,
so
they
don't
get
that
like
locking
down
of
dependencies.
The
way
the
way
yarn
does
so
that
may
resolve
that
concern.
B
It's
certainly
possible
to
end
up
with
overrides
in
your
package,
json
that
don't
do
anything
at
all
in
your
project,
and
so
that's
something
else.
I
think
to
consider
is
like
how
do
we
want
to
clean
those
up?
Because
I
think
that's
a
more
likely
outcome
with
npm.
B
That's
what
I
raised
my
hand
for
you're
gonna,
you're
gonna,
see
my
daughter,
yelling
chips
over
and
over.
While
I
speak
sorry,
so,
oh
man
now
I'm
distracted
and
I
can't
remember
what
I
was
gonna
say
there
was
two
things
that
I
was
going
to
mention,
so
I
totally
agree
that
the
use
case
you
mentioned
greatly
reduces
the
the
worry.
Thank
you.
B
She
loves
chips
and,
and
my
lunch
is
sitting
on
my
desk.
What
am
I
gonna
do
so
right
exactly
who
doesn't
so?
So
I
great
I
agree.
It
greatly
reduces
it
in
that
use
case.
B
B
B
I'm
not
trying
to
discount
that
that
app,
like
the
responsible
application
of
this
feature,
which
is
probably
what
we
should
design
for,
will
be,
will
be
like
you
say
right,
but
but
then
there's
going
to
be
a
lot
of
people
that
that
feels
like
a
concern
with
overrides
generally
and-
and
I
agree
and
I
and
I
think
it
would
be
worth
calling
out
in
this-
that
like
audit
providers
should
like
the
the
actual
application
of
it,
should
be
very
specific
so
that
we
don't
run
into
that.
B
C
E
I'm
confused
as
the
lines
here
because
we're
discussing
overrides
not
audit.
Now
I
don't
know
where
the
boundaries
are
here
of
this
specific
rfc
and
what
we're
discussing
so
more
of
a
point
of
order,
like
are
we
we've?
All
I've
heard,
is
discussion
about
overrides
themselves,
not
what
this
audit
would
mean.
So
I'm
very
I'm
confused
and
I
don't
have
a
lot
of
context
to
help
me.
D
My
question
sort
of
relates
to
that
like,
given
that
the
my
understanding
of
this
rfc
is
that
for
a
specific
vulnerability
that
which,
which
already
comes
with
a
range
of
affected
versions,
that
the
vulnerability
it's
the
audit
warning
itself
should
be
able
to
also
provide
meaning.
The
registry
should
also
be
able
to
also
provide
a
suggestion
to
say,
hey
client.
D
D
D
Okay,
so
only
the
registry
owner,
in
other
words,
would
decide
that
okay.
So
then
that
then
the
next
question
is:
is
there
a
reason
that
adding
a
new
type
makes
sense
to
me
here?
B
F
D
D
Right
right
well
so
so
I
can
see
a
use
case
for
where
the
affected
versions
is
very
large
and
the
versions
that
the
override
applies
to
is
a
subset
of
that.
But
I
do
not
see
any
use
case
for
where
it
is
not
actually
a
subset
meaning.
If,
if
we
can
constrict
this
cl
this
type
to
only
allow
to
override
version
or
versions.
D
That
is
a
subset
of
the
affected
version
range
then,
would
that
mitigate
wes's
concern
and
still
allow
granular
targeting
of
a
specific
version
or
like
if
v1,
v2
and
v3
are
all
affected
like?
But
maybe
you
can
only
do
the
override
for
v3
like
this.
Would
you
be
able
to
do
that,
because
v3
is
a
subset
of
the
affected
versions,
just
kind
of
throwing
that
out
there.
A
Yeah
yeah,
I
think
that
would
be
perfect
and
then
I'm
wondering
also
like.
Is
it
just,
and
I
know
it's
here
to
me:
you
had
your
hand
up
there
for
a
while,
but
just
on
this,
a
little
bit
more
like,
would
it
be
like?
Should
this
be
opt-in
like?
Should
this
type
be
opt-in
like
even
further
than
fix,
like
npm
audit
fix
flag,
like
include
overrides
like,
or
I'm
just
wondering
how
we
introduce
this
in
a
way
that
is
like
more,
I
mean
less
magic
and
more.
I.
B
Mean
fix
is
pretty
magic,
I
don't
know
I
don't.
I
don't
really
see
a
reason
that
we
would
want
to
make
it
like
if,
if
it's
a
safe
update-
and
you
know,
if
we're
providing
a
specific
patch
like
this,
it's
going
to
be
a
very
constrained
set
of
versions.
As
jordan
pointed
out,
because
you
know
you,
you
don't
want
to
hand
pat,
probably
a
specific
version.
In
fact,.
F
C
I
had
that
it
kind
of
ties
into
this
as
well
is
like,
and
I
I
think,
jordan
and
rebecca
touched
on
this.
A
bit
of
like
is
npm
itself
even
gonna,
be
providing
this
like
because
this,
how
do
we
distribute
these
things,
which
is
a
whole
new
registry
thing?
It
seems
like.
Maybe
I'm
wrong.
Maybe
I
don't
understand
something,
but
it
seems
like
there's
like
some
kind
of
new
publishing.
That's
required.
B
No
because
because
npm
supports
aliases,
so
it
can
just
say,
use
this
completely
different
package
publish
to
the
registry.
I
think
I
have
an
example
of
that
of
that
much,
at
least
in
the.
C
B
It
would
be
in
the
the
result
that
you
get
back
from
the
audit
api
cool.
It
would
tell
you
use
this,
got.
A
D
Yeah,
so
I
had
asked
to
try
to
avoid
disrupting
the
meeting
about,
but
again
because
I
showed
up
late,
I
may
have
missed.
Is
there
like
a
concrete
use
case
that
this
would
solve,
because
I
guess
the
I
can
understand
for
a
private
registry
where
a
company
is
able
to
make
a
lot
of
assumptions
like,
for
example,
a
breaking
change
might
actually
just
be
dropping
a
platform
they
no
longer
support
anyway,
and
so
like
that
makes
perfect
sense.
But
for
the
public
registry
is
there
any
like?
When
would
this
be
useful?.
B
Specifically,
I
would
say,
when
you're
floating
a
if
you
need
to
float
a
patch
to
a
package
that
maintainers
are
inaccessible,
so
you're
not
going
to
get
a
patched
version
of
that.
So
it's
not
been
uncommon
for
people
to
go
fork.
B
D
B
D
D
B
C
I
I
would
definitely
say
that
like
even
if
this
feature
is
only
useful
for
private
registries
and
npm,
like
audit
does
nothing
from
like
the
npm
registry.
That's
fine,
like
I,
I
think,
that's
a
totally
fine
feature
to
ship.
D
Yeah,
I
totally
agree
the
reason
I'm
asking
is
because
I'm
trying
to
think
through
unintended
consequences
and
if
for
sure
it
will
never
be
used
by
the
public
registry,
then
like
cool,
I
don't
care
but
like
there
are
no
antenna
consequences
that
matter,
but
but
if,
if
there
is
a
future
use
that
we
haven't
thought
of,
then
I'd
want
to
try
to
think
through
the
implications
of
that.
B
A
Yeah,
what's
you've
had
your
hand
up
for
a
bit?
Did
you
wanna
so.
B
Let
me
just
respond
to
tyranny's
question
in
chat,
because
I
think
that's
valid
is:
can
this
be
published
by
module
authors?
B
I
I
think
that
the
feature
here
specifically
would
not
be
something
that
would
involve
the
module
author
because
they
would
then
just
publish
the
fix,
but
I
think
that
any
data-
and
I
think,
there's
another
rfc
for
this-
that
is
anything
around
an
rf.
An
audit
result
should
be
more
owned
by
the
module
author
than
it
is
today
so
for
adding
this,
and
we
expect
the
public
registry
to
do
it.
B
There
should
definitely
be
some
sort
of
integration
with
the
module
author
to
make
sure
yeah,
approved
or
or
you
know
whatever
it
is
like.
Maybe
if
moment
decided
that
they
wanted
to
use
this
feature
to
shift
everybody
over
to
luxon
like
that,
should
maybe
be
a
fine
thing
like
and
say
like
look,
there's
some
security
vulnerabilities
in
that
move
over
here.
Here's
the
override,
like
I
don't
know,
maybe
I'm
taking
a
whole
nother
step
that
we
don't
want
yeah
yeah.
I
just.
B
A
B
I
don't
think
we
need
a
protocol
for
it
in
the
private
registry
space.
Just
if,
if
npm
is
going
to
utilize
this
in
the
public
registry,
we
need
to
make
sure
that
module
authors
can
have
a
say
in
what
what
results
are
returned.
A
A
Sure
yeah
and
we
can
tap
our
partners
as
well
on
the
registry
side,
feel
free
to
go
on.
E
Car,
okay,
once
again,
I'm
slowly
catching
up
here.
What
we're
proposing
is
a
new
thing.
The
audit
could
return,
the
private
registries
can
implement
and
the
cli
will
pick
up
on,
but
that
we
don't
really
think
the
public
registry
should
even
do
at
this
point
and
that's
fine
if
it
doesn't,
because
it's
just
something
the
cli
can
handle,
because
we
support
many
registries.
E
B
I
didn't
see
it
I
mean,
I
think,
that's
that's
the
only
way
to
add
overrides,
so
I
meant
automatically
like
not
just
like
here's
a
recommendation
that
you
should
add
the
override
here's,
the
json
printed.
One
click
literally
write
it
on
its
own.
Without
yes,
yeah,
that's
the
intent
I'll
make
sure
it's
clear.
D
Awesome
another
thing
that
might
be
nice
is
that
the
information
written
to
package
json
contains
some
sort
of
annotation
like,
for
example,
the
url
to
the
vulnerability
or
something.
A
A
It
might
be
a
log
that
we
could
create.
That
might
be
some
sort
like
we've
done.
We've
started
to
to
do
that
more
and
and
like
with
mpmy
and
explain
it's
like
now
like
we
want
more
information,
it.
B
Actually
overrides
would
be
just
to
store
it
in
the
package
jason
because
again,
my
whole
concern
about
them
going
stale
is
is
a
human
problem
and
the
only
way
to
make
sure
the
humans
see
it
is
put
it
right
next
to
the
the
thing.
So
so,
if
we,
if
we
could
add
to
that,
to
make
it
more
usable
for
other
use
cases
like
this,
I
think
that
would
be
a
great
solution.
A
Yeah,
it's
just
how
in
json
like
comments
on
json,
so
I
just
wanted
to
be
mindful
of
time
here,
because
we
do
have
a
number
of
other
topics
I
want
to
get
to
to
today.
This
is
great,
though
rebecca.
I
appreciate
you
bringing
this
up,
and
hopefully
you
can
move
on
it
quickly
and
and
feel
free
folks
to
add
comments
in
the
rfc
itself
and
hopefully
we'll
get
it
updated
a
bit
and
talk
about
next
week
as
well.
A
If
you're
around
moving
on
to
adding
type
to
npm
init
miles
wasn't
able
to
join
today.
This
is
our
our
roc,
so
essentially
the
topic
of
3
47.
A
A
The
hi
at
the
high
level-
this
was
a
small
improvement.
It's
not
completely,
I
think
refactoring
npm
in
it
itself,
even
though
we've
talked
about
that
and
how
we
could
potentially
consume
the
work
that
the
pkg
js
folks
are
doing
with
the
create
project,
and
essentially
you
know,
managing
your
package
json
and,
and
you
know,
creating
templates
and
that
kind
of
work
that
I
know
that
we've
put
into
that
working
group
yeah
did
you
want
to
top
up
here
jordan.
A
Like
do
you
have
thoughts,
feelings
about
adding
this
as
a
as
a
question
as
you're
going
through
npm
in
it
as
a.
D
Yeah,
I
think
it's
a
very,
very
bad
idea,
and
I
have
two
major
reasons
why
so
the
history
here
is
that
when
we,
the
modules
working
group
intended
this
to
eventually
go
into
npm
in
it
right
like
that
was
that
was
the
original
thinking
is
oh,
this
would
be
great,
we'll
put
it
in
there
there's
two
reasons
why
I
don't
think
we
should
do
it.
One
is
a
timing
thing.
The
tooling
and
the
ecosystem
are
not
ready
for
it.
D
There's
a
bunch
of
things
like
eslint
and
babel
and
typescript,
and
so
on
that
ask
you
to
put
maybe
not
typescript.
Ask
you
to
put
config
in
a
dot
js
file
and
if
you
put
type
module
they
break
because
they
require
a
synchronous,
cjs
file,
and
it
is
not
very
clear
to
users
that
they
can
fix
it.
D
They
can
maybe
fix
it
by
renaming
the
file
to
cjs,
but
only
if
the
tool
supports
that
which
many
don't
or
removing
type
module,
and
so
I
and
then
there's
just
a
bunch
of
tools
that,
like
around
resolution
that
don't
handle
it
appropriately
yet
native
esm
or
the
exports
field
or
js
files
as
es
modules.
So
I
just
think
it's
gonna,
be
it's
gonna,
be
long
a
long
time
before
the
ecosystem
is
ready.
I
think
for
wider
adoption
of
native
es
modules
at
all,
let
alone
type
module.
D
The
second
concern
is,
I
think
this
was
a
very
poorly
designed
package,
package.json
field.
It
turns
out.
I
think
that
this
was
a
very
poorly
designed
package,
json
field,
it's
confusing.
It
implies
that
if
type
type
module
implies
to
people-
and
I'm
not
saying
it
doesn't
apply
this
to
me-
but
objectively
people
have
told
me-
this
is
what
they
think.
It
means
when
I
help
people
in
irc
and
slack
and
so
on
constantly
it
implies
that,
in
order
to
use
es
modules,
the
package
has
to
have
type
module.
That's
false
type.
D
D
Unless
you
also
add
the
exports
field,
oh
and
here's
how
the
exports
field
works-
and
you
know,
even
if
all
the
tooling
supported
it-
which
it
does
not
like
it's
a
very
long
and
complex
thing
to
teach
or
remove
type
module
and
all
the
problems
are
solved
and
then
they
happily
get
back
to
work.
So,
like
I'm
fine,
I
don't
care
if
npm
in
it
silently
adds
typecomm
and
js
because
that's
already
the
default.
D
I
think
that's
fine,
but
I
think
asking
the
question
is
harmful,
because
I
don't
think
it's
possible
to
ask
the
question
in
a
way
that
won't
confuse
people
and
get
them
to
answer
the
actual
wrong
answer
based
on
what
they
think
it
means,
and
I
think
type
module
inherently
is
harmful
at
the
very
least
until
the
whole
ecosystem
is
caught
up,
but
inherently
because
I
think
it's
poorly
named.
A
That's
very
well
worded:
no,
it's
good
good
luck!
Synopsis!
I
don't
know
who
is
first.
Car
west
west
feel
free
to
go.
Okay.
B
I
was
going
yeah
well,
I
have
nothing
to
say,
that's
excellent
and
I
think
that
just
decides
the
issue
right
there.
For
me,
at
least
that
said,
I
think
rick
and
I
have
a
meeting
scheduled
later
this
week
to
do
a
once-over
on
the
pkjs
stuff,
and
that
does
ask
whether
or
not
you
want
common.js
or
module.
I
think
it
would
be
a
great
place
to
sort
of
pilot
this
and-
and
you
know
it-
I-
I
think,
I'm
using
those
tools.
B
I
use
them
instead
of
npm
in
it,
whether
or
not
we're
ready
to
start
recommending
them
for
a
wider
audience.
You
know,
I
think,
is-
is
sort
of
still
up
for
question.
They
may
not
solve
everybody's
problems
either
way.
B
I
think
that's
a
great
place
to
try
out
something
like
this
as
we
move
forward,
since
it
has
much
lower
usage
and
lower
impact
right
now,
and
it
would
be
just
a
really
great
way
for
us
to
get
feedback
so
happy
to
like
spend
some
time
going
through
what
the
next
steps
are
with
more
than
just
rick,
who
I'm
chatting
with
later
this
week
on
that?
If,
if
we
think
that's
a
good
way
to
to
go
forward
with
this
particular
rfc,.
D
Right
yeah,
I
think
people
opting
into
a
tool
like
a
special
init
thing
or
whatever
is
totally
fine
like.
I
think,
because
that
that
provides
ample
opportunity
to
investigate
whether
the
things
I'm
claiming
are
true
to
figure
out,
if
there's
alternative
ways
to
educate
people
and
solve
those
problems,
and
so
on,
I'm
just
very
very
concerned
about
making
it
be
an
implicit
default.
E
Yeah
clear
my
hand
I
npm
and
net
can
run
like
create
react
racked
app
right.
This
is
something
if
I
want
it,
I
can
make
it
and
I'm
a
big
fan
of
letting
the
community
make
these
right.
I
don't
think
npm
should
be
doing
npm
and
niche
slash
wash
big
the
bare
bones.
Maybe
we
throw
common
json
there.
I
don't
even
think
that's
a
good
idea.
E
A
E
Clapping
yeah
so
like,
and
it
should
never
get
anything
new.
The
community
should
decide
what
that
needs
to
do,
and
things
create
like
like
create
react.
App,
that's
a
hard
word
to
say
there
are.
There
are
things
that
will
bubble
up
as
the
canonical
way
that
the
community
is
chosen
to
create
a
common,
js,
app
or
etc.
G
A
Yeah
we
we
got
that
name.
Space
which
is
great
so
create
pkg
is
the
the
package
right
now
that
they're
working
on
bradley
you
have
your
hand
up.
Did
you
want
to
add
something.
F
Yeah
I
just
joined,
because
I
mostly
just
watch
usually
so
someone
to
agree
with
jordan.
Changing
the
default
is
really
bad
in
the
ecosystem.
People
do
this
node's
test
suite
can't
even
run.
If
you
do
this,
there
was
a
pr
to
try
to
change
the
default
as
a
build
option.
In
node,
almost
no
codebase
we
found
ran
if
we
changed
the
default.
F
F
A
If
not,
we
can
move
on
to.
B
One
one
maybe
point
of
order,
then
just
to
prevent
if
we
think
that,
like
gar
said
future
changes
to
npm
init
should
be
made
in
this
alternate
world
that
we're
creating
for
it.
We
should
make
that
clear
somewhere.
Maybe
that's
a
documentation
yep,
maybe
that's
you
know,
I
don't
know
what
it
is,
but
but
we
should
definitely
make
it
clear
that,
like
nbm
init
should
not
receive
new
rfcs
new
prs.
A
Yep,
I
think
that's
a
good
takeaway
for
us
to
to
go
and
document
that
and
yeah
excited
to
see
the
work
that
rick
and
your
southwest
come
up
with
with
the
create
pkg
work.
So,
okay,
if
we
can
move
along
to
pr
2912,
so
this
is
find
dupes
pretty
print.
I
think
this
was
added
roy.
You
want
to
track
this
at
some
point.
A
I
will
link
this
pr.
I
think
this
got
added
a
couple
weeks
back,
I'm
not
sure
if
you
can
provide
some
context
on
it.
This
is
like
improvements
made
to
find.
I
A
I
got
to
give
you
more
time
to
prep
for
the
call
yeah,
so
this
is
changing
the
output
and
you
know
we
can
clean
this
up.
Obviously,
the
idea,
I
think
we
might
have
talked
about
this
a
couple
weeks
back
as
well,
about
just
cleaning
up
the
style
of
this
to
be
more
in
line
with
like
outdated.
A
A
I'll
remove
the
label
sounds
good,
yeah,
okay,
so
moving
on
then
rc
343
by
yourself
roy.
If
you
want
to
provide
some
context
into
the
switching,
we
talked
a
little
bit
about
this
when
you
were
away
two
weeks
back
about
the
switching
the
context
for
workspaces.
A
So
right
now
the
approach
we
have
for
making
I'll-
I
guess-
lead
you
into
this,
but
the
approach
that
we
have
for
making
sub
commands
workspace
aware
is
to
sort
of
take
the
approach
that
we
are
jumping
into,
almost
as
if
you
would
cd
and
then
run
the
npm
command
in
that
in
what
workspace
directory,
and
so
the
idea,
I
think,
with
this
roc-
and
you
can
correct
me
away-
is
that
to
make
things
more
consistent
for
the
end
users,
if
you
are
running
an
fpm
command
within
a
workspace,
already
you've
cd
yourself
into
that
folder
and
you
run
the
command.
A
I
I
Yes,
that's
a
great
description,
yeah
and
I
did
watch
the
previous
rc
meeting
where
jordan
made
a
bunch
of
comments,
and
I
think
it's
all
very
pertinent.
I
Thank
you
all
for
discussing
that
last
time,
so
yeah
and
I
think
I
had
one
more
concern
to
bring
on
top
that
I
don't
think
was
mentioned
in
the
last
time,
which
is
basically
the
current
workflows,
because
today
there
is
also
like
other
tools
around
workspaces
like
learner,
all
this
that
might
be
taking
into
account
the
fact
that
the
npm
client
is
not
smart
enough
about
that
right.
Now,
right,
like
it's
not
doing,
this
auto
switch
the
prefix
behind
the
scenes,
so
so
yeah.
I
I
think
that's
another
thing
to
take
into
consideration
and
I
think
the
solution
proposed
by
jordan
might
solve
it
in
a
neat
way.
But
I
do
have
a
reservation
about
the
solution,
because
the
idea
of
having
the
npm
rc's
files
within
a
workspace
and
have
the
client
read
that
to
look
up
for
a
workspace
root
or
whatever
the
config
to
let
you
know
that
this
should
then
behave
with
the
auto
switch
that
that
we
want
to
provide
here.
I
D
I'm
kind
of
over
use
cases
for
that.
Right,
like
I
could
have
a
monorepo
where
I
have
one
public
package,
that's
published
publicly
and
only
has
public
dependencies,
and
thus
I
want
it
to
only
fetch
from
the
public
registry
and
then
I
have
another
package,
that's
published
to
my
internal
registry,
and
I
can
do
that
with
publish
config
and
it's
package
json,
but
it
installs
dependencies
for
my
internal
registry,
and
I
want
that
one's
registry
setting
to
be
the
internal
registry.
B
B
It's
going
to
add
a
ton
of
debugging
steps
to
people
trying
to
figure
out
why
their
client
is
not
doing
what
they
thought.
It
was
supposed
to
do
like
thinking
about
like
the
works
on
my
machine
issues
related
here
right,
it's
going
to
be
like
what
directory
did
you
run
that
command
in
when
we're
trying
to
help
people
debug
and
that's
going
to
be
really
confusing?
So
I
raised
my
hand.
What
was
that.
B
B
B
That
happens
as
soon
as
you
add
that
complexity
that
we
we
sort
of
avoid
today
by
having
just
the
one
right
like,
and
I
think,
there's
a
lot
of
value
there-
that
the
reason
I
raised
my
hand
was
specifically
to
bring
up
that
issue,
which
I
I
got
really
on
board
with
that
idea
in
the
last
call
I
was
like
yeah.
This
sounds
great.
B
This
actually
solves
it
really
well,
but
it's
the
it
solves
this
problem
well,
but
it
makes
other
problems
I
think
significantly
worse
and
and
that-
and
that
is
my
biggest
concern,
so
an
example
that
I
was
thinking
of
that
I
was
going
to
share
is
say:
you
have
a
registry
config
for
install
in
a
child,
rc
npmrc.
Well,
how
does
the
workspace
work
now
right?
Because
now
things
that
came
from
that
child
package
should
come
all
from
one
other
registry,
but
the
root
doesn't
have
that
registry.
B
D
D
D
So
I
like,
I
agree
with
you
that
if
this
is
the
only
reason
to
add
that
complexity,
then
maybe
it's
not
worth
it,
but
I
don't
think
it's
the
only
reason
I
think
it's
I
would.
I
would
politely
say
that
it's
a
bug
that
it's
not
already
supported
and
if
we
fix
that
bug
then
it's
already
supported.
Then
we
don't
have
to
go
with
the
root
prefix
solution,
I'm
actually
not
super
attached
to
it.
D
It
was
just
what
I
came
up
with
spitballing
last
week
right
but
like
whatever
solution
we
come
up
with.
I
I
think
should
just
assume
that
npmrc
files
work
there,
because
that's
how
npm
works
like
already,
if
I
have
an
npmrc
in
30,
nested
folders
and
I
have
30
of
those
files
they're
already
merged
together
like
so
it's.
It
seems
weird
that
the
only
place
that
that
doesn't
apply
is
a
workspace.
D
B
D
If
I,
if
I'm
wrong
about
that,
then
I
withdraw
that
that
reason
to
justify
the
feature
and
that's
fine,
but
I've
people
have
put
user
level
npmrc's
and
it's
messed
with
their
projects,
and
I
didn't
realize
that
even
creating
an
empty
npmrc
might
fix
that.
B
A
Yeah
rebecca,
I
see
your
hand
up
and
then
wes.
If
you
want.
B
Yeah,
I
was
just
going
to
clarify
that
which
is
so
what
npm
does
is
it
scan?
It
looks
for
the
root
of
the
current
npm
project,
and
so
it
has
a
heuristic
for
that,
and
so
it's
looking
for
node
modules
or
a
package
json.
B
B
And
it
says
this
is
my
route
and
then
and
then
it
goes
to
read
the
npmrc
from
there,
but
I
will
say
that
with
existing
like
it,
it's
not
a
hard
and
fast
thing
that
npm
has
to
copy,
but
this
is,
of
course,
ultimately
how
other
workspace
implementations
end
up
working
because
they
didn't
have
any
opportunity
for
special.
You
know
in
pmrc
reading,
so
you
know
if
you're
already
using
workspaces
from
some
other
tool,
you
would
expect
it
to.
A
Work
this
way,
so
on
that
point
I
actually
have
a
question
then,
just
because
I
don't
actually
know
so
in
yarn.
If
I
have
a
yarn
workspaces
project
at
which
they
do
support
and
pmpm
supports,
like
fpmrc
files,
those
are
respected
and
those
are
like
munch
together
properly
in
a
workspace.
If
you're
running,
it's.
B
The
best
nightmares
they're
not
munged
together,
it's
replacement,
replacement,
okay,
but
I'd
have
to
verify
that
I
can't
speak
definitively
to
that
learner.
Of
course,
not
being
package
manager
specific
ends
up
just
doing
the
you
know,
it
literally
runs
into
the
npm
command
from
the
subdirectory
and
follows
npm
semantics.
A
Okay,
so
in
terms
of
the
this
rfc,
then
I'm
wondering
like
what
we
should
like.
What's
an
actual
next
step
here,
I
feel
like
roy,
like
we
would
have
to
update
this
to
include
maybe
jordan's
recommendations.
If
we
want
to
go
that
route
or
we
back
out
and
and
just
say,
this
isn't
supported
for
for
now,
yeah.
I
A
Can
you
also
maybe
provide
more
use
cases
or
more
examples
of
just
the
expectations
like
yeah?
I
don't
remember
what.
A
I
Just
trash
is
your
you
know,
so
it
would.
It
should
just
make
that
auto
switch,
especially
in
the
install
scenarios
where
the
user
just
wants
to
add
a
dependency
there,
so
yeah
so
yeah.
I
can
definitely
add
more
examples
and
add
a
little
bit
more
of
the
feedback
from
these
discussions.
It
was
pretty
much
a
bare
bones
when
I
first
opened
it,
it
was
just
to
get
the
conversation
started.
E
D
I
D
Declared
well,
I
think,
regardless
of
the
mechanism
it
seems
like
there
are
like
there's
two
properties
here
that
I
think
are
somewhat
conflicting,
but
that
are
both
valuable
to
have
one
is.
I
want
my
child
project
to
behave
as
if
it
wasn't
inside
a
workspace
just
like
meaning
it's
the
same
meaning.
If
I
move
it
out
of
a
workspace,
I
and
I
move
it
into
a
workspace.
Nothing
changes
as
long
as
I'm
seated
as
the
directory,
and
I
run
the
same
commands.
D
That
is
how
I
prefer
to
do
it,
but
I
also
see
the
value
of
the
other
viewpoint,
which
is,
I
want
my
child
project
to
know
it's
part
of
a
workspace
so
that
it
always
when
I
run
a
command
inside
it.
It
always
does
the
workspace
appropriate
thing,
and
you
know
I
am
willing
to
accept
that
that
the
one
I
want
isn't
the
one
most
people
want
and
that's
fine,
but
I
think
that
they're
both
valid
right.
So
I
don't
actually
care
what
the
default
is.
D
I
could
live
in,
npmrc
doesn't
matter
but
like
whatever
would
make
sense,
but
but
if,
as
long
as
there's
an
explicit
way
to
do
that,
then
with
either
default,
npm
workspace
in
it
can
stamp
it
in
there
and
with,
and
someone
who
wants
to
do
it
differently
can
alter
that
and
then,
like
we've,
provided
both
use
cases
in
a
sort
of
clean
and
explicit
way,
and
you
know,
there's
more
complexity
to
debug
for
wes's
case,
but
like
at
least
it's
an
explicit
thing.
That
can
be
like
known
to
look
for
yeah
tuning.
D
I
don't
think
so,
but
my
assertion
from
many
other
workspace
discussions
on
this
rfc
call
is
that
there
does
not
exist.
Another
workspace
implementation
that
does
anything
correctly
because
hoist
and
no
haste
is
like
inherently
flawed.
Like
I
mean
I'm
not
like
judging
them
for
understanding.
D
C
A
Yeah,
I
do
think
that
yarn
has
the
ability
for
you
to
map
back
to
the
workspace.
So
that's
the
only
like
similar
kind
of
mechanism.
I
I
believe
that
exists
today,
but
yeah
roy.
I
see
you
in
hand.
I
Yeah,
I
know
I
was
just.
I
was
precisely
going
for
no
voice
as
an
example,
but
even
though,
let's
not
judge
the
merit
of
the
good
or
bad
solution,
but
it
is
just
a
way.
I
So
basically,
we
can
detach
this
proposal
from
the
npm
rc
idea,
at
least
so
that
at
least
we
can
move
them
in
parallel,
and
so
because
the
no
hoist
con
configuration
itself
like
is
an
example
of
being
able
to
define
a
property
right
within
the
child.
Workspace
and
just
have
that
be
part
of
the
logic
there
for
the
client.
So
maybe
we
can
propose
having
a
nested
property.
I
A
Yeah
just
to
be
mindful
of
time
so
the
action
here,
roy
you're
gonna,
provide
both
those
options,
essentially
in
this
rfc
or
at
least
document
them,
and
then
we
can
at
least
discuss
the
merit
of
both
and
keep
this
open
for
now
and
just
again
be
mindful
of
time.
We
had
a
number
of
other
issues.
A
I
I
know
that
we
want
to
get
to,
but
I
know,
isaac
and
nilf,
who
I
think
own
a
bunch
of
these
aren't
aren't
here
this
week
and
then
the
other
item
on
here
1a2
rc
182,
for
audit
licenses.
I
know
tierney
we've
gone
back
and
forth
a
little
bit
about.
This
is
something
we
want
to
do.
A
We
can
move,
I
think
forward
with
it
async,
probably
and
and
flush
things
out,
and
then
the
other
item
we
weren't
able
to
get
to
today
is
sort
of
the
optional
install
agenda
item
that
I
hit
here.
The
only
reason
why
I
added
that
was
just
to
basically
say
that
you
know
this
seems
like
something
that
can
be
done
now,
based
on
the
filtered
install
support
that
we've
provided
with
workspaces.
So
you
could,
potentially,
you
know,
put
different
dependencies
in
more
spaces
and
optionally
install
them
that
way.
B
B
Every
issue
we
come
up
with,
which
is
like,
let's
do
an
improvement
or,
let's
add
a
feature
or
whatever
it's
like
yeah,
but
foundationally
workspaces
need
improvement
so
like.
Why
are
we
continuing
to
circle
around
this
and
spending
time
when
we
should
probably
just
set
aside
some
time
figure
out
some
sort
of
plan?
Even
if
it's
not
like
an
rfc,
that's
going
to
be
implemented
just
now,
it
would
just
save
us
from
like
rehashing
that
conversation
over
and
over
and
over
again,
like
we
have
been
okay.
A
Let
me
propose
like
the
agenda
for
what
that
would
look
like
in
a
in
a
separate
issue,
and
we
can
queue
that
up
roy.
Did
you
have
a
rebuttal
before
we
close
out.
I
It
is
just
that
we
schedule
that
conversation,
but
it's
probably
going
to
be
an
npn
8
kind
of
thing,
because
we
have
yeah
so
for
the
sake
of
in
game,
7
we're
shipping
the
commands,
we're
making
it
so
that
they're
actually
usable
right
for
the
community.
So
we
still
have
to
just
figure
out
this
remaining
really
because
these
are
fundamental
things.
We
want
to
figure
out
for
npm
7,
but
then
we
want
to
have
the
conversation
on
how
it's
going
to
look
like
moving
forward.
B
Fully
in
support
of
that,
I
didn't
mean
to
disrupt
that.
I
just
hate
that
we
have
circled
around
this
issue
on
the
rfc
calls
specifically.
So
if
we,
if
we
can
come
up
with
a
really
good
plan
on
a
deep
dive
and
only
take
your
time,
your
folks
time
for
like
an
hour
or
two
or
something
and
like
really
figure
out
like
what
we
think
would
would
be
the
list
of
requirements,
and
then
we
table
that
until
npm
8
is
you
know
under
development?
That's
perfectly
fine
by
me.
I
just
don't
want
to
have.
B
We've
spent
a
lot
of
time
on
these
calls
over
the
past
few
months.
Circling
around
this
like,
but
but
workspaces
as
defined
before
in
prior
art
are
broken.
Let's
fix
them
and
like
that,
it
just
seems
like
it'll
save
us
a
lot
of
time
in
these
other
topics.
If
we
for
npm
7
specifically,
if
we
can
have
a
plan
for
eight-
and
we
can
always
then
just
like
take
a
thing
that
we
discuss
here
and
table
it
to
that
eight
discussion,
which
will
be
just
a
lot
easier
to
manage
the
discussion.
I
think.
A
Okay,
apologize
we're
a
couple
minutes
over
appreciate
everybody
jumping
on
again
today
and
and
hopefully
feel
free
to
continue
to
give
feedback
and
and
keep
conversation
going
in
the
rfcs
themselves
and
we'll
be
back
ideally
next
week
same
time,
the
same
place.
So
thanks
everybody
for
for
joining
today,
cheers.