►
From YouTube: Open RFC Meeting - Wednesday, April 14th 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
fdm,
open
rc
call
appreciate
you
joined
today.
Today's
date
is
wednesday
april
14th,
2021
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
367
in
the
mpmrcs
repo
and,
if
you
haven't
already
feel
free
to
add
yourself
to
the
attendee
list
in
the
hack
md
dock
that
I
just
copied
and
pasted
in
chat
and
we'll
get
started
since
we
have
a
pretty
decent
sized
agenda
today.
A
Quick
reminder
these
calls
and
all
comms
on
the
rfc's
repo
and
on
all
npm
repos
and
projects
are
governed
under
a
code
of
conduct
that
we
expect
and
and
hope
folks
will
abide
by
and
appreciate
you
being
kind
and
mindful,
as
other
people
are
speaking,
if
you'd
like
to
add
or
comment
on
something
feel
free
to.
Please
raise
your
hand
and
I'll
call
on
you
and
yeah.
I
just
want
to
make
sure
that
everybody's
got
a
chance
to
read
that
and
yeah.
A
A
If
not
no
announcements,
we
can
dive
right
in.
I
put
in
the
first
section
here,
a
few
rc's
that
we've
been
keeping
open
for
a
while,
specifically
the
the
overrides
registry
protocol
and
the
workspaces
v2
work,
which
our
team
has
delve
into
pretty
headfirst,
so
just
want
to
essentially
identify
those
as
good
first
topics
to
essentially
decide
whether
or
not
we're
ratifying
them
and
moving
them
into
accepted.
B
Yeah,
it
looks
like
there's
some
unanswered
comments
in
the
overrides
one,
I'm
not
sure
if
they
need
this
to
be
answered,
but
for
to
be
accepted,
but
I
just
want
to
make
sure
we
pointed
out
that
the
last
comment
from
isaac
seems
to
address
some
of
zoltan's
concerns,
maybe
but
then
there's
a
few
others
after
it
just
sort
of
asking
things.
So
if
we're
going
to
close
it
and
merging,
we
might
want
to
also
follow
up
with
answers.
There.
A
Isaac,
I
know
that
this
is
your
rc.
Did
you
want
to
like
respond
to?
Maybe
I
guess
the
one
question
is
there
another
one
that
you
saw
specifically
wes?
I
see
dominicus's
question
at
the
end,
they're
from.
C
Yeah
I
mean
there
was
some.
There
were
some
suggestions
that
zoltan
had
made.
That
would
have
either
they're,
not
bad
ideas,
but
I
think
we
talked
about
them
a
little
bit
and
kind
of
decided
that
they
were
either
unnecessary
and
kind
of
just
unnecessary
bike.
Shutting
or
would
make
the
implementation
a
little
harder
or
make
the
usage
of
it
a
little
more
confusing.
So
we
kind
of
punted
on
a
lot
of
that.
C
But
yeah
it
looks
like
I
mean
basically
where
this
still
is
is
every
time
we
talk
about
it,
we're
like
yep,
that's
pretty
much.
What
we
want
to
do.
I
just
haven't
gotten
around
to
digging
into
the
implementation.
I
think
workspaces
have
taken
a
higher
priority
since
then,
so
it's
just
time
and
typing
holding
it
back.
So
I
mean,
I
would
say,
yeah
let's
go
ahead
and
ratify
it.
We
can
always.
When
we
get
closer
to
implementation.
We
can
always
change
it
if
need
be.
A
So,
okay,
great
moving
on
then
to
the
second
item
there.
That
was
the
registry
protocol
is
this
I
feel
like
this
is
in
a
similar
state.
This.
C
One
this
one
actually
had
a
somewhat
subtle
and
kind
of
interesting
and
weird
impact.
So
if
you
and
and
it's
I
think
where
we-
the
reason
why
we
haven't
moved
forward
on
it
is
because
this
is
not
not
been
addre
not
been
fully
resolved.
So
the
issue
is,
if
I
have
a
if
I
list
a
dependency
with
a
registry
specifier
and
then
that
package
has
a
dependency
which
is
just
a
normal.
You
know
foo
at
1.x.
C
That
we're
pulling
that
thing
out
of
my
my
intuition
is
yes,
we
should
like
a
registry.
Specifier
should
basically
be
contagious
throughout
the
rest
of
the.
You
know
that
that
is
now
the
new
default
registry
for
all
things
down
that
branch
of
the
dependency
graph.
C
The
problem,
when
you
have
a
registry
which
is
not
proxying
and
only
contains
you
know,
only
contains
the
things
that
you
want
to
override
you
end
up
in
the
state
where
you're
going
to
get
404s
and
then
we
last
time
we
talked
about
we
kind
of
talked
about.
Well,
maybe
do
we
want
to
try
that
registry
for
its
steps
and
then
fall
back
to
the
default
registry,
but
then
you're
just
essentially
opening
the
door
to
name
hijacking
attacks
right
like
and
that's
what
we
want
to
avoid.
C
So
it's
it's
better
in
my
opinion,
like
the
case
that
I
would
make.
I
guess
I
need
to
write
this
down
in
text
on
the
issue,
but
the
case
that
I
would
make
is
if,
if
you've
published,
foo
and
bar
into
your
private
registry,
you're
kind
of
expecting
that
people
who
are
you
know
today
with
npm
six,
seven
yarn
one
and
two
whatever
you're,
expecting
that
people
are
only
installing
that
thing
by
doing
npm
install
food
dash.
Dash
registry
equals
my
private
registry
right.
C
A
Yeah,
I
see
some
comments
from
jordan
and
wes
and
I
also
saw
rebecca
you
raised
your
hand
or
clapped
there
for
a
second
did.
You
want
to
top
up
no.
E
No,
that
was
that
was
really
I
isaac
got
to
where
I
was
going
with
that,
which
was
just
that
any
existing
private
registry
has
to
be
it.
That's
not
intended
for
that's
not
used
with
scopes
has
to
be
proxying
already,
or
at
least
that
package
has
to
be
fully
installable
from
that
registry
for
it
to
work,
so
it
doesn't
break
anyone
to
go
that
route,
and
I
think
that
is
a
you
know.
Install
everything
from
the
registry
that
that
package
came
from
makes
a
lot
of
sense.
C
Yeah
the
the
argument
against
it,
which
I
I
don't
think
is
very
compelling
not
to
not
to
you,
know,
undersell
it
before
I
present
it,
but
the
argument
against
it
is,
I
might
want
to
let's
say,
fork,
express
but
not
fork.
C
C
And
to
kind
of
get
out
of
that
that
world
so
or.
C
Sensible
registry
already
does
right
right
exactly
so.
I
think
it's
entirely
a
hypothetical
that
doesn't
exist
in
practice
and
if
we
just
make
the
feature
work
that
way,
then
we're
not
we're
not
taking
anything
away
that
currently
exists.
Yeah
we're
taking
something
away.
That
is
probably
a
bad
idea
to
make
exist.
Yeah.
C
D
D
And
the
the
other
thing
is
once
overrides
exist
with
the
registry
specifier.
If
somebody
created
a
package
with
this
ill-advised
feature
in
mind
that
could
always
be
fixed
by
at
the
top
level,
using
overrides
to
say
actually,
this
forked
expresses
you
know
each
of
these
dependencies
should
come
from
this
other
registry
right.
C
It
would
be
it
would
be
possible,
but
it's
not
significantly
easier
than
just
putting
that
in
the
package.json
of
your
forked,
express
because
sure,
because
you
have
to
specify
every
one
of
those
like
there's,
there's
no
way
with
the
overrides
syntax
as
we
have
it
presented
so
far,
there's
no
way
to
say
everything
down.
This
branch
of
the
dependency
graph
means
to
use
this
other
registry.
B
Right
parent
parent
package
jsons,
so
so
I
say
I
decide
I
want
which
I
think
this
is
a
great.
These
are.
These
are
where
simple
features
come
together
to
give
you
real
power,
say
I
decide
to
finally
like
take
what
is
express5
and
publish
it
to
an
alternate
registry
and
tell
people
hey
like
yeah.
I
know
it's
never
going
to
happen
in
the
main
line,
but
like
here
I
am
supporting
it.
B
B
C
Yeah
that
provides
a
way
to
do
that
so
yeah.
I
think.
That's
fine,
then
I'll.
Just
I'll
update
the
registry
specifier
to
to
add
that
that
behavior
it
does
make
the
the
implementation
a
little
more
involved,
because
we're
going
to
need
to
it's.
Not
it's
not
just
simply
an
update
to
npm
package.
Arg
right,
it's
it's!
Actually
it's
actually
going
to
be
it's
going
to
affect
the
whole
build
ideal
tree
process.
C
C
D
C
C
No,
I
well
so
it's
worth
mentioning,
I
guess
the
other
part
of
the
conversation
where
it
was
kind
of
going.
C
Zoltan
and
male
were
sort
of
objecting
to
taking
this
small
of
a
step
without
specifying
what
the
sec
the
next
step
would
be,
and
I'm
strongly
opposed
to
specifying
more
steps
than
we're
currently
taking
than
the
next
one,
but
what
they
were
looking
for
was
basically
a
way
to
say
you
know,
define
a
short
name
for
a
registry
in
your
package
json
and
be
able
to
say
okay,
so
the
you
know
anything
that
is
foo
colon
should
expand
to
registry
colon
https
food.com,
whatever,
which
feels
like
a
pretty
small
ergonomic
fix
to
our
repackaged.
C
So,
there's
a
little
bit
of
an
open
question
there
about
whether
it
should
be
package
specific
in
package
json
and
in
the
manifest
or
if
it
should
be
a
config
level
setting.
I
would
prefer
it
to
be
in
package.json
actually
because
then
otherwise,
your
your
package
is
not
installable.
Unless
somebody
has
the
same
configs
as
you,
which
is
a
situation,
we
generally
try
to
avoid.
C
Yeah
yeah,
essentially,
although
with
scopes,
it's
somewhat
more
contained
problem
but
yeah,
it's
it's.
We
don't
want
to
get
into
a
situation
where
you
have
things
published
on
the
public
registry
with
a
short
name.
E
I
mean,
wouldn't
you
be
getting
the
equivalent
of
a
404
if
it
was
with
a
you
know,
undefined.
C
E
It
also
it
creates
a
disincentive
to
using
this
feature
on
the
registry,
because
it
has
to
be
on
your
npm
rc
versus.
If
it's
your
package
json,
then
it's
perfect,
like.
I
think
that
that
that
to
me
is
like
the
policy
question,
because
if
you
put
it
in
the
package
json,
then
it
becomes
a
well
then
this
is
an
appropriate
thing
to
use
on
the
public
registry,
which
might
be
what
you
want.
C
Right
right,
yeah,
that's
I
mean
that's.
That
is
a
good
point.
If
we
don't
want
people
publishing
packages
that
can
only
be
installed
with
npm,
seven
then
yeah.
That
is
an
argument
in
favor
of
making
it
a
config
level
thing,
but
they.
C
Yeah,
but
it's
notoriously
tricky
to
figure
out
that
right.
Like
I
every
time
we've
gone
down
that
road
of
saying,
like
we'll
force
you
to
have
an
engine's
npm
that
limits
it
to
that
version,
because
that
can
take
an
arbitrary
summer
range
that
is
pretty
tricky
to
know
if
you
are
specifying
it
correctly
or
not.
A
Separate
that's
a
separate
rfc
from
the
registry
specifier
yeah
yeah.
So
I'm
wondering
I.
E
Would
like
to
better
understand
what
the
concern,
because
it
I
felt
like
they
were
concerned
that
zoltan
and
male
had
concerns
about
what
the
you
know.
Just
the
registry,
the
registry
specifier
itself
like
they
were
like.
Well,
we
might
accept
this
more
complicated
version,
but
we
never
want
to
see
the
registry
specifier
and
I'd
like
to
understand
those
concerns
better.
C
The
argument
that
I
yeah
I
would
too
I
mean
the
argument
that
I
got
from
them,
was
basically
that
urls
are
tricky
and
people
get
them
wrong,
which
which
I
mean
okay.
Well,
that's
that's
a
weird
argument.
It's
also
the
building
block
of
the
internet
and
like
people
can
copy
and
paste
it.
I
mean
I
said
like
I
don't
really
understand
the
objection
here
and.
C
C
Yeah
also,
it's.
C
The
comment
about
using
tarball
urls,
it
does
allow
sember
ranges
which
you
can't
do
with
a
tarball
url
and
also
we're
going
to
have
this
feature
restriction
where
once
we
kind
of
encounter
one
of
those
things
all
of
its
dependencies,
effectively
become
scope
to
that
registry.
So
that's
another
thing
you
don't
get
with
urls.
I
think.
C
Right
now,
using
more
than
one
private
registry
at
once
is
pretty
challenging.
Even
if
you
have,
I
mean
you,
basically,
you
essentially
have
to
map
them
to
scopes.
Otherwise,
there's
no
way
to
do
it.
C
Right
right,
you
have
your
private
right,
one
private
registry
proxy
to
another
or
something
there
are.
There
are
examples
out
there
in
the
wild
with
sneak
and
some
other
like
use.
Our
you
pay
us
money
and
you
get
access
to
our
private
registry,
which
has
our
private
code
in
it
type
of
products
and
using
more
than
one
of
those
at
once
is,
is
very
hard.
A
So,
just
to
be
mindful
a
time,
so
it
sounds
like
we're.
Gonna
take
this
away
at
that
line
and,
if
that's
in
there,
just
essentially
the
implementation
detail.
Note
that
we're
talking
about
adding
are
we
okay
with
like
ratifying
that
as
well?
I
mean
do
we
want
to
look
at
the
language
next
week
or
like
leave
it
open
for
another
week
then,
or
can
this
just
be
updated
and
pushed
through.
A
A
Comment:
okay,
thank
you.
So
the
last
one
here
that
I
has
been
open
for
a
while
and
we've
already
been
doing,
a
lot
of
work
in
this
space
is
the
sort
of
workspaces
v2
work
which
we
kicked
off
and
making
mpm
commands
workspace
aware
through
the
the
two
configs
that
we've
included
here.
This
is
another
one
where
you
know
we're
already
starting
to
implement
this,
so
it
feels
like
it
should
be
ratified
already
and
yeah.
A
If
there's
any
cleanup,
I
think
roy
you
know
is
there
like
anything,
you
were
hoping
to
change
this
before
we
would
move
it
forward.
I
know
there
was
some
discussion
by
zoltan
and
jordan
again
about
terminology.
C
The
yeah,
the
other
thing
I
was
going
to
mention-
was
that
we
should
take
make
a
make
a
comb
through
that
rfc
and
make
sure
that
everything
that
it
says
is
actually
what
we
landed
on
doing,
because
I
know
there
have
been
a
couple
of
edge
cases
we
ran
into
in
the
implementation
where
we
were
like.
Oh
hey,
this
doesn't
make
sense.
We
have
to
go.
Do
you
know?
C
Do
it
the
subtly
different
way
it
might
be
worth
kind
of
outlining
in
there
also
how
how
workspace
scoped
reification
works,
because
that's
that's
also
something
that
I
think
we
didn't
fully
understand
how
to
do
it
until
we
started
doing
it.
A
Yeah,
so
it
sounds
like
action
item
is,
then:
is
it
okay
to
leave
that
with
you,
roy
and
maybe
I'll
I'll,
add
myself
there
and
we
can
maybe
pair
on
we
have
a
paying
session
this
week
you
can
potentially.
A
F
C
That
feels
like
it
might,
it
might
be
excessive,
for
you
know
maybe
like
link
to
it
as
a
supplemental
reference
or
something,
but
for
the
rfc
in
particular.
The
the
key
I
think
is
so
that
anybody
who's
working
with
node
modules
or
or
with
npm
has
a
better
idea
of
what
how
how
it
is.
We
do
what
we
do.
A
Yeah
and
wes,
I
see
your
comment:
docs
are
better
than
rfc
content,
so
just
the
continue
to
improve
those
which
we're
we're
trying
to
do
so
with
each
one
of
these
commands,
as
they
ship
we're,
actually
updating
the
docs
and
they
those
get
updated
with
every
every
release.
Now
so
we're
pretty
much
in
sync.
So
also,
if
you
feel
like
you
want
to
improve
the
docs
feel
free
to
to
go
in
there
and,
like
add,
appear
yourself
as
well,
which
is
great
okay.
A
So
I've
put
an
action
item
we'll
leave
this
open
for
now
then,
and
it
sounds
like
there's,
some
cleanup
work
still
to
do
and
roy
can
work
with
you
to
get
this
in
good
state,
so
we
can
hopefully
review
it
next
week
and
just
push
it
forward,
because
I
it's
been
open
for
for
a
really
really
long
time
like
yeah
year
year
and
a
half
or
something
so
okay.
I
want
to
move
on
quickly
to
then
the
next
rc
that
we
have
open
here.
A
Rebecca's
npm
audit
fix,
provides
overrides,
and
this
is
rce
number
356..
We
talked
about
this
a
little
bit
last
week
and
this
is
dependent
on.
I
think
the
you
know
the
obviously
overrides
landing
in
npm.
So
did
you
want
to
speak
to
this
a
little
bit?
I'm
not
sure.
If
you've
got
time
over
the
last
week
rebecca
to
work
on
some
of
the
feedback,
I
think
that
we
suggested
use
cases.
E
Yes,
which
I
did
add,
and
then
I
realized
that
just
now
that
I
didn't
update
the
link
to
the
to
the
rendered
version,
and
so
I
was
really
clicking
on
it
going.
Why
didn't
it
change?
Okay?
So
yes,
so
I
added
a
hotfix
scenario,
also
spent
some
more
time.
Looking
at,
like
the
changes
to
the
new
audit
in
plane,
and
so
essentially
like
this
is
the
scenario
of
critical
security
flaws
found
in
the
dependency
of
one
of
your
dependencies.
E
The
author
of
a
transitive
dependency
is
unavailable
to
provide
updates
packages
widely
used
within
your
organization.
The
ecosystem
will
eventually
switch
to
another
module,
but
in
the
meantime
you
need
some
sort
of
remediation.
E
So
you
instruct
your
private
registry
to
provide
audit
results
for
the
affected
version
of
the
module
to
indicate
that
a
custom
patched
version
is
available,
and
then
I
give
an
example
of
what
those
results
might
look
like
and
then
that
instructs
npm
audit
fix
to
edit
your
override
section
to
include
that
that.
A
Patch,
so
for
folks
that
I
know
isaac,
this
is
probably
first
time
you're.
Looking
at
this
as
well,
we
spoke
a
little
bit
about
like
this
is
introducing
a
new
type.
Is
that
right,
and
essentially
we
would
be
well.
E
So
the
audit
results
changed
a
lot
between
when
that,
when
I
had
last
worked
on
them
and
now
so
yeah
so
vita,
you
know
the
well
specifically
the
bulk
endpoint
versus
the
old
regular
audit
endpoint.
So
the
audit
endpoint
would
tell
you
here
are
the
vulnerable
versions
and
here's
what
you
should
and
here's
our
advice
as
to
what
you
should
use
and
the
bulk
endpoint
just
says:
these
are
the
vulnerable
versions.
E
It
returns
the
advisories
that
apply
to
your
tree
and
that's
it
so
that
changes
it
slightly
and
that
we're
not
going
you
know,
yeah,
you
don't
you
don't
provide
update
advice,
but
we
can
say
these
are
the
overrides
available
for
the
version
that
you're
using
if
there
are
any.
E
So
if
you
click
through
on
my
the
updated
the
example
in
this
the
scenario,
I
think
it
makes
it
clearer
than
what
I'm
saying.
C
C
We
could
start
putting
this
in
the
in
the
batch
endpoints
now
and
there's
really
no
harm
in
it,
because
it
just
ignores
extra
keys
anyway,
obviously
becomes
more
valuable
once
we
support
overrides
at
all.
Yes,.
C
Right
and
we'll
still
try
to
find
whatever
version
we
can,
then
then
I
guess
the
other
question
becomes
so
this
is
like
good.
As
kind
of
I
like
that,
this
is
so
small
as
an
rfc.
The
the
subsequent
question
becomes
like.
What
do
we
do
with
that?
Do
we
automatically
put
the
overrides
in?
Do
we
prompt
and
let
you
you
know,
is
there
a?
E
E
C
Yeah
yeah
yeah,
but
if
you,
if
you
do
request,
I
mean
I
guess
the
question
I'm
saying
is
like:
if
you
did
npm
audit
fix,
is
there
is
it?
Is
it
a
bigger
change
to
say
I
want
to
fix
this
with
an
override
or
should
fix
kind
of
treat
and
override
as
something
more
aggressive
or
a
different
ux.
C
D
Given
that
an
override
is
supposed
to
be
overriding,
a
specific
set
of
vulnerable
versions,
if
the,
if
npm,
if
the
cli
first
says,
is
there
like,
let
me
first
try
to
upgrade
it
without
the
overrides
and
then
see
if
the
overrides
still
apply
right.
That
means
that,
like
like
that,
ensures
that,
if
a
newer
version,
that's
fixed
comes
out
that
the
override
just
kind
of
fades
away,
and
then
by
default,
people
get
exactly
what
they
want,
which
is
trusting
their
registry
and
getting
a
fixed
version
as
much
as
possible.
C
So
you
should
talk
about
that
right
so
because,
even
even
if
we
automatic
you're
right,
that's
a
good
point.
So
even
if
we
automatically
apply
the
override
we're
first
going
to
try
to
find
a
version
that
doesn't
need
the
override
yeah
right
and
it'll
only
apply
to
packages
that
are
within
that
vulnerable
range
anyway,
yeah
cool.
I
dig
it.
A
Apologies,
I'm
just
taking
notes
here
trying
to
capture
things,
so
we
should
talk
about
we'll
look
connected
in
terms
of
next
steps
here.
C
E
I
mean
I'm
okay.
One
thing
I
would
like
to
be
able
to
know
in
advance
is
what
the
is
is.
What
the
api
changes
to
the
audit
endpoint
will
look
like
like
I,
and
they
could
be
the
the
examples
here,
although
I
think
I'd
want
to
actually
write
it
out
as
like.
This
is
what
the
change
is,
because,
like
I'll
be
getting
ahead
of
that
on
my
side,
to
do
to
do
things
with
that
with
that
change.
If,
if
it's,
if
I
know
what
it's
going
to
be.
C
I
will
I'll
take
an
action
item
to
just
kind
of
read
through
this
and,
and
you
know,
spend
an
hour
meditating
on
what
the
what
kind
of
cases
we
definitely
want
to
be
able
to
cover
in
this,
but
I
think
I
mean,
I
think,
what
you
at
first
glance.
What
you
have
here
looks
pretty
much
what
I
would
do,
so
I
don't
think
there's
any
hazard
in
committing
to
a
an
api
change
at
this
point.
C
B
B
E
Sorry,
good
I
I
was
going
to
say
I
would
think
this
is
kind
of
a
more
general
thing
of
like
what
do
you
do
when
your
package.json
has
a
bunch
of
overrides
that
don't
apply
to
your
tree,
because
this
does
not
stop
the
client
from
updating
the
package
like
this
is
just
saying
if,
if
you
resolved
to
3.0.0,
go
use
this
other
thing
instead.
But
if
the
client
resolves
to
3.0.1,
it
doesn't
use
the
override.
B
C
Well
right,
but
if
you,
if
you
then
later,
like
you
kind
of
you
kind
of
want
to
keep
that
override,
even
when
it
no
longer
applies
to
your
tree,
because
if,
if
you're,
depending
on
something
else
or
you
pull
in
something
else
now
at
a
later
date,
that
depends
on
that
vulnerable
version.
B
So
being
a
never-ending
list
that
just
gets
a
only
list
is
like
not
going
to
be
great,
especially
since
it's
in
the
package
jason.
I
I
think,
there's
a
broader
category,
though,
as
rebecca
mentioned,
which
is
like
which
is
not
specific
to
this
rfc
right,
and
so
I
think
we
should
just
be
considering,
like
maybe
adding
to
npm
doctor,
although
npm
doctor
is
not
something
people
run
very
often
so
like,
and
it's
also
kind
of
slow
and
checks.
B
It's
on
other
things,
yeah
I
mean
something
else
that
that
would
effectively
undo
it
when
it
was
correct,
whether
that's
coming
from
the
api
that
told
you
they
gave
you
the
recommendation
in
the
first
place
or
or
some
other
command.
That
knows
how
to
how
to
rectify
the
situation.
I
think
we
should
put
a
little
bit
of
thought.
C
To
it
well,
I
think
also
another
thing
that
we
had
discussed
in
the
overrides
conversation
was,
you
know
what
is
the
npm
cly
user
experience
for
managing
your
overrides
and
that's
that's
kind
of
a
whole
other
big,
convoluted
ball
wax
it's
not
a
terrible
json
structure
to
write
by
hand
and
to
read
it's
like
it's
pretty
straightforward,
but
you
may
want
to
be
able
to
have
an
npm
command
that
will
create
an
override
and,
in
that
same
in
whatever,
like
npm
override
command,
we
may
have
a
thing.
C
A
Interesting,
so,
in
terms
of
this
specific
rc,
I
took
the
action
item
down.
Isaac
you're
gonna,
take
another
pass
at
this
just
to
look
at
review
this,
and
then
it
sounds
like
so
in
terms
of
us
implementing
this
in
the
public
registry.
Is
this
again
we
we
said
last
week:
this
may
not
be
something
that
we
want
to
start
supporting
there,
but
private
registries
can
essentially
go
ahead
and
start
to
implement
this.
A
C
A
Whole
product
yeah
this
whole
product
decision
right.
So
that's
and
I
think
that
was
kind
of
like
what
we
alluded
to
was
like
the
space
here
and
the
the
improvement
here
and
change
here.
Like
really
is
a
feature
for
private
registries
to
to
to
to
take
on.
It
sounds
like
there's
interest
that,
which
is
why
we're
considering
this
gar,
I
see
your
hands
up
and
then
rebecca.
I
think
you
also
want
to.
G
E
E
So
it
you
know
this
this:
this
gets
into
the
like.
Okay.
If
the
registry
knows
that
you
should
be
using
this
other
package
instead,
what
you
know
like
we
do
have
this
weird
scenario
where
it's
like.
Well,
if,
if
simvir
compatible,
if
you're,
installing
a
fresh
module,
we'll
we'll
pick
the
most
recent
version
that
matches
your
simver,
so
you
do,
you
know
you'll,
never
have
anything
that
npm
audit
fix
can
do
on
a
fresh,
install
except
now
with
the
overrides.
You
would
if
we
introduced
this
override
thing.
So
what
do
we
do
about?
E
That
is
the
kind
of
the
the
question
raised
by
that
sorry,
so
on
a
fresh
install.
So
if
I,
if
I
freshly,
if
I
go
to
a
directory
and
install
a
module
everything,
there
is
going
to
be
the
most
recent
version
that
npm
can
install
that's
compatible
with
it.
E
So
it
determines
well
here's.
The
thing,
though,
is
it,
determines
what
versions
are
installed,
but
it
can't
tell
you,
go
install
this
other
completely
different
package.
Instead,
this
hotfix
and
that's
what
that's
where
we're
kind
of
going
with
that
is.
It
would
be
really
nice
to
have
a
way
of
having
this,
this
information
at
install
time
so
that
we
never
install
the
bad
version.
C
Actually,
I
mean
we
did
this
for
npm
enterprise
and
it
never
made
it
into
the
public
registry
and
it's
also
a
thing
that
maybe
shouldn't
be
in
the
public
registry.
But
you
you
can
put
those
versions
into
a
sort
of
restricted
versions
holding
pen
within
the
the
pacument.
E
Yeah
we
could
make
them
uninstallable,
but
in
this
case
we've
got
a
patch
that
we
want
to
install
instead
with
the
overrides
with
this
overrides
rfc
overrides.
A
E
C
Right
well
and
there's
also
the
case
where
a
vulnerability
is
introduced
and
npm
audit
fix
will
downgrade
you
be
below
the
like.
That's
the
yeah.
I
guess
that's
the
same
thing.
It's
it's
similar,
yeah
yeah,
I
think
the
bigger
so
the
the
broader
question
there
is,
you
know
we
cut.
We
currently
have
this
process
where
you
build
out
this
whole
ideal
tree,
and
then
we
reify
the
whole
thing,
and
then
we
check
to
make
sure
that
there's
no
vulnerabilities
and
we
say
oops,
there's
a
vulnerability.
C
You
should
probably
fix
that
like
is
there
some
way
to
shorten
that
that
window-
and
you
know,
get
the
information
about
the
ideal
tree
and
then
make
those
changes
to
the
ideal
tree
ahead
of
time
before
we
reif
it's
disk.
E
I
mean
it
seems
like
when,
when
fetching
package
metadata,
one
could
like
one
using
the
api's
today
one
could
go
fetch
the
check
to
see
if
there
are
any
vulnerabilities
on.
I
guess
it's
on
a
perversion
basis,
though
so
that
does
make
it
trickier.
A
B
Then
I'll
be
very
quick.
This
is
a
great
line
of
thinking.
I
think,
there's
a
lot
of
power
in
the
ability
to
modify
the
tree
before
you.
Refi.
I've
said
that
before,
if
there
is
a
way
that
we
can
come
up
with
a
plan
that
will
actually
let
people
make
arbitrary
changes
to
the
tree,
based
on
whatever
suggestion
logic
they
want
to
implement.
That
would
be
excellent
and
would
save
me
a
bunch
of
time,
because
I've
got
something
built
kind
of
like
that.
B
That's
not
finished,
and
I
would
just
abandon
the
project
if
you
all
were
willing
to
do
something
like
that.
It
just
needs
to
be
more
than
apply
overrides
like
you
need
to
be
able
to
run
logic.
Make
api
queries
like
just
you
need
to
be
able
to
run
arbitrary
execution
against
it
in
order
to
solve.
I
think
all
the
problems
that
that
companies
have
implemented
solutions
for
in
this
space,
yeah
like
a
hook,
would
be
great
if
it
like
loaded
up
a
file
ran
the
function
it
exported
and
passed
it.
B
A
Yeah,
so
just
action-
I
am
here
again,
it
seems
like
we're
we're
okay
with
like
landing
this
alongside
the
overrides
rc
moving
on.
I
believe,
with
this
got
kept
on
the
agenda,
although
I
feel,
like
jordan,
made
some
really
good
comments,
feedback
and
essentially
reasons
why
we
should
not
move
forward
with
miles's
initial
proposal
here
and
sort
of
discussion
around
adding
type
to
npm
init.
I
think
we
can
probably
just
remove
the
agenda
label
here
and
probably
try
to
capture.
C
C
Say
yep
or
make
your
own
create
module.
It's
super
easy
yeah
we
or
just
use
npm
and
isaac's.
If
you
want
to
write
code
like
I
do
credit
for
it,.
H
This
this
brings
up
a
point
that
I
I
think
there
was.
I
was
talking
with
someone
from
from
linkedin
about.
Is
there
any
programmatic
way
to
do
like
the
init
like?
Is
there
a
programmatic
way?
I
can
use
the
default
like
whatever
npm
and
it
runs
like.
Can
I
can
I
modify
the
results
of
npm
init
without
having
to
rewrite
all
that
logic,
myself.
C
Depending
on
what
you
mean
by
that
question,
yes,
okay,
but
the
details
vary
wildly.
The
simplest
answer.
Is
it's
json
you
parse
it
and
change
it
and
write
it
back.
It's
fine,
the
the
more
the
more
involved
questions
like
if,
if
what
you're
saying
is
like,
if
I
run
npm
init
foo,
can
you
can
you
modify
how
the
foo
package
works,
like
yeah,
use
a
different
package
or
just
run
npx
foo
yourself.
H
I
guess
more
specifically
like
I
would
love
to
be
able
to
hook
into
whatever,
like
either
the
interactive
logic
or
just
the
dash
y
logic
and
well
not
dashboard
dashboard
doesn't
make
sense,
but
like
be
able
to
hook
like
an
additional
question
into
npm
in
it
like
the
interactive
right
so
like,
then
I
don't
have
to
rewrite
all
that,
and
it's
like
close
enough
to
what
npm
already
provides
there.
C
Is
a
there
is
a
very,
very,
very
strange,
api
surface
that
you
can
use,
I'm
I'm
pretty
sure.
Almost
nobody
uses
it.
We
haven't
ripped
it
out
because
we
haven't
gotten
around
to
it
yet,
but
you
can
specify
an
init
module
which
uses
this
thing.
I
wrote
in
2010
called
promzard
and
yeah
you
can
you
can?
If
you
look
at
the
default,
init
module,
that's
being
used,
you
can
see
the
syntax
for
for
creating
those
scripts.
It's
it's
very
bizarre
and
it
predates
almost
everything
in
node
today.
So.
H
H
You
know
create
whatever,
because
like
then
theoretically,
npm
in
it
create
the
sm,
despite
it
already
being
published,
would
be
like
requiring
a
thing
putting
in
like
three
lines
of
code
and
then
then
you
have
type
type
module
which
I
I
have
wanted
in
many
cases,
but
also
like
larger
companies
want
it
for
their
internal
usage
of
their
own
modules,
to
you
know,
create
stuff
or
like
automatically
default
to
things
without
having
to
do
a
bunch
of
rewriting
the
you
know,
rewriting
the
whole
thing.
Every
time.
A
Yeah,
so
I
just
linked
a
couple
things
in
chat
and
what's
also
noted
like
this
is
a
lot
of
what
you're
speaking
to
tune
is,
is
what
we're
trying
to
do
in
the
package
maintenance
working
group.
A
We
kicked
off
the
create
pkg
project,
which
should
have
both
programmatic
apis
that
you
can
consume
and
utilize
as
well
as
give
you
the
ability
to
sort
of
scaffold
and
template
based
on
what
your
patterns
are
for
your
ecosystem
for
your
community
for
your
organization,
that's
the
whole
idea
behind
it
and,
like
potentially,
the
hope
in
the
future
might
be
that
we
would
actually
consume
it
for
in
it.
A
If
it
makes
sense
if
it
was
easy,
but
yeah
we're
trying
to
like
essentially
push
that
conversation
over
there
and
get
folks
working
on
that.
So
it.
B
H
Oh,
I
mean
literally,
the
example
is
that
like
create
a
weight,
create
package
and
there's
a
comment,
that's
to
do.
That
was
more
of.
B
A
So,
with
about
10
minutes
left
I'm
going
to
try
to
plow
through
a
bunch
of
these
in
terms
of
the
npm
workspaces,
auto,
switching
context
based
on
the
current
working
directory.
I
forget
where
we
landed
with
this
conversation,
but
it
feels
a
little
bit
bigger
than
well.
That
may
be
the
10
minutes.
F
C
A
Yeah,
okay,
great
so
feel
free
async,
to
give
comments-
and
I
look
it
looks
like
wes-
was
commenting
on
this
even
today,
so
that's
great
so
moving
forward
and
skipping
that
then
rce
339
approving
command
suggestions,
no,
I
know,
hasn't
been
able
to
jump
on
these
calls
the
last
little.
While
this
is
pretty
straightforward,
though
I'm
not
sure
yeah.
I
I
think
we've
essentially
done
this.
This
work
is
essentially
improving
the
output
we've.
A
I
know
car
has
already
done
a
bunch
of
this
work
and
cleaning
up
the
defaults.
What
you'll
notice
in
in
more
recent
versions
of
of
npm,
if
you're
keeping
up
to
date,
is
that
that
output
is
now
a
lot
more
cleaned
up
and
our
suggested
or
did
you
mean
output
is
a
lot,
hopefully
a
lot
more
helpful
and
actionable.
So
I
don't
know
if
we
like,
I
don't
know
if
we
just
land
this
as
is
or
it
doesn't
need
to
modify
it,
be
modified
to
match
reality.
Gary.
G
Because
we've
been
iterating
on
it,
a
little
just
to
make
things
a
little
more
clear
or
to
add
comments
about
you
know:
npm
exec
runs
an
external
thing
versus
run,
runs
an
internal
thing
kind
of
a
thing,
just
moving
things
in
a
direction
to
reduce
the
ambiguity
between
exec
and
run
and
nothing.
A
A
The
second
rc
that
nilford
created
is
the
where
config
so
so
nicely
named,
that
jordan
loves
it.
The
essentially
improving
the
experience
of
npm
config
to
to
give
you
more
control
over
where
essentially,
you
are,
or
meaning
meaning
to
get
and
set
config
values,
and
so
the
hope
here
is
that
we
can
introduce
some
config.
It
doesn't
have
to
be
the
name
where
that
allows
you
to
specify
the
location,
including
the
ability
for
us
to
define
like
at
the
project
level
and
hope
is
in
a
future
major
release.
A
We
could
change
that
default
so
that
the
expectation
of
the
user
is
that
npm
config
set
would
actually
interface
with
your
local
npm
rc
file
in
your
project,
which
I
think
is
a
bit
confusing
for
some
folks,
because
at
least
from
the
feedback
I've
gotten
and
having
that
ability
to
to
to
set
that
at
the
project
level,
I
think,
is
pretty
pretty
nice.
So.
C
C
And
I
think
well,
I
think,
first
of
all
like
having
npm
config,
set,
take
global
to
define
to
write
to
your
global,
config
or
otherwise
write
your
local
config
like
it's
not
great.
It
leaves
basically
no
way
to
specify
a
project.
It's
it's
classic
case
of
like
a
boolean,
where
really
what
we
wanted
was
a
a
string,
we're
in
a
num
and
the
the
need
to
be
able
to
do
that,
for
exact.
Also,
is,
is
pressing
and
has
a
lot
of
you
know
is
also
similar.
C
The
only
the
only
thing
that
gets
a
little
gets,
my
eyebrows,
a
little
wrinkly
is,
where
equals
user
kind
of
doesn't
mean
anything
for
exact,
but
it
does
mean
something
for
config
right,
and
so
it's
I
I
wonder.
If
it
do
we
just
throw
if,
where
is
set
to
user,
when
you're
running
exactly
that
could
be
fine.
C
A
A
Where
should
probably
not
be
used
like
it's
just
too
yeah,
it's
too
too
much
of
an
umbrella
term,
so
location
or
something
like
that
like
like
yeah,
okay,
moving
on
then
with
a
few
minutes
left.
I
want
to
keep
this
on
our
radar.
The
npm
audit
licenses
rc
tierney
182..
H
Think
there's
any
update
yeah.
I
I
my
understanding
is
I'm
waiting
on
just
advice
on
where
to
go
from
here.
I
might
have
missed
something,
but
I
don't
think
I
have
yeah
just
waiting
on
like
you
know
what
what
y'all
would
want
me
to
do
and
I'm
happy
to
take
that
async.
A
H
I
mean
I
I
built
my
own
thing.
It
was
on
arborist,
it
wasn't
really
proof
of
concept
like
it
works
or
worked.
It
was
also
using
arborist
before
the
mpm7
rewrite,
so
our
risk
changed
a
lot
and
it
broke,
and
I
just
haven't
gotten
around
to
fixing
it.
So
you
know
it
kind
of
works
but
yeah
it
doesn't
work
with
like
the
new
arborist.
I
think
it.
I
think
it
does
still
technically
work
with
the
old
arborist,
like
the
pre
new,
like
in-between
arborist.
H
Yeah,
so
you
know
I
I
I
built
my
own
thing:
it
doesn't
implement
this
api
at
all.
So,
like
I
basically
built
a
thing
that
I
wanted,
I
think
licensee
is
probably
a
better
example
of
something
that
people
use,
including
npm.
That
is
like
doing
the
policies
thing
rather
than
just
reporting
but
yeah.
You
know
I
I'd
love
to
see
this
move
forward
in
some
way
and
I'm
happy
to
do
the
work.
I
just
you
know
want
the
direction
of
of
y'all
to
know
which
direction
will
be
accepted.
Basically,.
C
H
That's
fair:
I
think
that
big.
C
A
Yeah,
no,
no,
it's
totally
fine.
We
have
a
couple
that
we
weren't
able
to
get
to
that.
Hopefully
we
can
next
week
and
we'll
push
things
through
between
now
and
then
feel
free
to
keep
giving
feedback
and
opening
up
rc's
guard.
Did
you
have
one
comment
you
want
to
make
before
we.
G
A
That
should
be
a
thing:
ls
can
do
right.
There's
yeah,
there's
been
some
discussion
in
the
past
about
ls,
outdated,
update,
outdated
and
some
other
commands
that
all
should
are
essentially
filters
of
the
same
information,
and
that
really
it
would
be
great
if
the
ux
ui,
like
of
that
those
outputs
were
essentially
just
yeah,
filtered
versions
of
of
that
same
kind
of
information
and.
H
A
H
Right,
it's
validate
and
like
filter
and
like
basically
let
me
act
on
the
licenses
that
are
in
my
dependency
tree.
C
So
part
of
the,
where
that
might
get
really
interesting,
is
actually
hooking
into
the
build
ideal
tree
and
refi
process.
So
if
you,
if
you
tried
to
install
something,
we
could
say
like
hey,
there's
a
there's
a
bad
license
in
here,
you
shouldn't
be
using
it
and
either
crash
the
install
and
or
print
a
warning
or
do
whatever
yep
exactly.
D
D
These
are
the
licenses
we
very
much
don't
want,
and
then
there
were
a
bunch
of
old
packages
in
our
tree
that
didn't
have
spedix
identifiers
in
the
package.json,
and
but
I
could
I
did
the
manual
research
to
figure
out
exactly
which
was
which
and
then
then
eventually
was
able
to
put
that
in
a
shared
public
corrections
package,
so
that
I
you
know
that
work
didn't
have
to
be
repeated
by
other
people
and
so,
like
all
of
those
things,
are
very
critical.
I
think,
regardless
of
what
implementation.
A
Yeah,
so
apologize
we're
a
few
minutes
over.
I
know,
let's
start
late.
Thank
you,
everyone
for
jumping
on
again,
and
hopefully
we'll
see
you
next
week
at
the
same
time,
same
place
and
yeah
keep
giving
us
feedback
in
the
earth
season
themselves
and
yeah.
Thank
you.