►
From YouTube: Open RFC Meeting - Wednesday, Oct 7th 2020
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
Hello,
can
you
spam
the
meeting
notes?
Sorry,
I'm
late,
no
worries.
B
And
we're
live,
welcome
everybody
to
another
fpm,
open
rc
call.
Today's
date
is
october
wednesday
october
7th
2020
we'll
be
following
along
the
agenda
that
was
posted
in
the
npm
rc
issue.
B
Issue
number
248
and
I
just
copy
and
pasted
the
hack
indeed
doc,
feel
free
to
add
yourselves
to
the
attendee
list.
Today
we
want
to
be
a
little
bit
mindful
of
time
as
folks
may
or
may
not
know.
We've
been
shipping
a
number
of
releases
of
mpm7
and
trying
to
you
know
queue
up,
essentially
a
release
that
will
go
into
node.
B
15,
actually
rc3
went
into
note
15
master,
so
you
should
be
able
to
get
it
today,
but
we're
hoping
to
have
another
one
queued
up
by
the
end
of
the
week
and
then
another
one
for
early
next
week.
So
with
that
in
mind,
we
want
to
shorten
the
length
of
the
agenda
today
and
just
focus
on
a
single
topic
and
and
then
hopefully
open
things
back
up
again
next
week.
B
So
the
one
item
that
we
actually
want
to
to
make
sure
that
there
was
some
time
a
good
conversation
around
is
the
pr
239
so
describing
how
mpm7
is
actually
handy
in
pure
depth,
conflicts
and
yeah
before
we
dive
into
that
again
in
these
calls,
we
ask
that
you
know
please
be
mindful
and
and
respectful
of
each
other
and
raise
your
hand
when
you
get
something
you'd
like
to
say
and
that
these
calls,
as
well
as
all
discussions
in
the
rfc
repo
itself
and
and
our
root.
B
Those
are
covered
under
conduct
and
I'll
actually
give
the
floor
to
any
folks.
If
there's
any
announcements
before
we
dive
into
that.
B
Topic,
if
not
I'd
love,
to
give
the
floor
to
isaac
to
maybe
take
in
on
this
specific
document,
which
is
pretty
lengthy
if
folks
haven't
had
a
chance
to
look
at
yet,
please
take
some
time
to
read
through
and
yeah.
Maybe
you
can
speak
a
little
bit
to
what
this
is
was
what
this
is
sort
of
outlining
for
client.
A
And
I
think
there's
there's
some
points
in
it
that
I
I
would
actually
like
to
change,
just
as
as
we've
gone
through
as
I've
been
kind
of
digging
through
the
implementation
and
and
looking
at
kind
of
like
what
makes
sense.
What's
the
best
user
experience.
What's
you
know
possible
to
do
one,
I
think
probably
the
you
know
if
we
were
to
zoom
out
at
a
very
high
level
as
a
user
of
npm
packages
as
a
consumer
of
them.
A
A
You
know,
with
kind
of
the
the
legacy
pure
depths
approach
there
are.
There
are
two
things
that
I
think
are
are
then
kind
of
reasonable
things
that
fall
out.
Of
that
the
I
mean
the
sorry
just
to
back
up
a
step.
The
the
other
thing
I
want
as
a
consumer
of
of
packages
in
the
npm
registry
is,
I
want
them
to
not
have
conflicting
peer
dependencies.
A
So
it's
these
are
somewhat
in
conflict
right,
because
the
simplest
way
to
make
install
time
just
work
is
we
just
don't
install
peer
apps,
that's
what
we've
been
doing
and
the
simplest
way
to
ensure
that
that
whatever
does
install
actually
works
and
is
tested
is
we
are
super
super
strict
and
we
just
you
know
like
the
initial
kind
of
npm,
seven
betas
crash,
if
there's
any
unresolvable
pure
depth
setup,
so
the
the
way
that
we're
trying
to
thread
this
needle
is,
if
you
set.
A
A
You
know
no
install
for
you
if
you
have,
if
you
set
legacy
pure
depth,
obviously
we'll
work
the
same
way
that
we
previously
did.
We
just
don't
even
look
at
pure
depths
and
that's
way
on
the
other
side
of
the
spectrum
if
you
set,
but
then
in
this
middle
ground,
what
we're
trying
shooting
for
is
effectively
if
the
pure
depth
conflict
is
your
fault.
A
Then
we
crash
the
install.
We
don't
it.
We
don't
do
the
install
for
you
if
the
pure
depth
conflict
is
not
your
fault,
it
comes
from
a
dependency
that
you're
pulling
in,
or
you
know,
you're
installing
you're,
installing
a
dependency
and
two
of
its
dependencies
have
conflicting
peer
depths
and
it
specifies
a
third
version,
maybe
like
we'll
just
kind
of
do
what
is
the
most
likely
the
most
reasonable
kind
of
resolution
that
we
can,
which
will
get
you
by,
and
so
I
think
this
is.
I
think
this
is
reasonable.
A
I've
talked
to
a
number
of
you
about
this,
and
it
seems
like
it's
kind
of
the
best
way
to
the
best
compromise
to
sort
of
get
us
forward
so
that
ipm
7
isn't
sort
of
overly
pedantic
in
doa,
but
also,
you
know,
does
kind
of
nudge
the
the
development
community
towards
having
you
know,
non-conflicting
pure
dependencies
by
alerting
them
much
more
forcibly
when
it's
a
problem
in
their
own
project
and
then
the
third.
A
The
third
thing
to
add
on
to
that
is:
if
you
set
force,
you
know,
because
even
if
you
have
a
peered
up
conflict
and
even
if
it's
your
fault,
you
may
want
to
fix
something
else.
First,
and
now
you
just
need
to
install
so
shut
up.
Npm
get
out
of
my
way.
That's
kind
of
what
the
the
dash
f
option
is
right,
just
just
force
it.
I
don't
care,
it's
broken
whatever,
and
so
we
have
these.
This
sort
of
spectrum,
where
strict
is
crash
on
anything
non-strict,
is
crash.
A
When
it's
not
my
crash,
when
it's
my
fault
and
forces,
never
crash
on
anything,
just
just
power
on
through
the
one
thing
that
I
think
is
a
a
little
bit
of
a
discrepancy
in
the
in
the
rfc
and
with
the
current
release,
candidate
versions
is
even
in
non-strict
mode.
A
We
are
crashing
for
peer
dependency,
conflicts
that
are
not
caused
by
your
project.
If
we
could
not
determine
what
the
you
know,
appropriate
resolution
would
be,
and
I
think
in
those
cases
that
the
change
I
want
to
make
to
this
rfc
is
in
those
cases.
If
it's
not
your
fault,
we
should
probably
still
just
behave
as
if
it's
forced
and
take
the
first
one
that
was
placed
there,
because
you
know
you're
not
in
a
position
to
fix
it.
A
So
crashing
is
kind
of
rude,
so
I'll
open
it
up
to
the
rest
of
everybody
to
to
chat
about.
I
don't
know
if
I
know
I
know.
Jordan
has
some
some
feelings
on
this.
I
know
I'm
guessing
christian
and
some
others
do
as
well.
C
That
said,
if
even
if
the
con,
like
yeah,
I
mean
so
that's
fair,
but
I
meant
by
technical,
I
meant,
like
you
know
it's
about
feasibility
as
opposed
to
or
like
like.
Can
you
achieve
it
right
and
right
yeah?
So
so
it's
important
and
I'm
not
trying
to
minimize
it.
C
I
think
that
the
reality,
though,
is
that
if
somebody's
pure
depths
are
invalid,
if
strict
would
fail,
then
there's
kind
of
two
main
scenarios
that
we're
concerned
about
one
is
somebody
coming
upgrading
to
npm,
seven
on
a
dependency
tree
that
already
seemed
to
work.
The
other
is
somebody
already
on
npm,
seven,
adding
a
new
dependency,
the
upgrade
from
six
to
seven
that,
like
it's
out
completely
out
of
their
control,
the
dependency
graph
worked
like
they
shouldn't
have
to
fix
that
in
order
to
upgrade
to
npm
seven.
You
know
like
that.
C
That's
the
worst
outcome
I
think
for
for
having
strict
on
by
default
would
be
the
people
in
that
bucket,
but
once
somebody's
already
on
a
strictly
valid
depth
graph
and
then
they
add
a
new
dependency.
I
think
that
the
correct
thing
is
that
they're
blocked.
They
can't
add
that
package,
because
it's
pure
depths
are
invalid.
It's
incompatible
right
like
they.
C
They
should
have
to
jump
through
hoops
to
make
to
to
invalidate
their
depth
graph,
even
if
it's
the
fault
of
another
project
maintainer,
and
I
I
as
a
project
maintainer
who
participates
in
many
ecosystems
where
invalid
peer
debts
cause
lots
of
subtle,
bugs
that
are
hard
to
track
down
in
triage
such
that,
like
my
issue,
templates
and
automatic
refrain
at
this
point
is:
does
npmls
exit
zero
if
not
everything's
broken
go
away
like
essentially
because
that
sniffs
out
a
lot
of
these
problems?
C
So
I
I
think
that
it's,
it
would
be
much
better
for
usability
for
these
users
to
get
blocked
when
they
try
to
upgrade
their
version
of
react
or
eslint
or
babble
or
whatever
than
to
be
blocked
a
week
or
two
later,
when
they
thought
everything
was
working.
But
then
they
have
some
weird
bug,
and
now
they
have
to
spend
to
like
rope
in
a
maintainer
to
like
burn
up
hours
of
time,
trying
to
figure
out
what
the
real
problem
is.
C
I
don't
when
I
suggested
a
middle
ground
between
those
two,
like
two
scenarios,
it's
correctly
been
called
out
as
being
too
magical,
so
I
don't
really
have
a
good,
a
better
solution,
but
I
think
that
that
it
is
vastly
important
that
somebody
not
be
able
to
like
not
just
unknowingly
but
not
at
all,
invalidate
their
valid
dependency
graph,
like
warnings
are
nice,
but
my
experience
is
that
people
don't
read
words.
So
unless
the
exit
codes
are,
are
non-zero
they're
not
going
to
pay
attention
by
and
large.
A
What
we
could
do
you
know
one
one
idea
that
might
be
less
magical,
although
unfortunately,
less
effective
would
be.
If
we,
if
we
run
an
install,
there's
no
pure
depth,
warnings
and
strict
is
not
on.
A
C
A
Yeah,
well
I
mean
it
is.
It
is
a
little
bit
of
a
cost
just
because
every
everything
we
say
has
some.
You
know
small,
but
but
relevant
impact
on
on
kind
of
the
overall
noisiness.
C
D
Sure
so
yeah
I
do
agree
with
jordan
in
that
we
should
probably
try
to
be
as
strict
or
as
noisy
as
possible
to
get
people
to
fix
their
dependency
graphs.
However,
the
question
is
a
bit
like:
do
we
want
to
be
more
strict
in
npm
8
in
the
future
and
then
another
thing
would
I
be
able
to
set
a
default
in
npm
rc,
because
I
think
that
would
be
super
useful.
D
D
No,
actually
with
just
what
what
isaac
just
wrote
in
the
chat
that
you
can
actually
set
a
config
so
that
it
will
always
be
strict.
C
Right
I
mean
that
that
and
the
fact
that
I
can
do
that
globally
is
nice
right.
It
means
that
I
can
like.
I
have
hundreds
of
projects
and
I
can
get
those
warnings
and
not
force
other
people
to
deal
with
them
like,
so
that
there's
something
there
but
like
the
the
audience
I'm
most
concerned
about,
is
not
the
developers
who
know
to
do
things
and
turn
things
on.
It's
the
ones
who
report
problems
and
don't
know,
thankfully,
don't
know
the
inner
workings
of
npm.
A
I
mean
another
another
take
on
this
like
from
the
whole,
like
warnings
or
ineffective
point
of
view
is
that
we
are
reducing
the
the
noise
considerably
with
npm
seven,
and
this
is
a
very,
very
noisy
warning.
It's
multiple
lines
that
it,
you
know
shows
info
about
the
the
graph
of
dependencies
that
led
you
to
that
place
and
so
on.
A
So
I
think
it's
it
may
be
more
impactful
than
you
know,
for
example,
the
previous
ineffective,
like
pure
depth,
missing
warnings
right
because
it
actually
tells
you
what's
going
on
and
and
what
the
problem
is
in
a
way
that
previous
things
didn't
really
and-
and
we
don't
have
like
no
node
built,
you
know
binary,
build
output
and
other
scripts
and
a
billion
other
things
flooding
your
screen
at
the
time.
So
it
does
stand
out
a
little
bit.
A
A
You
know,
even
if
you're,
if
you're
running
a
hundred,
builds
a
day
in
ci,
you're,
still
probably
running
it
once
every
day
or
two
on
your
local
machine
and
given,
given
how
much
people
complain
about
our
other
warnings.
I'm
somebody
is
seeing.
A
A
I'm
not
really
hearing
any
other
objections
about
the
you
know
fail
when
it's
mine
and
force
when
it's
not
default,
though
I
think
I
think
that's
like
the
only.
E
Wow,
well,
I
do
have
a,
I
think,
it's
more
of
a
maybe
a
clarification
on
the
algorithm.
You
explain
in
the
beginning
yeah,
so
it
is
not
going
to
fail.
It
is
going
to
succeed
if,
if
a
dependency
is
higher
up
in
the
tree
right
like
closer
to
the
top
level,
so
that
we
can
reasonably
say
that
this
is
probably
the
safest
one
declared
within
the
tree.
But
if,
at
the
same
level
you
have
competing
and
conflicting
versions
for
a
given
depth,
then
it
will
still
fail
right.
The
install.
A
Well,
that's
kind
of
the
the
change
that
I'm
suggesting,
I
think
really,
if,
if
it's
not
your
dependencies,
that
are
conflicting,
so
the
situation
that
that
roy
is
alluding
to,
let's
say
I
have
a
a
a
package
dependency
I
depend
on
x.
A
A
It's
very
likely
that
a
like
in
x's
root
project
it
would
fail
by
default
and
b.
If
I'm
installing
x,
there's
probably
no
way
to
get
a
version
of
z,
that's
going
to
get
the
right
version
of
y
because
of
this
explicit
dependency
coming
from
the
thing
I'm
actually
installing.
A
In
that
case,
we
just
go
with
the
version
that
that
x
wanted,
because
I'm
installing
x
x
has
a
specific
non-pure
declared
dependency
in
in
past
times,
like
that's
the
one
that
would
end
up
getting
installed
anyway,
it's
probably
the
one
that
has
actually
been
tested.
You
know,
in
spite
of
what
the
pure
depths
say,
so
we
go
with
it
there's
another
case.
Where
say,
I
depend
on
package
x,
it
depends
on
packages
y
and
z
and
y
and
z.
Each
have
a
pure
dependency
on
w
on
a
conflicting
version
of
w.
A
So
I
have
no
clear
indication
of
like
which
thing
is
higher.
Priority
right
x
doesn't
declare
a
dependency
on
w,
there's,
there's
nothing
else,
referencing
it
except
these
two
pure
depths,
which
are
for
two
different
versions
of
it.
In
that
case
the
rfc
states
that
we
will
still
crash
in
non-strict
mode
if
it's
a
nested
dependency
and
what
I
would
like
to
do
instead
is
say
you
know,
because
this
is
still
kind
of
the
case
where
I'm
I'm
not
in
a
position
to
fix
it.
A
It
should
just
take
the
first
one
that
it
placed
so
essentially
y
would
win
because
it's
you
know
willy-nilly
it's
earlier
in
the
alphabet.
So
that's
why,
and
I
think
I
think
that
actually
is
a
little
bit
more,
both
more
consistent
and
a
better
overall
user
experience
be
for
all
the
same
reasons
why
we
wanted
to
take
the
you
know
the
con,
the
version
of
why
that
x
specified.
We
also
want
to
take
the
version
of
w.
That
was
just
what
just
pick
one
of
them.
It's
fine
well.
E
I'm
really
afraid
that
could
lead
to
broken
installs
right
like
we
can.
We
can
successfully
install
the
install
tree,
but
then
the
application
would
just
not
run
right
because
one
of
the
dependencies
was
expecting
w
in
a
different
version
and
it's
just
not
compatible
right.
So
you
end
up
in
a
situation
where
okay
npm
install
succeeds,
but
still
like
your
app
is
not
really
usable
anymore.
A
In
that,
in
that
case,
it
would
have
been
even
less
it,
so
a
we're
not
making
things
worse
going
from
you
know,
yarn
or
pnpm
or
npm,
six
up
to
npm,
seven
like
it
hasn't
gotten
meaningfully
worse.
In
fact,
in
this
kind
of
a
case,
we
wouldn't
have
installed
w
at
all
right
so
that
the
whole
it
would
be
even
less
functional.
E
So
so
it
may
be.
So
that's
just
one
thing
I
would
float.
Maybe
it's
a
terrible
idea.
Maybe
someone
will
have
a
better
idea
than
this,
but
what?
If
we
just
do
this,
the
step
that
people
would
usually
do
in
this
case,
which
is
place
w
in
your
top
level
dependency
just
to
mark
what
you're
picking
up
right,
like
just
automate
that
so
so
that,
like
whatever
we
resolve
them,
because
or
whatever
like
y,
comes
first
in
alphabetical
order,
but
just
pick
that
w
and
put
it
as
a
top
level
dependency
just
to
mark
that?
E
Okay,
this
is
what
was
what
we
resolved
to
and
then
would
also
give
the
possibility,
like
to
the
user
not
only
bubble
up
to
the
final
user,
but
also
giving
them
the
possibility
to
tweak
it
right
and
select
a
different
version.
If
that
would
be
the
best
for
the
project
right
in
order
to
fix
the
their
application.
E
Oh,
maybe
maybe,
but
at
the
same
time
I
thought
we
were
always
like
preserving
the
topmost
destination
as
the
as
being
like
the.
A
A
C
A
Right,
well
I
mean
they
would
be
able
to
do
strict,
I'm
kind
of
I'm
kind
of
less
concerned
with,
I
guess,
maybe
I'm
kind
of
less
concerned
with
somebody
who's
like
using
a
bunch
of
react
modules
and
has
specified
a
version
of
react
that
doesn't
work
with
them.
Then
I
am
with
somebody
who's
like
just
building
a
website
with
gatsby
or
a
cly
with
ink,
and
you
know
buried
three
levels.
Deep.
A
There
is
a
conflicting
peered,
app
on
on
react
or
or
babel
or
whatever
else,
which
is
which
is
pretty
common
as
well
as
like.
I
just
I
just
want
to
use
this
typescript
thing.
It
has
a
pure
depth
on
a
thing
that
some
other
typescript
thing
I'm
using
doesn't
agree
with
like
shut
up
and
give
me
my
codes
right.
A
B
Of
time
here,
yeah,
I'm
not
sure
we
can
go
over.
Obviously,
we've
got
the
the
full
hour
block,
but
did
want
to
make
sure
that
we
stayed
on
point
and
tried
to
actually
surface
any.
You
know
clear
objections
to
to
the
current
like
way
this
is,
is
can
be
handled
so.
A
Yeah
kristen,
I
I
think
that's
a
good
idea
to
save
up
these
warnings
and
print
them
at
the
end
of
the
install
as
well.
We
had
we
had
talked
about
doing
that
with
some
other
things,
so
it's
kind
of
in
at
a
similar
priority
level
to
audit
output
as
it
currently
have
as
it
currently
is
implemented.
A
The
warning
gets
printed
very
early
in
the
process
before
all
the
you
know,
the
flood
of
deprecation
notices
and
it
certainly
does
get
somewhat
buried
as
a
result,
so
saving
them
up
and
printing
it
at
the
end
is
is
definitely
easily
done.
A
The
I
think,
there's
right,
you're
kind
of
touching
on
an
interesting
concern
here
that
I
think
needs
maybe
a
little
bit
more
like
testing
and
evaluation
and
we'll
certainly
see
more
as
people
are
using
it
more
widely,
which
is
the
the
difference
between
us
kind
of
getting
to
somewhat
of
jordan's
point
as
well
like
there
is
sort
of
a
functional
difference
between
you
know.
A
I
do
a
git
checkout
and
an
npm
install
with
just
like
whatever's
in
the
package,
lock
and
or
just
whatever
is
resolved
from
my
package
json
dependencies
versus
I'm
adding
a
new
dependency
to
the
tree,
and
I
don't
know
that
we've
captured
exactly
like
what
the
best
solution
is
to
that.
But
I
I
think
that
it
feels
like
there's
something
relevant.
There's
something
meaty
in
terms
of
like
that.
Just
the
difference
in
those
two
use
cases.
C
So
that,
actually,
that
does
suggest
a
less
magical
form
of
what
I
previously
suggested.
Npm
install
could,
but
with
no
arguments
could
continue
to
have
the
middle
ground
non-strict
thing
that
you've
been
talking
about.
But
then,
when
you
explicitly
attempt
to
install
like
npm
and
solfu,
could
we
make
that
pick
strict
or
non-strict
based
on
the
current
validity
of
the
tree,
meaning
if
it's
valid
it
adds
a
new
package
in
strict
mode
and
if
it's
not,
it
doesn't.
A
C
Yeah,
like
you,
can
have
something
like
like
yeah.
It
has
pure
depth
yeah
like
that,
would.
C
Would
still
that
would
still
achieve
what
I
want,
which
is
where,
once
your
graph
is
valid,
you
can't
easily
make
it
invalid.
A
Right
so
the
way
we
currently
do
package
editions,
if
you
do
npm
install
npm
install
foo,
we
basically
just
slap
that
onto
the
well.
So
we
resolve
that
to
figure
out
okay,
what
you
know,
what
version
will
it
actually
be?
And
what
is
the
name
of
the
thing?
But
then
we
just
basically
add
that
to
your
effective
package,
json
dependencies
and
proceed
with
attempting
to
resolve
the
tree
right
doing
the
whole
breadth.
First
search,
queuing
kind
of
thing.
A
So
it
might
be,
I'm
just
trying
I'm
just
trying
to
figure
out
I'm
just
kind
of
doodling
on
like
what
that
would
mean
for
like
if
we
had
a
different
level
of
strictness
based
on
whether
something
was
in
the
explicit
requests.
C
Well,
like,
presumably,
you
could
store
in
a
lock
file
the
validity
status
of
the
tree
right
like
would
it
have
failed
on
strict
or
not,
and
so,
if
there's
a
laptop
present-
and
I
do
npm
install
foo,
you
know
if
like
if
the
tree
was
valid,
then
you
can
just
implicitly
set
the
config
to
be
strict
and
move
forward,
and
if
you
know
it
wasn't,
then
you
just
move
forward
without
changing
anything.
The
I
don't
know
how
that
would
work.
A
You
actually
always
have
a
log
file:
okay,
a
little
hidden
secret,
there's
a
in
npm
seven
there's
a
node
module
dot
package
lock.json,
which
it's
not
quite,
it's
not
quite
the
same
as
a
lock
file.
It's
a
snapshot
of
the
latest
actual
thing.
A
Yeah
yeah-
and
we
just
you
know
if
any,
if
any
of
the
folders
referenced
by
any
of
the
packages
in
that
log
file
have
a
newer
m
time.
Then
we
just
say:
okay,
this.
This
is
this,
cache,
isn't
valid
and
throw
it
away,
but
that
lets
us
that
basically
lets
us
do
a
load
actual
in
you
know
under
50
milliseconds
versus
like
a
second
and
a
half
for
a
really
big
project.
So
it's
a
pretty
significant
performance,
improvement,
pnpm
and,
I
believe,
yarn
at
least
yarn
two.
I
don't
know
about
yarn.
A
One
do
something
very
similar.
A
Would
have
to
be
changed
so
the
the
change
I
intend
to
make
is
there
is.
There
is
one
one
edge
case
where
we're
in
non-strict
mode
and
it's
a
meta
dependency
that
conflicts.
A
We
should
still
let
this
let
the
install
proceed,
because
it's
not
yours,
it's
it's
somebody
else's
fault,
and
even
though
that
means
proceeding
with
something
that
we
have
no
reason
to
believe
is
any
better.
It's
just
it's
the
first
one
that
we
encountered
alphabetically,
and
so
we
just
take
something
like
we
would
in
force
mode.
The
the
other
things
I
think
are
are
actually
really
beyond
that.
A
Like
should
we
infer
strict
mode
when
adding
new
depths
or
should
we
capture
whether
or
not
there
were
warnings,
and
in
first
strick
note
if
last
time
there
were
no
warnings,
I
I
think
that
these
probably
rise
to
the
level
of
having
their
own
rfcs
and
feel
a
little
orthogonal
to
sort
of
like
what
do
we
do
the
just
the
basic
idea
of
like
what
do
we
do
in
strict
mode?
What
do
we
do
in
force
mode?
What
do
we
do
in
non-strict
mode
and
then
from
there
we
can
say
okay.
B
So,
like
you're,
saying
that
you
potentially
want
to
open
up
rfc's
for
those
specific
like
modes,
is
that
right,
like
for
for
jordan's.
C
A
Well,
you
know,
let's
ask
for
the
moon,
you
might
get
something
you
might
get
like
a
space
station
or
something
it
could
be.
I
think
it
could
be
a
reasonable
step
towards
that.
I
I,
I
also
think
we're
we're
probably
sort
of
at
the.
A
Where
we're
definitely
nearing
the
end
of
or
or
past
the
end
of,
where
we
can
add
new
breaking
changes,
arguably
even
doing
any
kind
of
strict
mode
or
non-strict
mode
is
kind
of
a
breaking
change.
So
it's
any
any.
Adjustments
to
this
does
adjust
kind
of
the
semantics
of
how
we
build
trees
and
that's
one
reason
why
I
want
to
get
it
out,
while
we're
kind
of
still
in
in
rc
territory,.
A
And
rfc
two,
but
I
think
on
day,
one
with
npm
7.
It
would
actually
be
really
helpful
if
we
said
the
plan
for
npm
8.
Is
you
know
one
of
these
two
options?
One
is
it's
strict
by
default
after
the
first
non-warning
install
option,
two
is
it's
strict
by
default,
always
and
then,
and
we
should
probably
have
an
rfc
for
for
whatever
we
we
end
up
going
with
right
and
we've
got
plenty
of
time
to
do
that,
but
yeah
it
is.
A
It
is
probably
a
breaking
change
and
I
would
love
for
pure
depths
to
be
to
have
always
been
strict,
but
the
question
is
kind
of
how
we
get
there.
A
I
mean
that
the
the
conflict
is
between
the
the
peer
depths.
The
conflict
is
between
two
one
or
more
peer
sets
which
are
dependencies
of
the
root
project
or
a
workspace
project.
A
Okay,
and
so,
if
it's
a,
if
it's
a
meta
dependency
of
the
root
project
or
metadependency
of
a
workspace,
then
we
just
kind
of
let
it
ride.
A
A
If
it
conflicts
with
something
that's
already
a
top
level
depth
and
you're,
adding
a
new
top
level
depth
that
conflicts,
then
it
will
crash.
So
it.
A
You
from
creating
new
new
peer
conflicts-
that
are
your
fault.
C
A
I
I
mean,
ironically
enough,
the
other
thing
about
this
is,
if
the
more
layers
of
nesting
that
there
are
right,
so
the
more
kind
of
non-peer
dependencies
are
exist
in
this
chain,
the
more
likely
it
is
that
we
can
find
a
satisfying
resolution,
but
it
could
have
the
unintended
side
effect
of
now.
There's
two
reacts
in
your
tree.
A
Yeah
so
I
mean,
I
think
we
could.
We
could
have
a
whole
other
kind
of
deep
dive
on
different
different
kind
of
cultural
mores
of
of
dependency
declaration
within
different
pure
depth
communities.
A
But
one
thing
that
seems
very
common
within
them
is
in
order
for
it
to
work
at
all.
It
has
to
become,
and
it
typically
does
become
very
widespread
for
everyone
to
declare
appeared
at
on
kind
of
the
central
thing.
That's
the
core.
B
A
A
The
in
some
other
peer-dep
communities,
I
think
in
I
believe
it
was,
I
want
to
say,
eslint
it's
and
maybe
also
in
battle.
A
It's
a
little
more.
It's
a
little
more
likely
that
either
a
peer
def
won't
be
declared
or
there'll
just
be
a
direct
dependency
on
something
that
has
a
pure
depth,
but
also
it's
a
little
bit
less
breaky
than
it
is
react
is
kind
of
the
worst,
the
worst
or
the
worst
in
terms
of
like
it
must
be
a
singleton
or
everything
falls
over.
C
C
B
So,
just
to
be
mindful
here
again
we're
human
like
teammates
over
what
we
want
to
be.
But
what's
like
the
next
steps
here.
A
I'm
going
to
update
the
rfc
to
to
make
these
changes
that
I
have
sitting
in
my
bin
buffer
right
now
to
be
basically
always
forced
when
it's
not
your
fault
and
always
strict
when
it
is
and
then
yeah
we
should.
We
should
do
another
another
rfc
to
figure
out
what's
going
on
or
what
we
hope
to
do
with
npm
eight,
and
I
think
that
would
actually
be
useful
to
do
now,
because
we
can
have
our
warnings
be
a
little
bit
more
forceful
and
say
like
this
will
break
with
npm
version.
E
A
Okay,
yeah
I've
been
I've
been
shying
away
from
using
like
I
sort
of
test
with
real
world
projects,
but
I've
been
shy
away
from
using
them
as
test
cases
specifically
in
our
test
suite
because
they're
they're
really
hard
to
pin
down
like
you
know,
and
isolate
a
particular
scenario
and
tend
to
have
like
many
many
many
dependencies
so
that
test
that
test
fixtures
folder
is
already
pretty
massive.
B
Was
there
any
other
comments
or
feedback
on
this?
I've
taken
a
bunch
of
notes
here
and
also
logged
down
like
the
next
steps
or
action
items
from
this
with
the
changes
isaac?
Would
we
then
also
consider
this
to
be
essentially
ratified
since
we're
basically
having
built
the
functionality?
At
the
same
time,.
A
B
Fast
and
furious
okay,
so
that's
another
thing
also
to
to
keep
mind
of
then
to
close
this
out
anything
else.
Any
any
other
comments
or
feedback
on
this
sounds
like
the
other.
To
do
here
is
to
open
up
another
rfc,
specifically
for
changing
the
default
strictness
mode.
Is
that
accurate?
Is
that.
A
B
Okay
cool!
Well,
I
appreciate
everybody
jumping
on
again
today
and
I
apologize.
We
didn't
have
more
of
an
agenda,
we're
all
gonna
get
back
to
typing
on
keyboards
and
we'll
be
back
at
it
next
week,
hopefully
with
a
larger,
larger
list
of
things
to
chat
about.
So
I
will
speak
with
you
all
in
slack
or
in
the
rfcs
themselves
and
hope
you
have
a
great
day
thanks.