►
From YouTube: Open RFC Meeting - Wednesday, July 13th 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,
welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
july
13th,
2022
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue,
613
I'll
copy
and
paste
that
for
folks
and
feel
free
to
add
yourselves
to
the
meeting
and
note
stocks
that
also
shared
in
chat,
a
quick
reminder.
These
calls
and
all
cons
on
the
rfc's
repo
are
covered
under
a
code
of
conduct.
A
We
ask
that
you
please
raise
your
hand
if
other
folks
are
speaking
and
just
in
general,
please
be
mindful
and
thoughtful
of
folks
on
the
call
quickly.
I
want
to
give
the
floor
for
any
folks
that
have
any
announcements
feel
free
to
speak
to
them.
Now.
A
If
not,
I
guess
the
one
announcement
we
have,
I
believe,
guy
you
just
pushed
out
the
latest
version
of
npm.
What
version
is
that
8
14.
awesome?
Thank
you
for,
for
that,
so
feel
free
to
go
grab
the
latest
greatest
version
of
the
cli
we
are
pushing
out
weekly
releases
on
wednesdays,
so
feel
free
to
go
check
out.
The
latest
command,
I
think,
was
audit
signatures
just
landed
in
in
13.
B
There
were
actually
a
lot
of
features,
the
two
that
the
community
will
be
the
most
excited
about.
I
hope
is
the
signature.
Audit
and
my
node
modules
changed
event:
life
cycle
event
than
scripts.
It's
called
dependencies
so
anytime,
your
dependencies
change
after
they're
done
changing
this
event
fires.
B
A
And
quickly,
jumping
into
the
agenda.
The
first
item
that
was
on
here
is
the
pr
5000.
This
is
mpm.
Query
guy.
I
know
you've
picked
this
up
the
workup
here.
I
don't
think,
there's
much
of
an
update
unless
you
have
something
you
want
to
share.
B
From
the
last
week
trump,
I
would
like
to
at
least
have
discussed
or
brought
up
the
from
field
here.
One
of
the
things
required
to
take
the
json,
that's
given
to
you
and
be
able
to
reconstruct
the
logical
tree
is
to
know
what
required
what
and
so
the
latest
addition
is.
I've
added
a
from
array
to
all
the
objects
that
give
the
local
path
is
the
attribute
that's
in
there,
because
that's
going
to
be
the
real,
that's
an
effective,
unique
id
for
all
these
things.
B
Instead
of
having
to
invent
a
new
one
that
tells
you
and
from
that
you
can
recreate
your
tree
again
down
the
road
that
was
the
minimal
thing
needed
without
something
we
might
want
to
back
out
of,
I
felt
that
was
we
can
keep
that
and
if
there's
something
else
we
also
want
to
do,
we
can
do
in
the
future
other
than
that.
It's
just
about
fixing
the
tests
for
the
case
insensitive
stuff,
I
added
and
making
sure
that
the
dev
prod
selectors
work
like
we
think
we
they
do
so.
A
Can
we
I
feel
like
we
need
to
update
the
rfc
with
those
two
things
specifically
the
case,
insensitive
and
sensitive,
attribute
selection
and
then
the
from
field
being
returned
which
might
round
out
that
dock
and
we
can
finally
ratify
it?
A
Does
that
sound
good
like
I,
I
can
go
take
that
away
as
yeah.
I
updated
docs
on
the
pr,
so
you
can
just
steal
back
from
that.
Okay
did
folks
have
any
questions
about
the
from
fields.
Jordan.
I
saw
you
potentially
no.
C
No,
I
think
all
of
my
concerns
about
it
have
been
addressed
by
adding
the
npm
explain
command.
So,
although
that
command
needs
additional
features
to
support
like
the
only
pro
only
dev
stuff
and
to
work
without
a
lock
file,
the
information
exists.
So
it's
no
longer
critical
that
it
be
buried
in
the
obscure
fields.
In
the
back,
the
reified
package,
json
cool.
A
Okay,
so
quickly,
moving
on
then
to
pr595.
This
is
proposed
backwards.
Compatibility
are
sort
of
provos
backwards,
compatible
improvements
to
compression,
I
believe,
evan
said
he
wouldn't
be
able
to
make
this
call
again.
I
believe
the
last
time
we
spoke
on
this,
we
were
waiting
on
an
update
to
get
some
more
data
on
the
results
of
just
some
testing
that
he
was
doing.
I
don't
know
if
anybody
else
has
any
other
updates
there.
A
To
pr
593
only
registry
target
balls,
I'm
not
sure
if
owen
was
able
to
make
the
call,
we
had
a
number
of
sessions
where
we've
gone
back
and
forth
with
him.
I
believe
the
last
update
was
blocking
blocking
on
npm
query
landing
to
actually
do
something
about
this,
but
I
felt,
like
owen,
had
enough
info
to
to
go
ahead
and
potentially
update
his
rfc,
so
not
sure
what
the
state
of
that
is.
A
D
Let
me
know
I
mean
if
you
have
any
questions
already
about
it,
just
a
couple
things
to
call
out
like
there
are
some
things
where
it
is
a
little
different
from
things
like
ca
file
like
it's
happening
further
downstream,
because
they're
registry
scoped,
and
so
like
back
in
config
and
the
cli
I
mean
there
is
that
get
credentials
by
uri,
which
it's
a
little
weird,
because,
like
that's
used
to
know,
if
you
know
we
need
to
authenticate,
but
we
don't
actually
use
those
credentials
and
then
down
in
npm
registry
fetch
it
like
pulls
about
in
the
same
way.
D
So
there's
some
like
weird
duplication
already.
So
that's
why
it
is
the
way
it
is.
Another
thing
to
call
out
is
I'm
doing
like
a
read
file,
sync,
because
that
is
that
was
the
most
straightforward
way
to
do
it,
but
if
we
want
to
make
it
async,
I
could
totally
do
that
just
a
little
more
complexity,
but
also
the
ca
file.
The
existing
one
does
a
read
file
thing,
so
there
is
a
precedent
there,
but
other
than
that.
D
A
Huge
yeah,
some
folks
usually
propose
things
and
never
follow
up
on
them.
So
it's
it's
huge
to
have
to
propose
this
and
then
do
the
work
so
go
ahead.
Sure.
C
About
the
read
file-
sync,
that's
actually
totally
fine
like
unless
there's
something
there
an
explicit
benefit
for
it,
but
it
might
be
wise
to
find
an
abstraction
layer
above
that,
where
you
can
make
that
async
forced
like,
even
though
it's
doing
the
read
file
sync,
because
then
that
allows
if
it
becomes
an
issue
later,
it
could
be
refactored
without
impacting
consumers
of
wherever
that
layer
is.
But
I
haven't
looked
at
your
diff,
so
I'll
trust
your
judgment.
There.
D
Yeah
totally
fair,
I
mean,
I
think
it
could
be
made
async
without
too
much
difficulty.
Just
right
now
down
an
empty
registry,
fetch
there's
this
off
class
and
it's
done
in
the
constructor,
or
so
we
can't
make
anything
there,
but
I
mean
it
could
be
deferred
a
little
later.
There's
like
the
actual
do
fetch,
which
is
an
async
function,
and
we
could
like
resolve
it
at
that
point,
and
that
would
be
fine.
A
Awesome,
I
don't
think
there's
any
updates.
Was
there
any
feedback
on
the
rfc
itself,
or
can
we
just
potentially
ratify
that
at
the
same
time,
I'm
making
updates?
Are
we
all
plus
one
to
just
ratify
it
as
I'm
seeing
head
nods
from
car
plus
ones-
okay,
great
so
expect
by
next
week,
then?
Hopefully
john
will
have
that
landed
at
least
the
rfc,
so
that's
set
in
stone
and
then
we
can
move
it
to
implement
it
once
we
land
in
the
prs
so
appreciate
you
pushing
through
on
this
awesome.
A
Thank
you
all
cool
moving
on
to
the
next
issue
that
was
brought
up,
there's
actually
three
of
them.
These
are
the
tracking
issues
for
npm,
v8,
v9
and
10..
Ten.
I
believe
I
may
kick
out
of.
D
A
Agenda
it
will
from
since
it's
pretty
much
over
a
year
away.
You
can
start
getting
folks
attention
to
it,
but
the
biggest
you
know
biggest
reason
these
are
being
listed
here
is
just
to
give
some
visibility
into
things
left
to
be
done
for
v8
and
as
we
get
ready
for
v9.
What
are
the
breaking
changes?
A
So
folks
may
have
seen
just
quick
updates
see
this
a
few
deprecation
warnings
go
out
and
we're
going
to
continue
to
flag
things
that
potentially
are
going
to
be
removed
in
v9,
with
depletion
warnings
and
basically
b9
the
the
goal
of
it
is
to
standardize
same
defaults
as
kind
of
the
holistic.
A
You
know
mantra
if
you
will
for
the
for
the
release.
The
last
major
release
from
the
cli
was
just
simply
to
bump
our
node
engines,
as
well
as
our
node
supported
node
versions
in
the
engines
field,
as
well
as
drop
the
programmatic
support
for
the
cli.
So
this
time
it's
going
to
be
a
little
bit
different,
we're
essentially
going
to
be
flipping
some
bits
on
some
configs.
A
But
ideally
you
know,
given
the
feedback
that
we've
got
from
jordan,
others,
you
know
we're
going
to
try
our
best
to
obviously
land
as
many
features
leading
up
to
that
release
and
continue
to
ship
things
and
be
right
up
until
we
can.
Our
team
hasn't
got
a
chance
yet
to
start
cutting
v9s
yet,
but
there
are
some
things
that
will
take
some
time
for
us
to
actually
get
done.
A
So
there
may
be
a
bit
of
a
pause
in
v8
releases
while
we're
shipping
for
like
a
month
or
so
probably
worked
to
v9.
A
So
that's
essentially
a
bit
of
an
update
there,
not
sure
if
folks
had
any
questions,
thoughts,
comments
about
the
next
major
anything
that
we
might
be
missing
in
those
lists
that
you
really
want
to
see.
A
If
not,
we
can
probably
move
on
so
that
was
49
47.
The
update
to
564,
which
is
the
fancy
selector
rfc,
is
just
that
all
updated
with
the
changes
to
the
cars
be
making
so
I'll
quickly
say
that
here.
A
B
C
I
see
you're
muted.
Oh
sorry,
apologies,
I'm
very
silent.
A
For
a
minute
talking
to
myself
so
quickly,
the
the
last
two
issues
here
that
we
have
the
1438.
A
Which
is
add
lips
e
fields
to
select
optional
dependencies
should
be
installed
or
skipped.
This
has
been
brought
to
your
attention
again
by
the
folks
at
purcell
and
was
is
something
that
both
yarn
and
pnpm
have
supported
now
for
a
while
is
definitely
something
that
we
can
support
and,
I
think,
should
support
prior
to
a
more
holistic
approach
to
distributions
or
or
improvements
to
optional
dependencies.
A
The
ellipsis
field
can
be
interacted
upon
in
a
similar
manner
to
the
other
and
be
used
kind
of
in
a
similar
manner
to
os
cpu
or
other
kind
of
platform.
Specific
fields
that
have
been
introduced
go
ahead.
C
A
It's
specific
to
it
is
different
than
I
would
say,
engine.
C
Okay,
like
I
noticed
it's
not
listed
in
process.versions,
for
example,
so
like
so,
nobody
would
be
declaring
this
in
their
engines
or
like
this
would
be
just
so.
It's
like
os
and
cpu
in
the
sense
that
npm
implicitly
reads
it
and
then
uses
that
to
figure
out
whether
the
package
can
work
or
not
exactly.
A
C
Are
there
likely
to
be
more
in
the
future,
or
is
this
like
the
only
missing
one?
Because
if
there's
likely
to
be
more
in
the
future,
it
might
be
wise
to
create
a
top
a
single
top
level
object
that
can
contain
os
or
cpu
and
lib
c
and
all
the
future
ones
so
that
you
don't
have
to
keep
adding
top
level
fields,
because
this
is
the
only
one
like
it's
fine.
A
A
C
C
A
I
think
at
this
point,
if
this
is
the
last
this
is,
this
would
be
likely
the
last
one
that
we
would
support
beyond
a
more
holistic
approach
to
right,
conditional
conditional,
optional
dependencies
right,
yeah
improvements
to
the
conditional
optional
dependencies.
Yeah
thanks
does
anybody
else,
have
any
questions
or
thoughts
around
this.
B
A
B
A
Cool
and
I
believe
that
that's
probably
a
very
small
like
detection
lib,
so
if
we
had
to
like
essentially
build
our
own
or
write
something
small
to
do
that.
This
one
supports
eight.
A
A
Cool,
so
if
there
isn't
any
other
feedback
on
that,
we'll
move
to
the
last
item
which
is
pr165.
This
is
the
rc
for
parent
apparent
package
json.
I
know
christian
wasn't
able
to
make
it
on
the
call
and
I'm
not
sure
if
they've
been
able
to
make
it
for
a
while.
Now,
I'm
not
sure
if
there's
any
updates
here
that
wes
was
gonna
give.
I
know
he
had
been
a
big
advocate
for
this
concept
and
he
said
that
he
was
gonna.
A
A
A
C
Like
yeah,
I
guess
that's
my
my
my
concern
is
avoiding
any
sort
of
runtime
extension
of
package.json
using
it
as
a
like
template
tool,
so
that,
like.
C
Yeah
I
mean
so
like
you
could,
you
can
use
extends,
and
then
you
could
like
generate
the
full
version.
I
don't
know
there's
I.
I
just
think
we
have
to
be
really
careful
about
that,
because
if
somebody
installs
a
package,
the
the
way
it
links
to
the
template
or
the
thing
that's
extending
or
whatever
there
would
need
to
be
a
way
to
guarantee
that
that
parent
is
accessible,
and
that
includes
sim
links
or
copy
pastes.
B
I
don't
know
how
many
of
you
have
tried
to
do
this
with
github
I
I
did
not
depend
a
bot,
but
there's
a
settings,
the
settings
bot
it
can
actually
extend
others,
but
it's
not
a
real
relational
relationship
to
where,
like
if
the
parent
one
changes,
you'll,
never
see
those
changes
in
your
own
and
so
having
an
inheritance
is
going
to
introduce
the
assumption
of
a
kind
of
relational
property
between
them
and
keeping
them
in
sync
is
not
a
trivial
matter,
and
I
don't
know
if
the
benefits
I
don't
understand
what
problems
this
is
solving.
B
I
don't
think
json
is
a
relational
extendable
spec
to
begin
with-
and
I
don't
know,
I
wonder
if
workspaces
or
npm
query
solve
either
of
the
problems
being
fixed
here.
C
C
I
don't
think
this
is
the
solution
for
that,
but,
like
I
can
see
that
kind
of,
because
you
like,
if
you're
in
isolated
mode
and
you
made
a
package,
that's
sub-dependent
on
those
like,
depending
on
the
top
one,
wouldn't
give
you
access
necessarily
from
outside
to
the
transitives
right
and
you
wouldn't
want
to
make
them
peer
dependencies
because
that's
a
lot
of
extra
tax
and
stuff.
So
it's
and
that's
that
would
be
the
only
way
you'd
have
to
do
it.
C
Is
you
make
a
package
that
peer
depends
on
all
these
things
and
then
you
force
the
period,
but
like
that's
a
lot
of
extra,
that's
like
more
work
than
just
having
all
the
versions,
the
same
so
like,
and
that's
just
one
of
the
parts
in
the
motivation,
so
I
guess
yeah.
I
think
it
would
be
helpful
to
get
a
really
clear
breakdown
of
the
use
cases
to
see
if
this
is
actually
the
best
solution
for
each
one
and
if
we
figure
out
the
best
solution
for
each
one.
How
do
they
overlap?
B
Our
template,
oss
repo,
solves
a
lot
of
these
problems,
the
the
fundamental
problem
of
having
a
centrally
managed.
I
need
to
update
a
lot
of
things
in
tandem
on
all
my
repos
template
oss
solves
almost
all
of
those
and
the
ones
that
it
solved
cleanly
is.
If
you
have
github
actions,
you
need
to
update
because
github
actions
can't
update
github
actions
outside
of
that
limitation.
I
think
our
template
oss
approach
solves
this
centrally
managed
problem.
C
I
mean
certainly
it
does
for
npm,
and
I
I'm
I'm
I
haven't
dug
into
it.
So
I
don't
know
what
constraints
or
like,
like
you've,
probably
been
able
to
bake
in
some
assumptions
and
constraints
that
are
specific
to
npm.
That
wouldn't
allow
template
oss
to
be
a
general
solution,
but
I
think
what
it
definitely
is
not.
B
C
Right,
yeah,
and
so
that's
what
I
meant
is
that
it
is.
It
certainly
validates
the
approach
that
it
can
be
done
outside
of
npm,
and
you
know:
I've.
I've
looked
in.
I've
had
visions
of
similar
tooling
that
I've
never
gotten
around
to
building
for
a
long
time
as
well.
That
sort
of,
unlike
the
create
react,
app
react
scripts
approach,
that's
sort
of
like
a
tool
that
always
reifies
your
package
json.
So
it
looks
like
the
tool
doesn't
exist
and
it
like
updates
the
right
scripts.
C
The
right
way,
and
so
on,
like
that
to
me,
seems
more
valuable
than
something
that
delegates,
because
it's
more
easily
easy
to
modify
it
and
it's
more
easy
to
see,
what's
being
changed
as
you
pull
into
configuration
changes
and
so
on.
That's
probably
an
opinionated
thing,
and
maybe
some
folks
disagree,
which
is
why
there's
like
the
react,
scripts
or
standard
type
approaches,
but
I
don't
know
either
way,
I
think,
for
the
rfc.
You
need
a
lot
more
use
case.
Expansion.
A
Yeah,
I
think
the
feedback
and
general
consensus
that
most
folks
come
to
eventually
is
that,
like
package.json
needs
to
be
static,
it's
not
like
a
dynamic
manifest
right,
like
we
don't
have
that
concept
in
the
ecosystem
and
and
ecosystems
that
do
have
that,
like
let's
say,
the
swift's
ecosystem,
like
have
problems
with
like
a
like
a
dynamic,
manifest
file
which
requires
you
to
you,
know,
actually
run
a
code
and
execute
the
manifest
file
to
actually
interpolate
it,
and
that
seems
dangerous.
A
That
seems
like
a
problem
that
you
you
know,
so
I
don't
know
I
I
feel
like
this
is
good.
It's
a
good
idea
for
separate
tooling
to
implement
these,
and,
I
think,
there's
maybe
space
for
a
standard
to
exist
like
a
standard
tool
to
exist
to
help
you
manage
these.
I
don't
know
if
it's
like.
A
I
don't
know
what
npm
can
do
necessarily
like
the
beyond
providing
better
ways
to
maybe
enforce
templates
via
maybe
the
pkg
like
sub
command.
Maybe
there's
a
way
for
us
to
like,
allow
you
to
validate
you
know
or
to
apply
a
template
to
you,
know,
workspaces
or
to
a
current
working
directory
and
and
yeah.
Maybe
extends
can
be
like
a
reference
for
where
that
template
lives
and
pkg
would
have
some
sort
of
understanding
to
use
that
and
then
apply
that
against
it.
A
C
Json
be
part
of
npm,
like
that
seems
useful
to
me
in
the
sense
that
a
repo
will
either
eslint
style,
it
will
fail,
it
will
have
ci
setup
that
will
fail
if
you
don't
update
your
package
json,
and
so
you
have
to
manually,
update
your
package
json
with
the
command
when
you
update
the
package.json
source
of
truth,
or
it
will
work
such
it,
won't
commit
a
package
json
at
all
and
it
will
ephemerally
generate
one
whenever
you
need
to
publish
or
do
you
know,
run
tests
or
whatever
and
in
either
case
there's
a
single
source
of
truth
and
there's
a
static
package
json
for
tooling
to
work
with.
C
So
the
if
npm
doesn't
support
anything
like
that.
Userland
can
still
do
all
of
those
things,
but
it
would
be
harder
to
have
a
coordination
on
the
file
path
and
the
format
and
the
schema
and
so
on
and
I've
one
thing:
I've
seen
a
lot
in
the
ecosystem
is
that
even
when
a
feature
doesn't
belong
in
a
core
having
the
rules
and
conventions
in
the
core
can
can
often
help
prevent
ecosystem
fragmentation
in
advance.
That
doesn't
mean
it's
worth.
Adding
it
to
npm.
A
So
the
general,
like
keys,
that
we
are
there's
like
a
known
set
of
keys
in
the
package.json
doc
that
we
have
today
that
we
respect
and
that
we
like
know
of,
but
then
there's
like
the
idea
that
you
could
arbitrarily
spec
out.
You
know
like
whatever
you
would
want
in
these
templates,
which
sort
of
extends
beyond.
I
think
the
like
the
tooling
that
we
would
build
yeah.
A
I
don't
know,
I
think,
there's
opportunity
for
this
be
updated
for
this
rfc
to
be
updated
and
for
us
to
consider
something.
If
christian
this
was
open
a
couple
years
ago,
if
christian
or
west
like
get
more
involved
again,
they,
I
would
definitely
be
open
to
us
building
something
like
this
into
pkg.
A
I
know
that
this
was
like
I
poked
wes
when
we
introduced
that
sub
command
as
like
a
hope
that
you
know
he'd
get
interested
since
he
built
a
bunch
of
tooling
in
this
area
and
potentially
bring
that
back
in
into
npm
itself
but
yeah.
It
seems
like
there's,
not
not
a
lot
of
work
here
unless
somebody's
willing
to
pick
up
the
mantle
to
like
redesign
this.
A
I
don't
see
owen
jumping
on
so
I'm
not
sure
if
his
conflict
has
run
long
sure
david.
I
think
we
have
lots
of
time.
Did
you
want
to
speak
to
that?
A
bit.
E
Yeah,
let's
see
sorry,
this
is,
I
think,
the
first
time,
I'm
here
so
hello,
I'm
david,
I'm
from
microsoft
and
yeah.
We
recently
I've
been
talking
with
vincent
about
some
of
the
strict
mode
or
the
the
work
that
he's
been
doing
to
enable
that
and
we've
run
into
a
number
of
issues
with
peer
dependencies
and
peer
dependencies.
E
Just
to
give
you
some
context,
I
I
started
our
fluent
component
library
a
long
time
ago,
and
I've
been
working
in
that
space
of
sort
of
the
middle
layer
component
library,
similar
to
material
ui,
where
we
have
react
as
a
peer
dependency
and
the
question
often
comes
up.
Do
we
have
the
component
library
as
pure
dependencies
of
other
component
libraries
that
apps,
build
and
peers
are
always
a
confusing
point
for
everyone,
because
we
don't
know
whether
we
should
list
things
as
dependencies
or
peers.
E
The
problem
is,
is
that
those
peer
dependencies
are
happening
at
the
middle
layer
depends
like
the
component
libraries
and
it's
really
not
necessarily
their
role
to
even
do
that.
E
There's
two
places
where
that
role
matters
there's
the
application
hosts,
because
they
want
to
dedupe
react,
and
then
there
is
the
library
itself,
because
they
know
they're
a
singleton
like
they
know
they
have
side
effects
and-
and
so
scenario
would
be
like
react
context.
We
have
a
react
context
package.
If
you
duplicate
it
many
times
it's
gonna
break,
it's
gonna
break
apps,
that's
a
very,
very
common
case
in
in
open
source.
E
So
really
what
we
want
is
a
kind
of
like
a
way
for
both
scenarios,
the
host
and
the
producer
to
be
able
to
either
declare
that
they're.
They
are
a
singleton
or
that
they
want
a
singleton
and
then
at
the
app
host
layer
there
are
edge
cases
where
something
that
might
be
a
singleton
might
be
okay
to
duplicate
because
they
sandbox
scenarios.
E
So
in
that
rfc
it
was
his
arcanus
arcanus
male
who
works
on
yarn.
He
gave
this
really
good
example
where
he
has
a
package
that
self-embeds
react
it
he
spins
up
the
next
server
and
in
hosts
react
in
his
own
space,
and
this
is
like
an
example
of
a
sandbox
scenario
where
react
can
be
duplicated,
because
if
my
app
post
uses
his
package,
I
might
have
my
own
copy
of
react.
But
I
know
it's
okay,
because
they're
separate
so
the
proposal
in
the
rfc.
E
I
I
stumbled
on
it
because
internally
we
were
saying
without
reading
the
rfc
packages
should
have
a
way
to
just
one
declare
what
policy
they
should
have,
whether
the
default
policy
is
okay,
duplicate
it
or
that
they
are
intended
to
be
a
single
tenth
and
then
at
the
host
layer
or
at
the
consumer
layer.
E
There
needs
to
be
a
way
to
say
whether
they
intend
for
a
package
to
be
a
singleton
or
they
intend
for
it
to
be
duplicated,
so
sort
of
like
a
way
for
them
to
override
the
default,
and
then
I
ran
across
this
rfc
and
I
started
chatting
in
it.
So
my
thought
was
a
couple
things.
E
One
is
if
we
had
this
feature,
I
feel
like
it
would
eliminate
this
constant
question
of,
should
I
should
I
list
my
dependencies
as
dependencies
or
peers
you're
just
listed
as
a
dependency
or
not
and
those
middle
layer.
Libraries
then
wouldn't
be
the
ones
responsible
for
defining
whether
it's
something
as
a
singleton
or
not.
It's
either
the
app
host
or
the
producer
that
those
are
the
right
places
to
to
define
that
relationship
or
that
that
expectation
and
yeah.
E
So
so
what
we're
thinking
internally
is
to
prototype
this
and
add
those
relationship,
definitions
in
our
package
jsons
and
build
some
sort
of
a
tool
to
try
it
out
to
enforce
it.
That
runs
on
like
a
post
install.
So
after
we've
installed
check
the
policies
make
sure
everything
is
is
a-okay
and
if
they
aren't
then
explain
why
so
that's
the
other.
Nice
thing
is
that
if
you,
if
you
d,
if
you
declare
things
to
be
singletons
or
that
you
expect
it,
the
error
messages
are
way
more
explicit.
E
They're
saying
this
thing
is
supposed
to
be
happening,
one
time
and
here's
where
we're
violating
that
that
expectation,
as
opposed
to
like
with
pure
dependencies,
it's
a
little
bit
arbitrary.
What
the
intent
is
sort
of
you
can
kind
of
say
well,
there
are
unmet
expectations,
but
then
you
know
you,
you
kind
of
have
to
have
these
sort
of
workarounds
to
get
around
it
like
a
resolutions
is
a
common
scenario
and
then
you
get
into
violations
that
don't
quite
work.
C
Yeah,
so
everything
you're
describing
is
exactly
what
peer
dependencies
already
do.
You
are
describing
accurately
and
education
and
intuition
and
confusion
problem
caused
by
the
naming
and
by
people's
under
appreciation
of
the
complexities
of
dependency
graphs,
but
like
I
used
to
maintain
airbnb's
component
library
so,
like
I'm
very
familiar
with
the
exact
use
case.
C
You're
talking
about
pure
dependencies
are
basically
a
hoisted
requirement
and
at
any
point
in
the
graph
when
they're
as
you
move
up
as
they
are
declared
as
an
explicit,
dep
or
dev
depth
they're,
I
guess
until
you're
at
the
top
that
resolves
it,
and
so
in
mile's
use
case.
C
He
would
put
react
as
a
dependency
at
the
top
of
his
little
isolated
sandbox
graph
and
that
would
satisfy
all
of
the
pure
depth
requirements
below
it,
assuming
they're
all
compatible
and
then,
above
that
anything
outside
of
that
you
could
have
another
copy
of
react
and
it
would
be
perfectly
fine
right
so
like
that
pure
dependencies
already
handled
that
and
then
similarly
with
the
component
library
approach
other
things
when
you
depend
directly
on
the
component
library,
the
react
pure
depth
requirement
keeps
going
hoisted
up.
C
So
you
don't
actually
have
to
peer
depend
on
the
component
library,
because
the
only
danger
would
be
if
you
peer
depend.
If
you
depended
on
two
different
versions
of
the
react
component
library,
that's
pure
dependent
on
the
same
version
of
react,
then
that
would
work.
Fine
right
and
you'd
end
up
with
two
duplicate
copies
of
some
components.
C
But
maybe
your
one,
you
know
one
code
path
is
depending
on
something
that
would
break
with.
You
know,
like
you
have
v1
of
the
component
library
and
v2
that
both
use
react.
17
overrides
doesn't
solve
that
because
they
must.
There
must
be
two
copies
because
they're
two
different
apis.
So
the
only
solution
in
that
case
is
you
have
to
upgrade
them
both
to
v2
or
downgrade
them
both
to
v1
and
change.
The
function
calls
correspondingly
right
so
like
in
that
case,
npm
is
functioning
perfectly
as
our
peer
dependencies.
C
It
is
correctly
allowing
you
to
use
two
incompatible
apis
and
correctly
merging
the
two
peer
dep
requirements,
because
they're
compatible
and
the
only
downside
is
your
bundle.
Size
is
large,
but
that's
not
broken.
That's
just
like
larger
right,
and
so,
if
it
does
break
something
because
their
state
in
your
component
library,
then
in
that
case,
your
component
library
should
be
declared
as
a
pure
depth
everywhere,
except
at
the
top
level
app
and
then
the
same.
It
shakes
out
the
same
way
as
react.
C
Does
right
and
and
I'd
be
happy
to
dig
in
with
specific
use
cases
if
you
find
that
that
doesn't
work,
because
I
have
a
lot
of
experience
starting
these
things
out.
The
challenge
with
having
the
package
author
try
to
proscribe
how
their
package
is
used.
Is
that
they're
wrong,
sometimes
and
mile
is
saying
well
yeah,
but
if
you
know
they're
right
most
of
the
time,
then
the
advanced
users
will
figure
it
out.
C
C
B
So
the
other
thing
is,
you
still
have
to
declare
the
peer
dependency
in
a
tight
environment,
because
you
have
to
declare
only
react.
5
works
with
me
because
4
is
going
to
send
me
stuff.
I
don't
understand
right,
so
you
can't
remove
it
in
the
cases
where
it's
being
used.
Just
because
you
need
to
make
sure
every
time
I
require
react,
I'm
going
to
get
the
same
one.
It's
a
separate
problem,
the
peer
dependencies
stay
and
they
already
do
solve
the
problem.
B
It's
just
a
disconnect
between
things
working
by
coincidence
and
then
people
thinking,
that's
the
rule
in
how
things
are
hoisted
and
then
it
breaks
when,
when
things
stop
being
de-duped
in
the
tree
so
yeah,
it
really
is
an
education
problem,
because
there
is
no
way
outside
of
being
locked
in
on
your
peer
dependencies
of
making
sure
the
right
thing
gets
hoisted
at
the
top
yeah,
it's
it's
and
again,
it's
like
jordan,
said
there's.
B
There
could
and
probably
should
be
better
ways
for
mpm
to
help
you
discover
and
surface
that
of
of
you
know,
what's
hoisted,
what's
not
how
to
how
to
find
out
how
many
copies
of
some
things
where,
if
I
require
it
from
here,
I'm
going
to
get
this
copy.
B
If
I
require
from
here
I'm
going
to
get
this
copy,
it
really
is
an
education
and
and
declaring
that
you
want
to
be
a
singleton,
is
no
different
than
us
being
just
stronger
about
deduping,
because
there's
going
to
going
to
be
points
where
they
still
have
to
declare
their
peer
dependencies
because
of
type
problems.
And
then
we
haven't
fixed
any
anything.
E
So
when
we
respond,
I
don't
know
how
to
use
zoom,
to
be
honest,
really
well,
and
so
I
can't
raise
my
hand
I'm
trying
to
figure
it
out,
but
so
the
reactions.
Thank
you
I'll.
Try
to
find
I'm
getting
weird
video
problems
here,
but
all
right,
the
the
thing
that
I
I've
run
across
is
there's.
Certainly
a
learning
problem.
E
Like
you,
you
all
were
kind
of
alluding
to
there's
people,
don't
100,
understand
or
have
different
understandings
of
what
pure
dependencies
are
actually
doing
because
they're,
not
the
word
peer
itself,
doesn't
completely
explain
what
it
does.
E
It's,
I
think
that's
a
learning
problem,
but
I
think
the
the
fundamental
other
there's
like
four
problems
all
rolled
into
one
one
is
the
first
one
is
like.
Besides
the
the
lack
of
understanding
I
I
and
by
the
way
in
that
scenario,
we
asked
developers,
you
know
what
what
peer
dependencies
are
and
whether
they
would
use
a
regular
dependency
or
not,
and
they
I've
heard
people
say
well
peer
dependencies
are
where
we
declare
our
large
ranges.
E
Dependencies
are
for
the
small,
it's
more
precise
ranges
like
they
don't
realize
that
you
can
have
a
large
range
in
your
dependencies,
so
that,
like
there's,
certainly
like
misconceptions
there,
but
we
have
repos
where
developers
don't
know
what
to
do
with
unmet
peer
dependency
warnings.
They
just
have
hundreds
of
them
spewing
and
there's
all
these
incompatibilities.
E
E
So
there
are
some
workarounds
for
that,
but
but
I
think
the
real
frustration
is
is
if
I
npm
save
some
some
sort
of
dependency,
I
don't
know
if
that
dependency
can
be
duplicated.
So
back
to
the
the
sort
of
allusion
to
react
being
duplicate
on
the
page.
There's
we
shouldn't
assume
that
it's
safe
to
duplicate
it.
I
don't
think
that's
a
safe
assumption,
because
we've
seen
in
production,
that's
not
a
safe
assumption
when
we
have
certain
packages
that
go
window,
dot
foo
equals
bar
and
they
assume
that
window.
E
E
You
know
to
have
one
copy,
like
css
libraries,
you
know
common
scenario
where
you
know
class
names
are
generated,
you
have
two
copies
and
now
you
have
and
then
they
use
like
index
based
class
generation
and
they
start
at
zero,
and
you
have
two
two
libraries
now
colliding
with
their
class
names
that
they
they
generate,
and
so
they're
they're
definitely
bugs
that.
We've
seen
as
a
result
of
things
that
expected
to
live
on
the
page
once
that
didn't
and
then
the
again
the
ques.
E
The
problem
is,
is
that
you
either
have
to
have
everyone
in
the
graph
participate
in
pure
dependencies
or
it
doesn't
work
or
it
doesn't
get
enforced.
And
so
you
end
up
with
duplication,
and
I
think
that's
why
I'm
I'm
thinking
libraries
that
are
intended
to
live
once
in
the
graph
should
be
able
to
declare
some
metadata.
E
That
says,
I'm
intended
to
live
once
in
the
graph
and
then
middle
layer,
libraries
don't
need
to
make
the
choice.
Is
it
safe
for
react
to
live,
multiple
copies
in
the
dependency
graph
or
not
or
or
styled
components,
or
whatever
happens
to
be?
But
you
know
their
assumptions
are
never
going
to
be
100
correct.
There
are
like
a
you
know:
there
are
edge
cases
where
react
can
live
three
copies
on
in
the
same
depth.
Graph.
E
That's
totally
fine,
but
you
have
to
be
very,
very
intentional,
like
you
have
to
know
that
those
are
sandbox
scenarios
they're
not
going
to
share
context
you're
not
going
to
be
pulling
some
context,
objects
from
one
instance
and
then
assuming
it
to
be
the
same
one
in
another.
So
got
this.
C
Sorry,
a
few
things
first,
the
reason
you're
having
all
those
errors
is
because
until
npm
seven
nobody
realized
that
they
were
you
having
invalid
dependency
graphs,
starting
in
like
2016,
I
ran
npm
ls
in
ci
on
all
airbnb
projects,
internal
external
and
it
exposed
legion
dependency
errors.
We
just
our
dependency
graphs
were
invalid,
like
a
dozen
different
ways.
C
Resolving
those
is
a
manual
problem
that
still
needs
to
happen.
Now,
even
if
you're
on
npm
six,
you
can
run
npm
ls
and
if
that
doesn't
succeed,
your
graph's
invalid.
You
shouldn't
be
able
to
rely
on
anything
working
and
nothing
matters
until
you
fix
that.
So,
like
the
new
errors
that
are
in
npm,
seven
and
eight
are
going
to
be
painful
for
people
with
an
existing
application
for
a
while,
because
it
is
exposing
the
fundamental
brokenness
in
their
dependency
graph
that
has
likely
existed
for
years.
C
That
they've
been
completely
ignoring
that
sucks
for
everyone
involved,
but
once
it's
resolved
it
will
stay
resolved
and
everything
will
work
better.
C
The
next
thing
was
another
thing
that
has
to
be
enforced
in
the
entire
dependency
graph,
where
it
doesn't,
work
is
sember.
It
works
really.
Well,
even
though
that's
the
requirement,
because
people
know
that
it's
better
and
then
the
third
case
is
the
things
that
have
to
be
a
singleton
are
the
edge
case.
C
It's
a
very
small
number
of
packages
like
there's
a
reason
that
javascript
as
an
ecosystem
stays
away
from
mutation
and
statefulness,
because
those
things
are
terrible
and
they
should
be
the
edge
cases
and
that's
why
like
react
has
to
be
appeared
at
because
it
has
to
hold
state.
But
virtually
nothing
else
in
the
react.
Ecosystem
should
be
because
it
doesn't,
and
similarly
in
the
eslint
ecosystem,
eslint
core
has
to
you
know
be
appeared
at
because
its
plugins,
you
know
have
to
interoperate.
C
But,
like
I
mean,
there's
a
little
bit
of
state
there
as
well,
but
like
individual
es
link,
don't
know,
the
asl
is
probably
a
bad
example
because
they
have
to
interoperate
with
a
static
config
file
and
so
like
every
eslint
plug-in
has
to
be
a
pure
depth.
But,
like
I
don't
know,
babel
is
probably
a
better
example
where
the
core
has
to
be
appeared
up,
and
nothing
else
does,
and
it
works
just
fine.
C
It's
certainly
an
edge
case
to
have
two
different
react:
trees
on
your
web
page,
but
it
also
works
perfectly
fine
and
nothing
gets
broken
as
long
as
there's
no
like
cross
talk
between
the
two
react,
trees
with-
and
I
admit
that
can
get
tricky,
which
is
why
most
modern
apps
are
like
for
reactor
built
from
scratch
as
one
tree
instead
of
people
trying
to
patch
smaller
trees
into
an
existing
legacy.
C
What
would
it
make
it
easier
to
surface
and
explain
to
people
how
to
fix
the
existing
pile
of
of
garbage
fire?
That
is
most
people's
dependency
graphs?
If
so
that
alone,
that,
like
alone,
might
mean
it
has
enough
value
to
do
something,
because
it
is
very
painful
for
a
lot
of
people
to
get
their
depth
graph
into
shape.
But
I,
once
those
errors
don't
exist,
I
don't
think
there's
any
added
value
on
top
of
pure
depths
to
be
had
like
once
the
errors
are
resolved.
A
Go
ahead
and
then
I'll
hopefully
also.
B
I
agree
with
jordan
that
typically
a
a
package
author
isn't
always
right
about
declaring
that,
but
I
I
think
an
app
designer
should
be,
and
is
it
possible
we
instead
give
the
app
designer
a
way
to
say.
I
should
only
have
one
react
in
my
tree
and
then
npm's
like
you.
Don't
I'm
not
going
to
install
or
I
do
so.
B
It's
a
contract
that
you
just
say,
hey
npm,
make
sure
that
everything
that
requires
react
is
going
to
get
the
same
one
and
if
it
doesn't,
I
need
to
see
that
as
an
error
and
that
could
be
a
way
to
or
as
an
app
designer.
I
don't
have
to
worry
about
that
people
still
could.
If
it's
working
for
them
now
with
two
reacts,
that's
fine!
If
they
know
they
need
one,
they
are
the
ones
who
know
that
and
they
can
put
in
their
app
versus
the
dependency.
B
Is
that
a
path
we
could
see
going
down
to
help
people.
C
I
see
david
nodding
a
lot.
I
just
want
to
get
a
clarification
gar.
If
I
could
jump
in
the.
Are
you
proposing
something
that,
like
a
dev,
only
lock
file
would
only
affect
the
current
project
and
even
like,
even
if
it
was
in
package
json,
it
would
never
matter
that
that
metadata
was
in
your
node
modules.
It
would
only
be
for
the
current
app
essentially
because
I'm
wondering
then
sorry
only
if
you're
npm,
installing.
C
Right
so
I'm
wondering
if,
for
example,
so
just
I
have
a
package
where
I
am
collecting
a
bunch
of
packages
in
from
like
so
this
is
es
shims
right,
so
I
have
a
I
have
a
hundred
and
some
individual
packages
and
they
all
transitively
depend
on
some
similar
utilities
and
I'm
trying
to
make
a
like
mega
package
that
includes
them
all
and
I'm
trying
to
minimize
duplications.
C
Is
this
the
sort
of
thing
that
I
could
also
say?
I
don't
want
duplicates
of
these
transitive
depths
and
have
it
error,
but
that
wouldn't
affect
any
of
the
downstream
usage,
then
that
and
that
would
obviously
work
just
as
well
for
a
full-on
website
that
was
saying
like.
I
only
want
one
copy
of
react.
That
seems
like
an
interesting
direction.
E
Yeah
that
that
that
I
put
a
little
json
blob
in
there,
but
something
that
would
allow
you
at
the
app
host
layer
to
say
I
expect
one
thing
of
muy
or
whatever
it
is
to
be
there
or
react,
because
then
it
doesn't
matter
in
the
middle
tier
layers,
whether
or
not
they
use
peers,
it
would
just
be
enforced.
And
then,
when
it's
when
it's
violated,
then
the
tool
fails
and
it
and,
like
you
said
it
actually
like.
I
think
we
would
have
enough
data
or
like
enough
understanding
to
give
a
reasonable
error
message.
E
That
would
tell
you
how
to
resolve
it
like
that's
always
where
we
get
stuck
is
like
okay.
You
know,
some
error
happened
and
we
introduced
a
dupe
and
where
did
they
get
introduced
and
having
this
sort
of
like
a
way
to
define
this
policy
would
allow
us
to
say
you
said
that
you
expected
this,
but
now
we
have
that
as
a
result
of
this
pull
request,
or
this
install
when
we
upgraded
something,
and
so
what
we
were
thinking
was
to
build
some
sort
of
tool
like
that
and
play
with
the
error
messaging
to
see.
A
We
only
have
a
couple
minutes
left
here.
I
just
made
a
note.
This
sounds
very
similar
to
conversations
we've
been
having
in
other
rc
calls
in
the
months
leading
up
to
this
one.
A
Actually,
so
improvements
to
audit
have
actually
been
floated
a
few
times,
including
what
kind
of
other
checks
could
people
have
that
could
expand
sort
of
the
scope
of
audit
and
we
keep
going
back
to
the
fact
that
we're
introducing
npm
query
soon,
which
is
going
to
be
this
robust,
selector,
defensive,
selector,
syntax
that
allows
you
to
create
at
least
the
selector
that
you
could
apply
to
policies.
Let's
say
similar
to
what
you're
saying
like
that.
That
could
become
the
thing
that
that
you
then
pass
to
an
audit
that
checks
for
specific.
A
You
know
numbers
of
results
from
that
query
right.
So,
if
you
pass
query
to
let's
say
empty
modded
for
a
specific
check,
it
would
check
to
make
sure
that
you
only
have
one
one
version
one
copy
of
each
one
of
those.
You
know
dependencies
being
returned
and
then
fail
if
otherwise,
but
it
seems
like
this
is
definitely
something
we
want
to
keep
on
the
radar.
A
I
actually
added
the
agenda
label
here,
because
I
know
that
we're
probably
going
to
run
right
up
to
time
here,
so
we
definitely
would
be
willing
to
talk
about
this
again
david
if
you're
willing
to
join
us
again
next
week
and
talk
a
bit
more
about
what
we
could
be
doing
in
this
space.
A
Yeah
sounds
good
yeah.
I
see
jordan
and
garbo
said
same
things.
Sorry,
audit
subtypes
makes
a
ton
of
sense,
yeah
cool.
Well,
thanks
everybody
for
jumping
on
today.
I
know
we
basically
ran
right
to
time
and
david.
Thank
you
so
much
for
bringing
up
the
singleton
issue
I
didn't
realize
they
had
had
so
much
traction
and
last
little
bit.
A
So
thanks
for
flying
in
that
and
we'll
make
sure
that
we
talk
about
it
next
week
as
well
feel
free
to
keep
going
and
giving
feedback
in
the
rc's
themselves
and
discussions
and
we'll
hopefully
see
you
next
week-
cheers.