►
From YouTube: Open RFC Meeting - Wednesday, July 20th 2022
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
on
youtube.
Welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
july
20th,
2022.
we'll
be
following
along
in
the
agenda
that
was
posted
in
the
mpmrc's
repo
issue
614
and
it's
a
small
agenda
today.
Just
a
quick
reminder
for
folks.
This
fall
and
all
cons
on
the
rfc's
repos
are
covered
on
the
code
of
conduct.
A
We
ask
you
to
please
be
kind
as
you're
speaking
and
if
others
are,
please
raise
your
hand
and
we'll
call
on
you
and
I'll
just
copy
and
paste.
The
meeting
notes
here
for
folks
feel
free
to
add
yourselves
to
the
agenda
or
to
the
attendees
list.
Sorry
in
the
hack
and
detox
there
that
I
just
shared
and
does
anybody
before
we
get
started?
Does
anybody
have
any
announcements
they
want
to
share,
go
edgar.
B
He
submitted
three
pull
requests
and
implemented,
something
that
was
very
nice,
treating
certain
thoughts
in
a
nerf
darted
way
without
breaking
anyone
who
exists
has
been
existing
made,
some
very
fine
decisions
along
the
way,
and
it
was
a
pleasure
reviewing
those
pr.
So
just
thank
you.
A
Awesome
yeah
thanks
john
quickly,
just
a
note
on
your
rc.
I
put
it
into
a
section
that
just
said
to
ratify.
Essentially
I
know
we
spoke
about
that
last
week.
I
don't
think
there's
any
necessarily
anything
crazy.
We
would
want
to
change
about
the
rfc
itself,
so
it
just
needs
to
be
pulled
into
the
actual
rebound
accepted
and
then
moved
into
implemented
so
quickly
moving
into
the
agenda.
Unless
folks
were
there
any
other
announcements
from
folks.
A
If
not,
the
first
item
was
the
proposed
backwards.
Compatible
improvements
to
compression
evan
said
he
wasn't
able
to
was
going
to
be
able
to
make
today's
call
again,
unfortunately,
so
unless
other
folks
had
any
talking
points
for
that,
I
think
we
can
just
skip
over
that
for
today.
A
D
Sure,
thanks
in
fact
I
was
able
to
play
around
with
it
a
little
bit,
so
I
was
able
to
do
the
npm
linking
from
roy's
feature
branch
locally
on
my
machine,
and
then
I
created
a
github
repro
repo,
just
with
like
a
babble
from
the
registry
and
eslint
from
the
github
and
was
able
to
run
a
quick
test
using
some
of
the
examples
that
you
had
that
were
in
the
query
docs.
So
I
could
paste
it
in
here.
Just
I
just
wanted
to
make
sure
I
was
like
getting
it.
D
D
The
only
guess,
follow-up
question
that
I
have
is:
is
there
a
way
to
query
like
the
negative
like,
as
you
know,
git
or
bucket,
or
anything
like
that?
So
basically,
like
is
there
a
way
to
query
like
implicitly,
I
suppose
versus
like
testing
the
negative
of
everything
we
don't
want.
A
B
Yes,
I've
been
actually
playing
with
query
myself
there.
The
not
operator
is,
I
think,
what
you
need
and
yeah,
because
I've
been
trying
to
query
sorry.
I
just
drew
a
blanket
like
two
things
in
my
head:
yeah
right
now,
I'm
trying
to
query
for
things
that
require
a
package
that
then
themselves
don't
have
a
certain
depth
dependency
and
so
yeah,
the
not
operator.
B
I
can
show
you
my
query,
which
won't
work
in
the
branch
right
now,
because
that
was
a
plugin
for
it,
but
that
query
right
there
will
show
you
anything
that
requires
knocked.
It
doesn't
have
this
dependency
and
representatives
right.
So
you
can
it's
totally
the
not
the
not
operator
is
what
you
want.
Okay,.
B
Yeah
you
could
do
a
you,
could
just
do
a
a
non.
This
doesn't,
I
think,
not
stem
bar.
I'd
have
to
go
look,
but
then
there
is
a
thing.
So
I
believe
you
should
be
able
to
do
anything
that,
like
anything
in
it,
that
has
a
dependency,
does
not
send
there.
I
think
you
should
be
a
link.
I'd
have
to
dig
into
that,
but
that
should
be
positive.
Cool.
D
B
By
hand
is
related
to
this
and
the
next
one
I
just
want
to
throw
the
idea
out
there.
We
need
a
flag
on
npm
query
that
says
if
you
have
results
exit
uncleanly,
if
you
don't
have
results
like
that
uncleanly
and
with
those
two
flags
things
like
this,
could
easily
be
a
limiting
rule
or
for
your
post
rule
this
and
the
next
one
we're
going
to
discuss.
D
Cool,
yes,
I
guess
just
familiarizing
myself.
Excuse
me
more
with
like
the
vocabulary,
I
guess
or
like
the
keywords
but
yeah.
So
basically
it
sounds
like
if
I
just
dive
a
little
bit
more
into
the
selector
syntax.
I
should
be
able
to
find
like
not
december
or
something
like
that
through
what's
available.
B
I
think
so
I'm
about
to
wrap
up
a
little
project,
I'm
on
now
and
I'll
I'll.
Look
at
this.
D
A
Yeah,
what
I
think
you're
looking
for
is
type
owen
and
specifically
the
type
pseudo
selector.
It
pulls
the
information
from
npm
package
arc,
so
you
don't
have
to
do
what
you're
doing
with
the
resolved
at
all.
A
Even
you
can
do
a
type
selector,
so
the
type
then
will
give
you
the
options
to
use
the
same
categories
we
use
internally,
which
is
get
get
tagged,
version
range
file,
directory,
remote
and
alias,
and
so
you
can
use
that
to
essentially
figure
out
what
type
of
depth
it
is,
whether
it's
github
or
not,
so
you
don't
have
to
use
the
resolved
like
resolved,
is
a
you
know
like
the
attribute
selector
you're
using
it.
A
It's
definitely
it's
a
catch-all
for
like
any
metadata
we
may
not
know
about,
but
there
are
some
privileged
pseudo-selectors
like
type
that
that
we
do
know,
and
we
do
a
little
bit
when
you
kept
saying
somewhere,
I
was
trying
to
figure
out
what
you
meant
by
sunburn,
because
there's
a
sember
selector
as
well.
That
allows
you
to
do
your
center
ranges,
which
is
really
nice,
which
again
these
are
nuanced.
You
know
selectors
that
are
only
specific
to
you,
like
obviously
our
implementation,
they
aren't
expecting
the
css
spec
anywhere
or
anything
like
that.
Okay,.
D
All
right
cool
yeah
cause.
I
think
that
level
of
hinting
is
what
I'm
looking
for.
Obviously
I
want
to
have
that
or
I
think
the
most
predictable
way
would
be.
You
know
having
like
that.
So
it
sounds
like
there's
something.
That's,
so
I'm
not
sure
if
this
is
just
well.
I
guess,
if
you
is
there
somewhere
to
look
for
kind
of
the
under
the
hood
details,
because
it
sounds
like
that's
gonna
be
the
okay.
A
Cool,
so
the
rfc
has
a
bunch
of
that
and
I
think
our
yeah
there's
a
bunch
of
docs,
a
doc
that
is
going
to
come
out
with
npm
query.
Even.
C
A
D
Oh
yeah,
this
type,
I
think,
is
exactly
what
I'm
I
think
would
would
get
this
the
cleanest.
I
think
so.
Yeah
type
tag
or
something
okay.
No,
this
is
good
yeah.
I
think
this
is
what
I
was
looking
for.
A
Cool
and
you
can
change
them
together
right,
so
you
could
say
this
or
this
or
this
comma
type,
and
actually
what's
really
nice
is
what
the
css
selector
for
sudo
is.
I
believe
it
is.
I
think
it's
is.
You
can
do
a
combinator,
so
it
could
be
like
this
type.
This
type,
this
type
in
commas,
within
a
nice
thing,
you
don't
have
to
do
the
entire
selector.
You
can
just
do
at
that
specific
that
specific,
like
scope,
you
can
say
just
of
the
different
types.
A
It
could
be
any
one
of
these
different
types,
so
you
don't
have
to
expand
out,
which
is
what
gets
css.
I
think
a
little
bit
verbose
in
in
normal
when
you're
writing
it
normally
is.
You
would
have
to
usually
have
expanded
them
with
selectors
the
selector
v4
spec,
I
think
they
introduced,
I
think,
is,
and
that
is
helps.
You
include
like
multiple
sets
like
that.
So.
D
Yeah
looks
like
basically,
I
just
want
tag
version
range,
maybe
I
guess
maybe
alias.
D
A
You
mean
file
yeah,
so
in
npm
package
arg
like
we
consider
a
local
file
to
be
like
file,
so
that's
the
type
that
will
come
back,
so
you
could
do
like
carl
was
saying
you
can
say
not
file
and
not
or
sorry,
not
type
file
and
not
type,
let's
say
git
right
or
for
whatever
reason
like
if
you
want.
But
that's
that's.
Why
we're
saying
like
with
this
now
available
to
you
it
kind
of
changes,
how
you
look
at
like
the
the.
D
Because
someone
could
provide
their
own
types
and
those
could
override
like
the
default
ones
right.
If
someone
wanted
to
say
well,
I
want
the
default
you
have
but
allow
a
remote
not
get
but
a
remote.
You
know
someone
could
take
sure.
D
Yeah,
I
guess
the
the
question
the
last.
The
the
question
more
regarding
file
and
directory,
though,
was
if
those
should
be
treated
with
the
same
permissiveness
as
a
tag
jordan
raised
that
point
of
like
well,
if
it's
a
local
file-
or
I
see
a
directory
here
like
that's
me
saying
you
know,
this
is
on
my
system,
making
it
like
an
exception
versus
like
only
assembler
tag
or
range,
like
literally
stopping
the
you
know,
closing
the
door
past
that
you
know
so.
D
B
Ahead,
I
think
that
question
isn't
exactly
why
we
do
not
want
to
codify
this
into
a
separate
command,
but
maybe
don't
fetch
how
to
use
npm
query
to
solve
this
problem,
because
this
and
the
next
we're
going
to
talk
about,
I
really
don't
think
need
to
be
baked
in
the
npm.
They
can
just
be
here's
the
query.
You
want
to
use
to
solve
this
problem
and
if
we
add
those
flags,
npm
query,
it's
a
single
link.
You
put
in
your
dependency
script,
which
we
just
added
and
then
you're
done
and
then
at
self-serve.
A
Essentially,
I
think
would
be
helpful
that
you
have
these
types
of
dependencies
that
we
are
are
known
known
to
be
problematic,
potentially
right,
and
if
you
want
to
ignore
that
warning,
that's
fine
or
if
you
want
to
ignore
that
audit,
like
that's
fine,
but
I
think
that's
why
how
this
particular
like
work
and
owen's
working
this
has
sprung
up
is
because
I
think
we
all
know
that
like
remote
depths
are
dangerous
and
so
like,
I
think,
to
speak
to
what
your
question
is
owned,
specifically
as
well
like
file
file
and
directory
types
of
packages
and
dependencies,
I
think,
are
okay,
like
you,
I
think
that's
what
jordan
was
trying
to
speak
to
that
like.
A
I
think
those
are
totally
fine.
It's
the
ones
that
we
outline
here
that
are
the
problematic,
are
the
remote
and
the
get
dependencies
right.
So
those
two
are
the
ones
that
we're
concerned
about.
There
should
be
the
ones
that
people
are
concerned
about
when
they
see
those
in
your
tree.
You
should
you
know
they
likely
have
then
just
increased
the
scope
of
the
number
of
hosts
that
you're
relying
on
for
your
packages
right
so
you've
gone
from
I'm
configured
to
this
one
registry.
But
then
a
package
here
told
me
to
go
fetch.
A
You
know
something
from
github
or
from
a
different
get
repository
or
it
told
you
to
go,
get
something
from
somebody's
personal
domain.
You
don't
know
like
we
need
to
do
a
better
job
at
like
surfacing
that
I
think
that
that's
right,
so
I
would
say
the
grouping
should
be
get
and,
and
remote
are
the
two
types
that
we
should
be
looking
for
and
warning
on.
A
When
we
see
those
everything
else
should
be,
I
think
fine,
because
it
either
deals
with
something:
that's
local,
so
file
or
directory,
or
it's
dealing
with
something
that's
specific
to
the
the
registry
implementation,
so
tags
versions,
ranges
and
then
aliases
are
all
will
only
map
to
the
specifically
reconfigured
registry,
so
yeah.
D
Yeah,
okay,
yeah
cause-
I
I
mean
I
get
because
I,
if
jordan
was
here,
I
know
he'd,
say
to
gar's
point
which
yeah
I'm
not
disputing
per
se,
but
I
know
jordan
said
that
like
yeah,
he
didn't
he
was
worried
that
query
could
be
used
as
a
way
to
push
more
things
into
user
land.
But
I
think
just
to
echo
darcy's
point
was
that
my
understanding
was
that
the
prevailing
need
for
something
like
this
far.
You
know
far
outweighs
the
potential.
D
I
guess
maintenance
cost
of
you
know,
making
it
an
opinion
of
the
npm
cli.
Just
because
of
the
nature
of
you
know
the
surface
vector
of
dependency.
So
again,
because
I
think
I
can
also
see
from
gar's
point.
Like
you
add
a
third
one,
is
someone
gonna
remember
to
either
add
it
or
remove
it
from
the
list
in
like
npm,
10
or
11?
You
know
now
you
kind
of
forgot
that
oh
whoops,
we
forgot
to
update
this
and
everybody's
been
exploited
by
you
know
dropbox
urls,
or
something
like
that.
D
You
know
what
I
mean
so
anyway.
Just
I
can
see
both
sides,
but
I
think
my
opinion,
for
whatever
it's
worth,
I
see
more
value
than
less
in,
at
the
very
least,
the
warnings
and
being
able
to
fail
on
them.
At
the
very
least,
you
know
so
anyway,.
A
B
Yeah,
I
I
agree,
I
just
that's
just
a
point.
I
want
to
bring
up
and
I'll
I'll
continue
to
you
know,
and
it's
not
that
I'm
hardline
I
just
want
to
be
mindful
of
it.
I
was
like
this
is
fine
and-
and
I
I
think
the
forgetting
to
change
problem
is
a
wash
either
way
either
we
forget,
or
they
forget
someone
especially
so
I
don't
think
it
matters
for
that.
B
Yeah,
it's
fine
to
do
and
I
would
say
it's
just
non-git
steps
at
this
point
right:
yeah,
yeah,
but.
D
Yeah
cool
yeah,
the
I
have
one
other
thought,
but
it
escaped
me
so,
okay,
I
guess
that's
it.
A
Cool,
I
know
at
least
I'm
not
sure
did
you
add
in
a
flag
to
query
for
that
whole.
A
So
there
was
a
discussion.
I
think
that
gar
and
I
had
offline
about
adding,
essentially
a
a
like
error
if
empty
or
air,
if,
like
some
sort
of
flag,
that
was
named
something
along
that
those
lines
to
essentially
change
the
status
code
of
npm
query.
A
If
there's
no
results
like
empty,
like
error,
if
no
results,
essentially,
which
would
really
make
npm
query
turn
into
like
that,
like
a
really
good
audit
tool
right
so
if
like,
if,
instead
of
never
failing
instead
of
never
erroring,
which
is
what
the
default
mode
is
for,
npm
query:
if
you
provide
this
flag,
then
it
would
essentially
air
if
it
found
no
results,
then
you
know
that
could
be
flipped
to
also
be
like
error.
A
If
you
found
results
right,
so
we
could
have
two
potential
flags
that
you
could
configure
or
pass
them
in
query
to
that
be
used
essentially
as
this
like
auditing
tool
and
could
be
the
underpinning
for
a
lot
of
folks
on
audits.
A
So
that
was
something
we
discussed
internally
and,
as
garza
said
like
in
fast
follow
once
we,
you
know,
release
this
initial
version,
but
just
want
to
speak
to
that,
so
that
you
know
that
you
know
that
might
also
be
an
opt
something
easy
to
do
at
the
command
line.
It
won't
help
necessarily
with
the
programmatic
usage.
You
have
to
fail
yourself,
like
just
just
check
the
length
of
the
array
and
fail,
but
yeah,
I'm
not
sure.
If
there's
anything
missing
on
that
car.
A
Cool
any
other
questions
you
had,
though
owen
or
do
you
feel
like
like,
I
think
the
what
you
were
looking
for
is
the
like
yeah,
not
type
get
so.
D
Yeah,
I
guess
I'm
not
sure
if
it's
too
early,
but
would
you
yeah,
so
you
would
prefer
the
the
asserting
and
the
negative
as
opposed
to
serving
in
the
affirmative,
so
not
get
remote
versus
is
version
xyz
yo,
oh.
A
Guess
it
would
be
like
what
you
we
don't
ever
show
you.
I
guess
we
do
at
the
end
of
an
audit.
We
show
you
all
these
packages
are
clean,
but
usually
during
an
audit
we
show
you
like.
Are
there
advisories
right?
So
it's
like
you
are
showing
the
issues
so,
like
you
probably
want
to
find
all
the
you
probably
want
to
find
all
the
get
and
all
the
remote
packages
and
when
you
find
them
that's
the
problem.
Those
are
the
ones
that
you
service
right.
So
so
you
don't
want
the
negative.
A
I
don't
think
because
then
you're
just
querying
for
all
the
good
things.
Really,
you
want
to
be
looking
for
all
the
things
that
we
think
are
problematic
right,
like
so
yeah.
D
Yeah,
I
guess
I
was
a
jerk.
The
opposite
would
be
that
they
would
all
be
explicitly
listed.
So
if
you
looked
at
it
and
like
the
source
be
like
okay,
they
it's
these
five
but
yeah.
I
make
sense
to
go
either
way,
but
yeah,
oh
and
then
the
other
thought
that
I
recalled
was
actually
more
about
query
was,
I
guess
how
to?
Maybe.
D
This
is
a
good
case
study,
for
it
is
how
to
thread
that
needle
and
like
measure
the
impact
of
when
it
should
be
in
user
land
like
no,
you
have
the
tools,
you
know
instrument,
your
own
query,
like
you
know,
byo
flag
or
something
like
that
right,
as
opposed
to
you
know,
because
part
of
it
is
like
it
does
shield
you
from
the
maintenance
of
having
to
implement
every
flag
yourself,
because
now
anybody
could
have
made
this.
D
You
know
not
get
like
audit
for
themselves,
but
npm
has
chosen
to
specifically
add
it,
even
though
they
could
have
just
kept
it
a
flag,
and
I
I
remember
from
the
query
conversation
like
having
that
governance
zone,
as
you
know,
as
predictable
as
possible
like
well,
why
this
one,
and
not
this
one,
you
know
so
anyway,
just
more
food
for
thought,
but
that's
it.
B
Oh
you're
still
here
just
to
point
out
that
these
won't
be
flags.
There's
gonna
be
a
separate
command
for
things
that
use
query
under
the
hood.
This
isn't
going
to
be
part
of
npm
query
itself,
these
baked
in
ones
we
use.
These
are
going
to
be
a
new
set
of
commands
for
doing
these
kinds
of
lending
and
that,
I
think,
will
help
us
mentally
make
this
distinction
between.
Is
this
a
specific
command
you
want
to
make
in
the
opinions
for,
or
should
this
just
be
something
we
suggest
people
use
in
queries?
B
Yes,
right,
yeah
it'll
be
part
of
fpm
audit,
or
maybe
it's
not.
Maybe
audit
becomes
the
sub
command
of
this
new
thing,
because
it's
a
broader
concept,
but
it's
not
going
to
be
part
of
them
being
wary.
The
command
so
that'll
help
us
with
that
mental
divide,
which
I
agree
is
something
we
just
need
to
discuss
every
time.
I
don't
know
that
we
should
be
should
be
right.
Hard
bought
every
time.
A
Right,
I
think
that's
that
last
point
is
the
the
key
one
right
like.
I
think
that
we
are
over
time,
like
just
gonna.
Have
that
conversation
again
and
again
like
what
makes
sense
to
you
essentially
privilege
or
like
bring
into
in
a
more
sophisticated
way
in
an
easier
way
to
essentially
alias
or
to
change
our
defaults.
A
That's
going
to
be
a
conversation
every
single
time
like
we
know,
looking
forward
that
there
are
some
changes
we
want
to
make,
and
this
just
happens
to
be
one
that
aligns
with
like
where
we're
going,
but
there
might
be
something
some
query
that
the
community
starts
to
find
really
helpful,
like
licensing
checks
right
like
or
something
like
that
which,
like
we
has
been
our
radar
but
not
really,
and
now
that
could
be
a
potential
conversational,
it's
just
a
simple
query:
can
we
get
it
privileged
into
the
default
checks
that
are
happening
in
npm?
A
You
know,
and
then
we
have
that
conversation
and
we
decide
whatever.
That
is,
I
think
it's
really
tough
to
like
try
to
set
any
kind
of
thresholds
or
like
any
kind
of
framework.
I
think
it's
just
a
discussion
each
and
every
time
like
if
we
have
the
feeling
that
there's
like
enough
yeah
enough
of
a
push
enough
of
a
drive,
then
there's
enough
value.
There
then
we'll
probably
add
it
yeah
yeah.
A
You
know
these
mpm
scripts
that
are
referencing
npm
query:
to
do
these
checks,
you
know,
maybe
you
should
privilege
the
you
know
that
specific
one
that
we're
seeing
in
userland
so
much
and
that
I
I
think
that's
the
right
way
to
go
like
we
sort
of
let
the
community
sort
of
start
to
to
play
with
things,
and
then
they
tell
us,
oh,
you
should
have
this,
and
that
and
the
defaults
should
change
and
in
terms
of
the
defaults
changing
here
like
we're.
A
A
Yeah
again,
that
is
garcia
even
saying
here
in
chat
like
there
could
be
a
potential
future
where
we
can
write.
Let
you
write
a
whole
bunch
of
your
own.
You
know
queries
that
can
be
aliased
quickly
it.
It
definitely
is
a
tool.
That's
going
to
allow
us
to
build
better,
tooling
and
a
better
framework
around
how
again
we
enable
the
community
better
and
support
the
community
better
in
a
more
holistic
way
right.
So
it
you
know
it's
not
going
to
be
a
catch-all.
A
I
don't
think
it's
going
to
ideally
be
solve
a
lot
of
the
problems,
but
I
don't
know
if
it's
going
to
catch
every
single
problem
and
there's
npm
does
have
like
our
team
does
have
best
practices
that
we
know
of
that.
We
want
to
enforce
and
some
defaults
that
we
want
to
enforce
right.
So,
like
we're,
not
you
know
in
terms
of
production
versus
debt
dependencies
in
terms
of
peer
dependencies.
A
A
Okay,
we
can
jump
on
to
the
next
or
sort
of
last
item
that
we
had
here
with
a
good
healthy
amount
of
time.
Now
to
speak
to
it.
I
know
we
sort
of
had
only
a
few
minutes
last
week.
This
is
the
adding
singleton
packages
rfc
number
23..
I
know
david
zirin
who
jumped
on
here
had
originally
poked
us
about
this,
and
I
think
we
had
a
good
discussion
last
week.
I'm
not
sure
if
there's
any
updates
you
want
to
share.
I
see
you
commented
last
week.
E
Yeah,
I
I
left
a
hack
md
on
on
the
comments
list
and
the
important
part
about
it
is
the
possible
solution
at
the
end,
which
essentially
is
a
rough
proposal
of
expectations.
So
just
to
kind
of
recap,
the
the
discussion
from
last
week,
we
were
talking
about
having
better
control
of
the
app
host
layer
for
defining
which
things
we
want
as
singletons
or
single
install
installs.
E
The
the
general
idea
is
when
we
violate
those
expectations.
There's
some
way
to
clearly
indicate
to
users
that
something
they
didn't
expect
is
happening,
and
that
here
are
the
resolution,
steps
that
they
can
take,
so,
whether
it's
opting
in
to
allowing
the
duplication
so
there's
a
little
bit
of
friction
in
doing
that
they
could
work
around
it
or
we
can
actually
provide
sort
of
a
walkthrough
of
how
to
resolve
it
and
a
lot
of
times.
E
That
means
we
downgrade
something
to
match
a
dependency
or
we
have
to
upgrade
something
or
we
have
to
work
across
repos
to
kind
of.
Let
them
know
you
need
to
support
the
new
version
of
typescript
or
react
or
whatever
it
happens
to
be
so
so
I
I
listed
just
a
general
stab
at
what
would
errors
look
like.
I
think,
that's
interesting
to
consider
whenever
you
hit
these
scenarios,
where
there's
two
copies
of
react
or
two
copies
of
a
thing.
E
How
do
we
communicate
that
and
how
do
we
make
it
so
that
the
developer
can
either
opt
in,
or
here
are
your
options?
You
know
you
have
these
five
versions,
which
one
do
you
want
to
choose
or
which
ones
do
you
want
to
allow
and
then
from
that
information
we
can
then
translate
that
into
steps
on
how
to
resolve
that,
and
it's
not
always
resolvable.
E
Some
things
are,
and
some
things
aren't,
but
that
that's
really
what
we're
looking
at-
and
I
don't
have
any
updates
on
this-
is
now
built,
but
I
wanted
to
jot
down
the
sort
of
expectation
and
the
the
the
problems
that
we
have
around
the
peer
dependencies
because
they're
they're
intending
to
solve
this
exact
problem,
where
we
don't
introduce
dupes,
it's
just
that
we
have
they're
at
the
wrong
layer
like
we
want
this.
E
We
do
want
to
not
have
dupes
it's
really
at
the
app
host
layer
that
we
know
best
and
then
there
are
cases
and
they
are
minor,
but
they
are
edge
cases
where
coming
back
to
the
original
rfc,
it
was
like
singleton
scenarios
where
I
have
a
library
that
has
react
context.
E
One
of
the
things
that
we're
doing
in
in-house
right
now
is
separating
all
the
react
contacts
into
one
package
that
never
major
releases
it.
It's
always
a
1.0.
Everything
else
can
major
release
all
they
want
and
we
can
adapt
to
that.
We
can
have
duplicates.
We
can
have
the
react
button
in
its
own
package
and
you
have
three
different
versions
of
it,
but
they
all
use
the
same
context
package
so
that
works
and
that's
okay.
E
So
in
that
case
we
would
say
we
marked
the
context
packages.
This
is
a
singleton,
but
we
would
allow
duplication
for
all
the
other
ones
and
then,
of
course,
at
the
app
host
layer.
You
have
full
control,
so
you
can
say.
Actually
I
know
that
these
two
scenarios
have
different
singleton
versions,
but
they're
sandboxed
and
they're
separate
and
that's
totally
cool.
E
A
Go
ahead,
gar
see
you
handsome.
B
Just
that
this
is
a
big
chunk
of
change
and
the
only
way
it's
gonna
work
is
if
we
figure
out
a
way
to
do
it.
Interestingly,
and
I
think
the
first
step
is
being
able
to
have
a
way
of
the
app
layer
of
saying
this
is
a
rule
I
have
so
regardless
of
how
what
the
error
messages
look
like
or
the
results,
and
I
really
I've
been
playing
around
with
empty
inquiry
on
a
lot
of
stuff
this
week
and
I
think
with
those
flags
is
the
solution,
because
you
can
run
I've
got
a
chat
here.
B
Mtm,
query
or
anything
named
reacts,
that's
not
right
there
right
and
if
I
get
results
blow
up,
that's
I
think
that's
a
good
first
step.
I
don't
think
you
know
this
doesn't
address.
You
know
teaching
them
how
to
resolve,
but
we
can
get
to
that,
and
so
that
would
be
my
only
input.
I
want
to
think
about
this
iteratively
and
I
think
the
next
step
is
to
have
a
concept
of
hoisted
in
npm
query,
because
the
use
the
path
globbing
doesn't
play
very
nicely
with
scoped
launch.
B
I
need
to
know
what
isn't
hoisted
make
sure
it's
under
kind
of
a
thing.
So
those
are
my
only
two
updates
our
input,
for
that
is,
I,
I
don't
see
anything
actually
wrong
in
the
rc,
just
that
that
the
end
there's
a
big
distance
between
here
and
there-
and
I
want
to-
I
want
to
know
what
we
do
next
and
I
really
think
mbm
query
is
what
we
do
next.
A
One
one
quick
question:
actually
for
you
guys
based
on
that
what
you
just
said
did
we
do
we
does
path
now,
except
globs?
Did
we
fix
that
or.
B
It
always
has
okay.
C
B
I
think
it's
hoisted
as
a
special
thing.
That
means
it's
no
natural
slash,
my
name
which
may
or
may
not
have
a
slash
and
because
of
that
flash
the
glove
approach
isn't
something
we
can
use
generically
to
find.
If
something
is
hoisted
or
not,
so
we're
going
to
need
that
keyword
just
because
of
the
scoped
modules.
Okay,.
A
Okay,
good
to
know
yeah,
I
I
I'll
I
I
have
to
apologize
david.
I
I
don't
have
to
read
through
your
whole
hack,
md
doc,
it's
a
good,
very
good
write-up,
but
I
do
see
that
you
have
to
find
like
essentially
like
a
mocked
up
sort
of
dependency
policies
that
looks
similar
to
exactly.
I
think
what
car
is
speaking
to
right
in
terms
of
using
query,
maybe
to
do
the
matching
you
have
this
like
concept
of
matching
on
name
and
even
matching.
A
A
That's
very
interesting.
This
is
essentially
along
the
lines
of
what
we've
been
talking
about
with
audit,
like
improvements
to
audit
to
and
exactly
what
we're
talking
about
just
before
with
owen,
in
terms
of
allowing
folks
to
define,
maybe
a
whole
bunch
of
tests
that
they
want
to
run
a
whole
bunch
of
audits
themselves.
And-
and
maybe
you
know,
these
two
things
collide
or
become
the
same
thing
like
audits
and
policies,
become
the
same
same
concept
or
use
the
same
mechanism
for
defining
a
query
that
that
is
going
to
pass
and
fail.
A
They
become
like
these
almost
like
specialized
scripts.
You
know
that
are
defined
in
your
packet,
your
applications
package
json
and
to
find
those
policies
and
they'll
fail
or
pass
the
what
you
were
speaking
though
too
about,
and
I
apologize
if
you've
written
more
about
it
in
here,
but
the
interactive
installation,
almost
like
the
guide
for
making
those
decisions,
sounded.
A
If
I
remember
correctly,
roughly
like
three
years
ago,
two
and
a
half
years
ago,
when
we
started
down
the
path
of
respecting
peer
deps,
when
we
were
doing
the
work
there,
we
did
consider
what
it
would
look
like
when
we
were
going
to
error
so
that
you
resolve
errors
that
are
are
now
famous
infamous.
A
I
guess
you
should
say
we
were
trying
to
avoid
the
those
situations
as
much
as
possible,
which
is
why
we
came
up
with
old
flags
like
legacy
peer
dubs,
to
kind
of
ignore
them
temporarily
those
issues,
but
we
were
also
considering
like
okay.
What
would
it
mean
for
you
to
step
into
different
modes,
or
was
there
different
modes
that
we
could
essentially
operate
under
to
try
to
resolve
these
conflicts?
A
These
imperial
defense
of
your
conflicts
and-
and
we
essentially
have
three
different
modes
inside
of
arborist-
that
it
falls
into
and
whether
or
not
you're
using
the
force
flag
will
opt
you
into
a
different
mode
of
essentially
trying
to
resolve
those
dependencies.
But
it's
not
on
a
case-by-case
basis.
It's
not
interactive
either
right,
it's
just
via
flags
that
you
would
opt
into
one
of
those
modes
of
making
those
decisions.
I
thought
what
was
interesting
about
what
you
were
saying
was
just.
Can
I
get
walk
through
and
what
I've
seen
in
the
ecosystem?
A
Also
with
like
update,
tooling
package
update
tooling,
is
the
interactive
modes,
and
we've
talked
about
this
for
a
long
time
how
we
could
improve
our
our
update.
You
know
user
experience
to
allow
for
interactivity,
so
you
can
choose
which
versions
that
were
out
of
date,
which
ones
you'd
like
to
update
in
an
interactive
mode.
It
sounds
like
what
we
are
also
missing
is
like
an
installation,
interactive
installation.
A
Once
we
hit
that
those
error,
you
know
those
errors,
instead
of
just
spitting
out,
depending
on
what
kind
of
mode
you're
on
instead
of
just
spitting
out
an
error,
we
could
potentially
allow
you
to
sort
of
make
some
decisions
at
that
point
and
then
maybe
generate
an
override
mapping
for
you
or
somehow,
like
you
know,
help
you
get
to
a
a
place
that
you,
you
know
are
not
receiving
any
errors.
A
Post
install
essentially
and
you've
made
all
the
decisions
along
the
way,
which
is
what
I
think,
what
you're
saying
and
I
I
think
that's
that
should
go
hand
in
hand
with
probably
the
interactive
updates
as
well
work
that
we
would
do.
But
that
sounds
very
interesting,
like
I
think.
That's
that's.
E
That
sounds
good,
I
think
on
our
side.
Well,
if,
if
there's
someone
I
mean,
if
you
have
someone
that
can
look
at
it
on
your
side,
that's
awesome.
E
We
could
work
together
on
it
and
I
think,
on
our
side
we
could
always
do
something
outside
of
the
client
and
run
it
as
opposed
to
install
to
like
trial
it,
because
I
wouldn't
want
to
put
anything
in
this
in
sort
of
standards,
standard
package,
json,
schema
or
anything
if,
if
it
doesn't
work,
because
I
think
there's
some
edge
cases
in
in
that
interactive
mode
that
are
really
hard
to
resolve,
but
we
have
so
much
of
the
the
metadata
like
you
like
the
the
every
we
know,
every
package
has
dependencies
from
the
service
layer,
so
we
should
be
able
to
say
like
here's,
the
viable
remedy
towards
like.
A
We
do
this
for
audit
right,
so,
like
npm
audit
is
able
to
intelligently
either
downgrade
or
upgrade
you
when
you
run
fix
so
like
when
you're
in
that
mode
like
it
will
try
to
again
there's.
A
I
forget,
I'd
have
to
look
into
this,
but
like
there's
essentially
like
three
or
four
different
modes
that
arbors
can
get
into
when
it's
trying
to
build
the
ideal
tree
to
that,
aren't,
as
I
think,
they're
it's
not
very
user-facing,
it's
not
very
user-friendly
to
know
that
you're
being
opted
into
one
of
these
sort
of
modes
or
strategies.
A
I
guess
for
a
reification
with
these
conditions
applied
to
them
right
so
like
in
audit's
case,
when
you
apply
audit
fix,
you
might
get
a
down,
you
might
get
downgraded
a
version
in
some
cases
to
fix
apply.
You
know
to
get
a
non-vulnerable
version
of
that
package,
so
we
have
like
you
said
we
do
have
all
the
information
available
to
us
to
to
try
to
help.
A
You
find
the
version
that
is
going
to
match,
maybe
in
your
summer
range
or
like
you
might
have
to
make
a
decision
about
that
or
you
might
need
to
be
applying
an
override
right.
A
So
this
is
where
I
I
bring
up
overrides
again
is
because
somehow
there's
a
mismatch
within
you
know
your
transitive
dependencies
and
and
maybe
direct
appliances
that
you
you
want
to
resolve
on
behalf
of
like
the
the
people
that
you're
depending
upon
right,
like
they,
they
have
decided
not
to
patch,
for
whatever
reason
their
issues
or
they
they
have
decided
not
to
upgrade
or
change
their
december
ranges
to
be
able
to
pull
in,
like
the
most
up-to-date
version
of
a
transitive
dependency,
you
can
override
that
at
the
project
layer
through
overrides
and
so
being
able
to
have
an
interactive
way
of
generating.
A
I
think
the
overrides
file
is
like
the
key
here.
That's
the
key
missing
piece
here,
because
otherwise
you
have
to
be
very
knowledgeable
to
camp
right.
A
I
think
overrides
and
be
very
you
know,
so
the
interactive
piece
for
sure
like
if
you
were
interested
in
helping
build
something
like
that
some
tooling,
and
then
we
would
probably
love
to
bring
it
back
in
and
especially
if
you
were
finding
ways
to
not
create
net
new
fields
in
packing.json,
but
to
leverage
the
existing
overrides,
let's
say,
spec
and
then
leverage,
maybe
like
at
least
with
ibmquery
leverage
that
syntax
to,
if
you
had
to
introduce
like
a
policies,
top
level
policies,
field
or
top
level
audits
field,
or
something
like
that
be
using
those
as
the
backbone
for
the
the
the
syntax
that
was
being
used
to
do.
E
Is
there
a,
is
there
an
audit
section
actually
in
the
in
the
schema,
not
today.
A
Okay,
there
there's
been
lots
of
conversations
about
what
we
should
do
there.
One
of
the
oldest
rfcs
that
we
have
open
is
actually
about
creating
audit
resolvers,
and
so
I
know,
cb,
who
sometimes
comes
through
not
their
is
his
username
has
written
npm
audit
resolver
and
created
a
separate
schema
for
audits.
A
Specifically
audit,
like
an
audit
schema-
and
you
know,
we've
considered
what
that
would
look
like
if
we
were
put
to
nest
that
impacted
json,
it
might
blow
it
a
bit,
especially
given
that
there's
like
a
lot
of
a
lot
of
vaults
or
advisories,
you
might
want
to
be
ignoring
so
yeah.
We
haven't
essentially
privileged
or
we
don't
respect
any
kind
of
like
audit.
Today,.
A
A
If
not,
we
can
head
off
to
the
last
sort
of
section
that
I
had
here,
which
was
basically
things
to
be
ratified,
so
I'm
not
sure,
john.
If
you
want
to
give
a
quick
update,
I
think
your
work
got
landed.
I
think,
if
that's
right
from.
C
Yeah,
I
think
all
the
pr's
are
now
emerged.
Just
the
last
one
was
during
the
meeting.
Actually
one
quick
question:
is
there
anything
else
we
want
to
look
at
as
far
as
documentation
goes,
I
mean
I
know
like
with
the
main
pr
and
the
cli.
I
added
sort
of
a
note
on
the
existing
key
insert
options
that
kind
of
describe.
You
know
how
the
cert
file
and
key
file
scoped
ones
work.
Is
there
anywhere
else
that
this
should
be
surfaced,
or
is
that
good
enough.
B
Not
on
top
of
my
head
that
I
can
think
of
it's
kind
of
a
niche
thing
right
using
a
certain
boss
and
it's
something
people
are
already
doing.
I
I
we
could
probably
just
look
to
see
if
there's
anywhere
in
our
content,
not
the
command
like
using
npm
or
configuring
npm
stuff,
that's
mentioned,
search
and
see,
if
there's
stuff
to
add
there,
but
other
than
that.
B
No,
I
think
having
it
in
the
config
is
the
nicest
thing,
and
we
did
we
updated
these,
and
I
don't
think
we
want
to
add
that
those
flags
to
any
commands
that
they
show
up
on
their
respective
switches.
C
B
C
Yeah
I'll
get
I'll
get
wes
to
do
it
because
wes
wants
this
so
yeah,
I
think
he's
excited
about
it.
A
Yeah,
what
we
can
say
as
well
is
the
cars
right
like
the
configuring
and
using
sections
of
our
npm
docks,
are
kind
of
like
our
tutorials
or
guidelines,
sections
which
you
can
be
a
bit
more
wordy
if
you
want
to
like
go
into
like
a
example,
usage
or
use
cases,
and
we
have
sections
in
using
npm
just
for
high
higher
level
topics
like
logging
etc
so
like,
if
you
want
to
even
add
a
new
section
there
or
you
can
like,
when
I
say
new
section,
it's
just
a
new
markdown
page
that
could
be
specifically
on
this
topic
of
configuring.
A
Certs
inserts
are
considered
auth,
and
so
they
get
respected.
They'll
respect
your
registry
config
and
won't
pass.
You
know
like
being
a
little
bit
more
verbose
than
you
might
have
been
in
the
api
docs
or
the
config
docs,
just
with
like
yeah
like
what
why
you
might
want
to
use
this,
it
helps
with
seo.
Obviously,
if
we
have
a
secondary
piece
of
information
there.
E
A
Cool
about
five
minutes
left-
and
I
didn't
know
if
any
folks
had
any
other
topics,
they
would
bring
up
or
any
other
items
that
we
didn't
get
to
other
than
just
the
things
that
need
to
be
ratified,
which
I
know
are
on
my
backlog.
A
If
there's
nothing
I'll
I'll,
give
everybody
roughly
five
minutes
back
of
their
their
day
and
we'll
hopefully
see
you
next
week,
cheers
thanks
bye.