►
From YouTube: Open RFC Meeting - Wednesday, September 15th 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live
on
youtube
thanks
everyone
for
joining
us
again
at
another
npm,
open,
rc
call.
Today's
date
is
september,
15
2021.
A
We
will
be
following
along
in
the
agenda
that
was
created
in
npm
rfc
issue
number
five
457,
I've
shared
the
meeting
note
stock
here
in
chat,
but
I'll
share.
It
again
feel
free
to
add
yourselves
as
attendees
or
to
the
attendees
list
in
that
hackam
deduct
and
I'll
be
taking
notes
as
we
go
along
here.
A
Quick
reminder
as
always
that
these
calls
and
all
comms
on
the
rfc's
repo
are
covered
under
the
bureau
of
code
of
conduct,
and
we
would
like
to
ensure
that
folks
stay
mindful
and
thoughtful
as
they're
speaking
and
listening,
and
please
raise
your
hand
if
somebody
else
is
speaking
and
I'll
call
upon
you
and
we'll
hopefully
have
good
discourse
throughout
these
conversations,
and
I
just
wanted
to
give
some
space
and
let
folks
potentially
share
any
announcements
that
they
may
have.
A
If
there's
no
announcements,
we
can
just
dive
into
the
agenda,
which
is
rather
small
today,
the
first
of
which
is
a
issue
number
454.
A
This
was
a
poll
that
I
started
I'll
share
the
reference
to
it
for
alternative
names
for
the
reification
proposal
by
vince
bailey
who's
on
the
call
here
had
a
conversation
with
him.
I
think
late
last
week
and
or
earlier
this
week,
just
to
clarify
you
know
what
the
intent
of
the
reification
strategy
is
and
and
maybe
better
names
that
we
could
choose
to
to
to
name
this.
A
There
seems
to
be
a
half
decent
number
of
folks
that
actually
voted,
and
so
far
it
seems
like
the
the
the
winner
of
at
least
the
poll
is,
is
isolated
in
terms
of
the
name
I
saw
isaac.
Also,
you
were
one
of
the
few
people
to
actually
comment
on
this
and
we
had
talked
about
it
a
bit.
Did
you
want
to
maybe
share
why
you
chose
this.
B
Yeah,
so
the
main
reason
is
just:
I
think
that
the
term
isolated
sort
of
describes
the
effect
that's
visible
to
a
user
who's
using
that
feature
which
I
think
was
kind
of
the
goal
of
calling
it
pure
mode
to
begin
with,
whereas
if
we
call
it
unhoisted
or
sim
linked
or
pnpm
style,
it
sort
of
is
is
very
tied
to
the
implementation,
and
we
may
I
mean
once
node
supports
import
maps
like
we
may.
B
A
A
Yeah
I
like
that.
Okay,
I
I
think,
then
we
can
probably
close
the
poll
in
that
issue
and
I'll
take
the
onus
to
close
that
out.
I'll.
Just
take
a
note
here,.
A
And
then,
if
you
can
yeah
update
the
relevant
pieces
of
the
rfc
would
be
great
vincent.
A
A
Awesome
so,
following
along
on
that
thread,
we
have
the
actual
reification
mode,
pr,
that's
open.
So
this
is
436.
and
vincent.
A
I'm
not
sure
if
you
can
share
maybe
a
little
bit
about
the
the
changes
or
updates
that
you've
made
based
on
the
comments
that
have
come
in,
but
I
don't
know
if
there's
been
any
action
or
any
new
comments,
I
see
a
couple
new
pieces
of
feedback,
I
guess
from
jordan
within
the
last
hour
or
so,
but
maybe
you
could
speak
to
a
little
bit
about
any
updates.
You've
made.
D
Yeah,
so
I'll
share
the
updates
since
two
weeks
ago,
since
last
meeting
and
then
we'll
we'll
discuss
some
of
the
unresolved
discussions
that
are
still
open.
So
what
I've
made
based
on
the
discussions
both
on
the
rfc
and
on
the
call,
was,
I
kind
of
reformulated
the
motivation
and
to
to
kind
of
hopefully
be
less
confusing
about
using
the
word
sharing
and
the
word
deduplicating
in
some
ways
that
were
confusing
before
so
also
clarify
that
this
mode
will
be
available
for
everyone.
D
So
so
there
is
that
reward
we
discussed
two
weeks
ago
that
actually
the
log
file
format
or
the
log
file
itself
will
not
change.
It
will
be
exactly
the
same
log
file,
regardless
which
mode
you
use,
which,
which
is
good
for
compatibility,
because
you
me
it
means
you
can
have
you
have
two
different
version
way
to
install
the
same
ripple
without
changing
any
any
file
in
that
ripple.
D
So
that
means
you
know
you.
Your
repo
is
compared
to
an
older
version
of
npm,
simply
like
maybe
you,
you
may
have
some
changes
that
build
locally
and
fail
on
ci,
but
you
will
be
able
to
to
develop
locally
and
that
also
allow
to
like
locally
and
on
ci
to
have
a
strict
environment,
our
isolated
environment.
But
when
you
develop
to
prod,
if
your
product
environment
doesn't
support
simulink,
then
you
can
use
hoisting
mode
in
in
prod.
Like
I
know,
amazon
doesn't
at
the
moment,
support
simulink.
D
So
you
could,
you
know,
develop
all
in
in
isolating
mode
and
deploying
hoisted,
and
you
have
the
kind
of
the
guarantee
that
if
it
works
in
isolated
it
will
work
in
a
hosted
as
well.
So
I
updated
this
in
the
rfc
and
concerning
the
the
what
was
the
last
bullet.
D
Yeah,
so
concerning
the
compatibility
with
the
ecosystem,
I
think
there's
still
an
open
question
here
and
that's
that's.
That's
one
of
the
unresolved
discussions
so
we'll
talk
about
it
then.
D
Oh
yeah,
the
other.
No,
the
other
update
is
like
the
configuration
I
I
was
wondering
whether
we
should
how
to
configure
that
mode,
whether
it
should
be
like
per
per
workpix
or
I
should
be
in
the
config
files,
or
I
should
be
in
the
cli
option
or
whether
we
should
force
that
option
for
a
repo
or
let
the
developer
choose
which
strategy.
So
I
think
we
it
will
be.
It
will
not
be
enforced,
so
you
know
repos
will
be
compatible.
D
The
repos
that
will
be
compatible
with
hoist
with
isolated
will
also
be
compatible
with
hoisted.
So
there
is
nothing
forcing
people
to
to
isolate
it
in
order
to
be
able
to
build
and
run
the
ripple.
D
So
therefore
it
maybe
it
will
be
in
the
in
the
npm
rc
file
as
like
the
preferred
mode
for
this
repo,
but
it
could
be
overwritten
by
by
the
cli
option,
either
way,
so
that.
A
E
A
I
see
your
hand
up
vincent
sorry,
just
to
clarify
that
last
note
was
that
you're
saying
how
you
cannot
opt
into
this
is
through
npm,
rc,
config
or
bypassing
like
this
config
option.
But
they're
you're
trying
to
I
guess,
clarify
that
there
should
be
interoperability
between
these
two
modes
right
and
that
you
know
it
should
still.
A
You
should
still
be
able
to
install
a
project
that
would
have
been
built,
or
I
say,
built
but
reified
with
isolated
mode
or
what
we're
calling
isolate
mode,
but
also
be
able
to
do
it
with
the
default
strategy
that
we
have
today,
which
is,
let's
say
hoisted
mode,
and
that.
D
So
I
propose
we
will
just
use
junctions
because
I
there
is
no
major
issues
with
junctions,
so
we
could
use
junctions
for
now
and
if
there
is
a
need
coming
to
use
sim
links
instead,
we
can
always
add
this
as
as
an
opt-in
later
on.
D
So
that
was
the
two,
the
the
updates
I
had
since
two
weeks
ago,
and
I
think
we
could.
We
could
go
back
to
the
three
unresolved
discussions
and
they
are
all
involving
jordan.
So
I
think
we
can
let
him
speak
to
them.
F
Sorry,
kinda,
okay,
so
I
essentially
I
have.
I
have
like
a
broader
philosophical
concern
that
has
some
concrete
things
I'll
get
to
in
a
second
isolated
mode
or
whatever
you
want
to
call
it.
Imposing
that
constraint
on
yourself
on
your
own
code
is
completely
reasonable.
That's
already
what
most
people,
what
even
I
do
with
linter
plug
like
with
the
eslint
plug-in
import
and
so
on.
You
can't
require
or
import
anything
in
in
first
party
code
in
repos.
F
I
maintain
that,
isn't
that
isn't
listed
in
package.json
and
I
think
that's
a
good
practice.
The
fact
that
it's
a
good
practice,
though,
does
not
mean
that
it
should
be
like
forced
on
third-party
code,
in
other
words,
it's
great
that
people
can
switch
back
and
forth
between
the
revocation
styles.
But
if
I'm
working
at
a
company,
the
infra
team
puts
set
up
the
npmrc
to
do
isolated
mode
and
I'm
a
regular
engineer-
and
I'm
I'm
not
thinking
about
that-
I
don't
know
it
even
exists.
F
It
just
quietly
does
that
for
me
and
all
of
a
sudden
I
get
some
warning
because
a
third
party
package
isn't
you
know,
matching
this
philosophy,
and
you
know
that's
not
actionable
for
me.
So
what
I'm
gonna
do
is
go
file
an
issue
and
create
noise
and
effort
and
and
lead
to
burnout
for
a
maintainer
somewhere
in
the
ecosystem,
or
it's
going
to
essentially
disadvantage
that
package,
because
I'm
just
going
to
quietly
go
use
a
different
one.
F
F
So
that's
the
first,
the
broader
philosophical
concern
and
then
the
concrete
reasons
that
this
comes
into
play.
Eslint
itself,
which
could
be
in
the
graph
and
not
globally
installed,
requires
things
that
aren't
listed
in
eslint's
package
json
constantly.
That
is
how
plugins
work
babel
does
the
same,
with
plugins
and
presets
literally.
Every
tool
that
takes
configuration
from
the
user's
project,
but
in
order
to
do
plugins
will
do
requires
of
things
that
aren't
in
its
own
package
json.
F
If
isolated
mode
doesn't
interfere
with
this,
then
great,
but
then
how
isolated
is
it
for
third-party
code?
So
I'm
and
that's
where
I'm
unclear
there
have
been
bugs
filed
on
eslint,
plug-in
import
about
this
and
I
think
they're
fixed.
But
I
don't
really
know
because
it's
the
people
reporting
it
aren't
providing
clear
repros
and
I
don't
use
pnpm
or
yarn
pnp,
and
so
I
you
know-
and
I
don't
have
a
repo
set
up
to
use
it.
F
So
I
it's
just
I
I
don't
know
how
to
fix
it
or
even
debug
it
and
really
like
the
yeah.
So
so
I
think
that's.
Some
of
the
concrete
examples
is
essentially
anything
with
a
plug-in
system
is
likely
to
be
to
be
requiring
things
that
aren't
as
package.json.
So
I
think
that
if
we
were
able
to
restrict
it
to
just
first-party
code,
then
we'd
be
able
to
match
the
ethos
in
a
way
that
is
solely
actionable
by
the
user
right
and
then,
as
isaac
pointed
out
the
if
it's.
F
F
It's
not
a
there's,
not
a
a
universal
thing,
with
consensus
here
that
there
is
a
moral
issue
and
that
those
packages
are
bad
and
shameful
and,
like
those
should
be
discouraged
and
lacking
that
consensus,
I
think
it's
inappropriate
for
npm
to
be
artificially
screwing
over
those
packages.
A
Name:
okay,
I
think
just
I'll
I'll
start
just
by
maybe
like
giving
my
a
little,
my
own
two
cents
on
like
the
fact
that
this
is
opt
in
ideally
we're
not
changing
the
default
behavior
of
npm,
so
hopefully
we're
not
not
making
a
very
strong
opinion
about,
like
which
mode
you
should
be
using.
I
definitely
feel
and
share
your
concerns
about,
like
you
know,
creating
a
situation
for
end
users
that
don't
have
anything
actual
that
they
can
do
about
a
warning
or
about
an
error
that
they
receive.
A
That
is
definitely
a
really
good,
highlight
and
good
call
out
jordan,
but
yeah
like
I
think
that
the
way
that
we're
presenting
this
is
is
sort
of
an
opt-in
and-
and
there
are
many
classes
of
there's
many
types
of
packages
in
the
ecosystem
today
that
are
being
left
out
of
or
not
available
to
certain
consumers.
Just
based
on
you
know,
they're,
you
know
can't
be
built
on
certain
systems.
They
are
reliant
on
certain.
You
know,
I
think,
there's
a
whole
new.
F
There
is,
and
I'm
not
saying,
npm
has
a
duty
to
include
every
possible
thing.
People
can
come
up
with
I'm
saying
that
the
things
that
work
and
that
have
worked
in
the
ecosystem
for
decades
should
continue
to
like
work
unless
they
are
somehow
like
morally
bad,
and
I
think
that
it
being
opt-in
does
not
wipe
away
that
problem.
F
It
definitely
is
like,
obviously
for
like
it's
way
less
of
a
problem
than
if
it
were
to
become
the
default
right.
That's
that
would
be
a
completely
different
tone
of
discussion,
but
even
opt-in
people
are
going
to
try
it
for
fun
and
then
complain
to
maintainers
or
change
their
dependencies.
F
People
are
going
to
use
it
without
knowing,
because
someone
more
experienced
on
the
repo
is
going
to
put
it
in
npmrc
and
commit
it
and
then
the
same
effect
happens
and
people
are
going
to
want
to
use
it
because
it's
new
and
shiny
and
they
think
it's
better
in
in
and
they
might
be
wrong
about
why
they
think
it's
better,
but
they
think
it's
better,
so
they're
going
to
use
it
right
so
like
I
just.
I
think
opt-in
is
not
sufficient
to
be
like.
Therefore,
it's
fine
go
ahead.
Isaac.
B
Given
the
relative
popularity
of
yarn,
pnpm
or
yarn
pnp
and
of
pnpm,
I
think
it's
more
likely
that
it's
going
to
disadvantage
this
feature
rather
than
disadvantage
individual
packages.
What
people
are
going
to
find
is
they'll
they'll,
try
it.
It
won't
work
because
they
have
eslint
and
a
plug-in
and
then
they're
gonna
go.
Oh,
I
guess
isolate.
I
guess
isolated
vote
is
is
broken.
I'm
not
gonna
use
it
and
that's
also
a
bad
outcome
like
I
I'm
not
saying
that
that
makes
it
fine.
B
I'm
saying
that
that
is
totally
worth
bringing
up
as
a
concern.
I'm
less
concerned
about
you
know,
features
about
disadvantaging
packages
than
I
am
about.
You
know
spending
all
this
time
and
effort
to
build
a
feature
that
has
some
benefits,
but
most
of
our
users
can't
use
it.
For
this
reason,
like
that
seems
to
me,
like
totally
a
valid
thing,
to
work
around
there's
now,
there's
I'm
just
kind
of
bringing
this
back
to
practicality.
B
I
think,
from
a
from
a
cli
design
point
of
view,
like
yeah
you're,
probably
right
some
some
way
to
say
look.
I
want
to
isolate
my
code.
I
want
to
make
sure
that
I'm
not
the
one
making
the
mistake
having
the
shadow
dependencies,
but
also
I
want
everything
in
my
tree
to
work.
Pmpm
actually
has
a
mode
like
this
for
exactly
that
reason,
because
otherwise
they
couldn't
get
people
to
use
pnpm
right.
So
it's
it's.
It's
totally
worth
doing,
and
I
think
it's
something
that's
going
to
be.
B
If
we
don't,
you
know,
if
we
don't
build
that
on
day,
one,
it's
going
to
be
probably
the
first
thing
that
anybody
using
this
feature
wants
there.
There
is
also
some
value,
especially
in
the
kinds
of
use,
cases
that
that
led
to
this,
where,
where
vince
was
coming
from,
where
you
have
a
giant
monolithic
project,
and
actually
you
want
to
make
sure
that
you're
not
doing
it
not
using
any
dependencies
that
have
shadow
depths.
B
F
B
F
F
F
I,
I
pnp
asked
like
mile
asked
me
to
make
changes
in
resolve
solely
so
that
pnp
could
run
time
hack
them
in
to
work
around
these
problems,
and
I
assume
mile
asked
many
packages
in
the
ecosystem
for
similar
workarounds,
and
I
assume
that
pnpm
is
probably
doing
similar
things
to
try
and
hide
the
fact
that
things
are
broken
so
much
from
their
own
users
and
I'm
not
trying
to
make
a
value
judgment
on
that.
I'm
just
saying
like
that
that
it's
possible
that
we're
underestimating
the
actual
breakage
because
of
these
kinds
of
cover-ups,
essentially.
B
Yeah,
so
I
I
think
my
my
point
is,
I
think,
there's
value
in
a
super
strict,
all
the
way
down
mode.
We
have
that
for
pure
depth,
for
example,
you
can't
use
almost
any
like
any
package.
Any
ecosystem
like
if
you
use
something
that
uses
react
and
you
have
strict
beard,
apps
enabled
I
I
can
almost
guarantee
that
it's
past,
like
a
trivial
level
of
complexity,
it's
going
to
break
and
that's
why
we
don't
have
that
on
by
default.
B
But
it's
it's
valuable
if
you
know
that
there
shouldn't
be
any
conflicts
or
if
you
really
want
to
surface
those
conflicts,
to
be
able
to
kind
of
run
in
that
mode
and
see
see
what
breaks,
and
I
I
think
that
there's
some
value
in
a
a
super
super
strict,
isolated
mode
where
everything
is
isolated.
All
the
way
down
the
tree,
even
though
there's
a
large
number
of
projects
where
that
will
never
work
for
them,
there's
higher
value
in
an
an
isolated
mode
which
isolates
your
dependencies
kind
of
from
each
other.
B
But
if
they're
using
shadow
depths
of
their
dependencies
kind
of
past
that
first
level
in
the
dependency
graph,
then
that's
totally
fine
and
then
there's
this
comes
assuming
in
the
fullness
of
time.
We
want
to
do
both
modes
right.
We
want,
like
you,
know,
isolated
equals,
strict
and
isolated
equals.
Just
me
that
kind
of
brings
up
the
question
of
how
we
go
about
implementing
it.
So
I
think,
having
this
rfc
to
kind
of
define
what
is
the
the
strict
isolated
mode
totally
fine?
We
can.
B
We
can
implement
that
and
then
see
how
to
tweak
it
in
order
to
enable
shadow
depths
within
nested
within
transitive
dependencies
or
we
can.
You
know,
build
that
into
the
design
from
the
start.
I
I'm
not.
I
don't
really
have
any
strong
opinions
about
that
or
or-
and
we
can
also
ship
them
separately
right.
We
can
ship
the
superstretch.
B
F
Where
I
was
gonna
bring
up,
I
don't
have
any
opinions
about
the
order
of
implementation
or
design.
I
I
think,
though,
that
anything
anything
that,
like
this
comes
up
in
node,
occasionally
anything
that
has
ecosystem
level
impacts
that
where,
where
things
will
ripple
out
to
maintainers,
I
think
we
have
to
be
very
careful
about
releasing
it
and
if
we
release
the
full
tree
isolated
mode
and
do
not
include
the
just
me
isolated
mode,
then
like
I.
F
What
I
worry
is
that
people
will
rush
to
try
the
full
tree
one
and
the
the
zeitgeist
will
not
learn
about
the
work,
the
the
nice
middle
ground
of
just
isolate
my
own
stuff,
and
it
will
end
up
harming
maintainers.
That's
what
I'm
concerned
about
here,
so
I
would
prefer
to
ship
either
just
be
myself
mode
or
both
and
not
to
just
ship
the
full
tree
mode,
and
this,
of
course,
is
all
assuming
it's
plausible
to
implement
it,
which
I
have
no
idea.
A
So
I
I
think
the
the
tough
part
is
definitely
changing
like
inside
the
ecosystem,
getting
a
lot
of
folks
to
adopt
this
over,
like
that
takes
a
long
period
of
time.
If
we're
talking
about
like
you
know
that
we're
talking
to
jordan,
which
is
a
hypothetical
field
that
you
know,
exists
in
the
package
jason.
A
I
think
that
that
takes
a
lot
more
time
versus
like
what
folks
would
like
to
see
today,
which
is,
is
locking
this
down
and
sort
of
opting
into
this
mode
and
then
cleaning
up
their
projects
or
starting
net
new
projects.
With
this
mode
in
mind,
I
would
love
jonathan.
I
know
you
you
just
joined,
but
you've
been
putting
some
good
comments.
I
think
in
in
the
chat.
Did
you
want
to
at
least
speak
to
and
also
introduce
yourself,
maybe
yeah
yeah.
G
So
I'm
jonathan
creamer,
I
work
with
vincent's
at
microsoft
and
I'm
helping
implement
midgard
yarn
strict
in
the
big
mono
repo
we've
got
about
a
thousand
packages
in
there,
so
I've
been.
I
took
actually
some
of
his
the
mega
yard,
strict
work
from
his
refills
and
put
it
in
directly
in
our
mono
repo.
So
we
can
iterate
out
really
quickly,
so
I've
been
experimenting
with
that.
A
lot
yeah
I
was
just
gonna
say
to
me
like
it
just
seems
like
you
always
should
declare
your
stuff
in
a
package
json.
G
I
don't
know
why.
That
would
be
like
a
jarring
change
for
a
package
owner.
I've
actually
identified
at
least
three
different
github
repos,
including
some
of
our
own
microsoft
ones,
where
we
forgot
to
declare
something
in
the
package.json
json
and
it
broke.
When
I
ran
mid
guard
yarn
tricked
because,
like
mcgregor
and
strict
will,
you
know
not
work.
If
you
forgot
to
declare
something,
and
so
I've
actually
been
able
to
submit
prs
or
help
three
different
package
owners
by
you
know
making
sure
that
they
have
this
stuff
declared.
G
I
don't
I'm
trying
to
understand
the
eslint
and
babel
plug-in
example.
From
my
understanding,
like
yeah,
those
will
be
required
automatically,
but
if
they're
not
declared
in
some
package
json
somewhere,
that
thing
will
break
you
have
to
have
them
cleared.
B
Somewhere
they're
declared
at
the
root,
but
not
within
the
thing,
that's
requiring
them.
So
I
tell
eslints,
I
give
eslint
a
string,
and
I
say
this
is
my
plugin
and
then
at
some
point
later,
eslint
requires
that
string
and
expects
it
to
be
in
the
tree.
So
it's
it's
a
top
level
dependency,
but
it's
not
an
esl
dependency.
If
eslint
is
isolated
from
those
and
can't
require
other
kind
of
peers
within
the
depth
graph,
then
it's
not
going
to
work
well.
G
D
So
these
are
like
global
for
your
ripple,
so
everything
you
have
at
the
top
level
will
be
requirable
by
any
packages
installed
in
your
ripple.
If
you're.
G
F
Okay,
so
I
have
three
responses
to
that.
That's
interesting,
so,
first
jonathan,
I
was
saying:
detecting
bugs
in
packages
that
are
is
something
that
sounds
great
and
that
maintainers
will
of
course
want
to
just
fix.
Like
oops,
I
forgot
no
big
deal.
That's
that's
not
something!
I'm
concerned
with
I'm
concerned
about
not
having
workarounds
for
the
valid
use
cases.
F
Now,
if
a
dependency
can
require
anything,
that's
in
the
top
level.
Isn't
that
going
to
prevent
discovery
of
those
exact
same
bugs?
If
I
depend
on
lodash,
then
I
could
depend
on
a
thousand
things
that
forgot
to
depend
on
it,
but
require
it
and
it'll
just
work.
So
how
what's
the?
How
is
this
actually
isolated?.
D
D
And
and
the
the
we
are
in
like
we're
discussing
all
or
nothing
like
when
you
put
one
dependency
in
your
root
you're,
declaring
that
this
dependency
is
global,
is
accessible
by
everyone,
but
all
the
others
are
isolated.
You're,
not
you're,
not
excluding
all
the
strictness
you
can
get
just
because
one
packages
doesn't
work
with
it.
D
So
so
I
guess
that's
the
difference
between
you
know,
hoisting,
everything
or
just
manually
deciding
to
kind
of
hoist,
because
that's
essentially
what
you're
doing
when
you
take
a
dependency
to
to
a
package
in
the
route
you're,
basically
forcing
the
hosting
of
it
yeah.
G
So
yeah,
if
you
put
it
in
the
root
you're
like
intentionally
saying
I
I
realize
what
I'm
doing
right
now
versus
it
accidentally
happening
like
you're,
saying
it's:
okay,
I'm
aware
that
this
is
going
in
the
top
level.
I
put
it
there
intentionally
on
purpose,
because
I
actually
want
this
thing
to
be
able
to
be
shared
across
which
is
different
than
like,
putting
it
in
some
other
package
and
having
it
accidentally
hoisting,
and
you
not
realizing
that
it
got
wasted.
F
So
so
what
this
means
is,
if
I
get
an
issue
on
my
package
saying
I
tried
isolated
mode
and
some
broke
and
it
points
at
you
like.
I
can
either
fix
it
by
adding
it
to
my
package.json,
of
course,
but
if
there's
valid
reasons
why
I
shouldn't
my
response
should
be
put
it
in
the
root
of
your
package,
depths
or
dev
depths
as
appropriate,
and
your
problems
are
over.
D
Yeah,
so
pnpm
has
two
workarounds
or
three
actually,
so
this
is,
there
are
documented.
This
is
the
number
one
I
work
around.
The
second
one
is
through
a
config
file.
You
can
actually
declare
dependency
on
behave
on
behalf
of
external
packages.
We
discuss
whether
we
want
like.
D
Yeah,
you
can
say
well
I
I
want.
I
want
my
bubble
package
to
be
able
to
have
access
to.
I
don't
know
whatever
plugin,
so
you
you
can
do
that
through
a
config
file
and
we,
you
know
we
discussed
to
implement
this
in
in
npm
with
isolating
mode
and
we
decided
to.
D
Not
implement
it
at
the
first
iteration,
maybe
later,
if,
if
the
first
work
around,
this
is
not
enough
or
based
on
the
feedback,
and
then
the
this.
The
third
work
around
is
like
a
programmatic,
programmatical
api
to
add
some
hooks,
and
that's
I
I
don't
know
too
much
about
that.
One.
F
D
Yeah,
so
pnp
has
a
list
of
known
breaking
packages
and
a
list
of
how
they
are
fixed,
so
they
are
like
automatically
fixed
this
one
that
I.
D
Yeah,
okay,
so
if,
if
you
install,
you
know
a
dependency
that
that
is
not
fixed
by
the
maintainer,
the
you
know
they
they're
automatically
yarn
will
by
default,
adds
that
missing
dependency.
So
there's
that
too,
all
right.
F
Well,
I
I
mean
I
appreciate
knowing
this
this,
I
think,
mitigates
a
number
of
my
concerns
right,
given
that
that,
as
a
maintainer,
my
my
my
aunt,
my
easy
answer
is
either
I'll.
Add
it
or
you
add
it
that
that
calms
me
down
a
lot
about
this,
so
thank
you
for
explaining
that
it
still
kind
of
feels
like
it
defeats
the
philosophical
goal.
F
You
know,
because
things
aren't
actually
isolated,
they're
only
isolated
from
other
siblings
right,
but
they
can
still
hijack
whatever
they
need
from
the
application
and
in
a
sufficiently
large
application.
That
is
a
large
list
of
of
undeclared
dependencies
it
could
get
at,
but
you
know.
G
D
One
thing
is
the
in
the
root:
typically
in
big
repos
you're,
not
you
don't
have
too
much
dependency
on
the
root
level.
Like
the
difference,
you
are
in
your
packages
in
your
workspaces
in
the
root
you
may
have
basic.
F
D
Contexts
you
will
have
just
you
know,
prettier
a
few,
a
few
of
these
dependencies
that
needs
to
be
in
the
route
to
be
run
by
your
git
hooks
or
a
husky,
or
this
kind
of
things,
but
like
typically
bubble
will
not
need
to
be
in
the
roots.
So
you
will
have
it
in
only
if
you
want
to
declare
it
globally,
so
isaac,
a
serious
hands.
A
B
B
Actually,
then
you're,
like
the
bulk
of
your
project,
is
in
dependencies
right
because
that's
what
a
workspace
is
it's
it's
linked
as
like,
a
like
a
file
dependency,
and
so
the
the
isolation
of
each
workspace
starts
to
become
really
important
and
in
a
large
project
where
most
of
what
you're
using
are
workspaces,
and
you
have
a
lot
of
workspaces
and
they
interdepend
on
one
another
to
a
high
degree.
B
Then
it
will
actually
prevent
an
awful
lot
of
of
bugs
from
getting
out,
and
you
know
for
the
for
the
cases
where
you
have
just
like
a
handful
of
dev
tools
that
need
to
do
plug-ins
and
fancy
stuff
like
that
goes
in
the
route
and
it's
fine
but
yeah,
I
think,
there's
there
is
definitely
a
a
class
of
large
apps
which
are
a
single
package
effectively
a
single
package
json,
not
using
workspaces
or
only
using
workspaces
for
kind
of
small,
isolated
parts
of
the
application,
and
that
is
a
little
bit
yeah
it.
B
A
We
can
rename
it
so,
like
I
said
I
I
jokingly
said
we
could
go
back
to
the
poll.
If
that's
if
this
would
help
also
like
mitigate
confusion.
A
F
I
F
Reiterate
just
to
make
sure
the
work
around
here
would
be
to
put
it
in
a
child
workspaces
package
json,
so
that
that
child
workspace
like
then
that
becomes
global
to
the
child
workspace,
but
not
to
the
siblings.
F
F
A
E
In
every
single
child
like
say
you
have
yes,
lin
did
you?
Have
you
have
a
single
plug-in
that
you
want
in
all
of
them?
Can
you
put
that
in
the
root
workspace
terms,
the
root
package
jason
rather
than
the
child
package,
jason.
D
B
How
is
that
like?
What
do
we
do
with
that?
D
C
D
Mind
that
you
know
only
the
workspaces
that
are
listed
as
dependency
of
the
root
who
will
be
host,
it
will
be
linked,
but
you
know
yarn
is
automatically
linking
all
the
workspaces
to
the
root
you
mean
like
in
the
root
there
will
be
a
sim
link
in
the
non-module
folder
to
every
workspaces
is.
Is
this
what
you're
asking.
B
D
Yeah
we
can
decide,
I
don't
have
a
strong
opinion.
There.
G
I
think,
as
of
right
now,
they're
they're
linked
from
the
node
modules
directories
to
each
other,
there's
no
like
like
in
the
current
yarn,
workspaces,
implementation
and
npm
workplaces,
there's
like
a
node
module
at
scope
or
whatever
that
has
all
of
them
in
one
place
and
they
get
sim
linked
to
each
other,
and
I
think
in
the
ideal
state
not
not
to
like
a
global
root
thing.
I
think
that's
what
you're
asking
magic.
B
Right
so
right
now
effectively
when
you,
when
you
have
a
workspace
declared
when
we,
when
we
load
that
in
the
arborist
data
structure,
we
we
only
have
one
edge
one
edge
out
representing
a
dependency.
B
If
it's
a
workspace,
that's
an
edge
of
type
work
type,
equals
workspace
and
that
workspace
edge
will
clobber
any
dab,
depth
or
other
kind
of
depth.
So
we're
gonna
have
to
definitely
that
that
could
lead
us
into
some
some
knots
to
comb
through
in
that,
in
that
data
structure,.
E
So
the
inverse
of
the
question
I
had
earlier,
if
I
have
a
dependency
in
my
root,
and
I
want
to
solve
it
separately
for
two
different
child
workspaces,
can
I
do
that?
Will
that
be
like?
Well,
if,
okay
so
say
like?
Yes,
I
have
a
plug-in
well
now
say
like
I'm,
requiring
typescript
and
typescript
missed
a
module
in
their
package
json.
I
want
to
require
two
versions
ago
and
one
version
to
go
into
different
workspaces.
E
Is
that
something
that
I
can
do
as
well
so
like
in
the
child?
Can
I
resolve
it
by
installing
it
in
the
child
package
jason?
Despite
the
the
thing
it's
being,
the
the
thing
that
the
child
is
getting
it
from
is
the
global
rather
than
itself.
D
So
yeah
you
can
do
this,
but
this
won't
like
it
won't
be
a
workaround
for
the
configuration
issue
where
you
have
a
string
in
your
in
your
config
file.
There
is
only
one
global
scope,
so
you
cannot
have
a
like
a
second
level
global
scope,
which
is
at
your
workspace
level,
but.
D
B
So
so
hold
on,
if
you,
if
you
have,
if
I
have
eslint
and
an
eslint
plug-in
defined
in
the
dependencies
of
a
workspace,
then
that
eslint
plugin
will
be
linked
to
the
workspaces
node
modules.
Folder.
A
For
folks
who
haven't
seen
it,
I
showed
the
rendered
rfc
and
I
think,
there's
some
examples
of
the
current
strategy,
the
and
how
things
would
lay
out
on
disk
that
vincent
put
together.
A
It
sounds
like
maybe
they
we
could
add
more
examples
for
some
of
these
other
use
cases.
Is
that
what
I'm
hearing.
A
In
terms
of
jordan,
like
any
because
you
start
this
off
one
way,
I
feel
like
we've
massaged
the
conversation
a
little
bit
and
we're
the
hope
is
that
we're
gonna
start
to
potentially
work
on
on
this
feature
very
soon.
F
My
my
preference
would
be
that,
while
this
feature
is
built,
it
is
the
the
possibility
of
now
or
later
building
a
only
first
party
isolation
mode
version
of
it
like
the
just
for
me
not
for
you
kind
of
thing
is
like
kept
in
the
minds
of
those
building
it,
and
maybe
we
could
ship
both
of
them
at
the
same
time,
and
if
not,
then
maybe
you
know
the
the
code
base
won't
be
boxed
into
a
corner
when
next
you
know
next
month,
someone
comes
along
to
try
and
build
the
more
encapsulated
form.
F
I
think
the
the
workaround
is
good
and
simple
and
addresses
many
of
my
concerns.
I
still
expect
to
get
a
bunch
of
noisy
issues,
but
now
I
have
a
quick
one-liner
that
I
can
use
to
respond
to
them,
which
is
a
big
part
of
the
battle
of
getting
all.
Those
issues
is
knowing
what
to
say
without
pissing
people
off.
So
I
think
my
urgency
is
is
is
addressed.
F
I
think
I
would
just
be
much
happier
if
both
of
those
modes
switched
because
then
my
response
would
be
like
either
use
this
workaround
or
stop.
Trying
to
you
know,
stop
caring
about
things
that
aren't
your
own
code.
Just
like
when
someone
tries
to
lint
node
modules.
I
tell
them.
Don't
don't
do
that?
That's
not
yours
right!
I
would
prefer
to
tell
to
tell
them
the
same
thing
here,
but
you
know
I.
B
B
I
I
think
we
really
need
to
get
a
little
bit
of
play,
testing
to
sort
out
a
lot
of
that
stuff,
we're
doing
a
lot
of
like
hypothesizing,
and
that's
good,
that's
like
what
this
call
is
for,
but
also
I
I
think
we're
sort
of
at
the
limits
of
like
what
we
can.
B
What
we
can
confidently
say
about
the
pros
and
cons
of
this
right
like
we
have
microsoft,
has
a
use
case
that
is
going
to
benefit
from
it
from
performance
as
well
as
a
correctness
point
of
view.
That's
for
me,
that's
enough
to
just
do
it
and
then,
let's,
let's
see
how
it
goes.
I
I
I
wouldn't
be
surprised
if
you're
100
right
and
it
causes
a
bunch
of
noisy
issues,
but
we
do
have
some
easy
workarounds.
At
least
we
can
mark
it
as
experimental.
B
B
F
Is
an
experimental
mode?
That's
all
fine,
but
you
npm
is
microsoft
so
like.
I
would
hope
that
myself
think
you
know
my
own
entity.
That
has
a
use
case.
Therefore
we're
just
gonna.
Do
it:
it's
not
the
sole
motivation
for
doing
things,
but
obviously
I'm
not
describing
bad
faith,
and
in
this
case
I
think
it's
fine.
B
No,
I
I
think
it
is,
I
think
it
is.
I
think
it
is
representative
of
the
challenges
that
we've
heard
about
from
other
folks,
using
you
know
using
large
projects
with
a
lot
of
a
lot
of
deep,
a
lot
of
duplication
and
a
lot
of
shadow
depths.
I
mean
that's,
that's
really
the
ideal
use
case
for
pnp
sure
m.
G
G
A
Yeah,
I
think,
to
that
point
jordan,
like
what
we're
trying
to
do
with
this
form
before
even
that
acquisition
was
to
pull
in
the
best
ideas
from
the
ecosystem,
from
what
tools
we're
seeing
in
the
community,
bring
them
back
in
and
then
also
discuss
how
they're
going
to
be
built
right
like
that's
why
this
is
an
open
call,
not.
F
A
Live
on
youtube
for
folks,
folks
that
are
watching
you
can
join
us
every
wednesday
cool,
I'm,
I'm
hoping,
then
that
we
can
potentially
make
the
the
few
small
changes,
ideally
just
to
the
name.
Are
we
okay
with
the
name
now,
based
on?
Like
the
you
know,
you
know,
discussion,
we've
just
had
yeah
still
still,
okay
with
calling
it
isolated
mode.
Even
though
it's
not
a
100
isolated,
you
can.
A
Because
it
is
of
same
is
the
same
kind
of
you
know.
Everybody
has
different
kind
of
like
associations.
F
A
E
Yeah,
I
think
stamping
on
ustrict
is
not
like
just
for
searchability,
not
something
we
should
do.
G
Fair
enough
I'll
have
to
change
some
some
internal
pipelines
too
isolated.
A
Cool
so
vincent,
can
I
give
you
the
action
to
update
the
rc,
and
then
I
think
we
can
potentially
ratify
this
at
least
and
get
a
poc
together
or
start
working
on
the
actual
code.
C
A
Update,
actually,
we
forgot
this
action.
Okay,
then,
moving
on,
I
want
to
bring
up
the
issue
that
we
brought
up
last
week,
just
again
about
npm
8
and
the
fact
that
we
are
moving
quickly
here
to
potentially
cut
a
next
major
version
of
npm,
potentially
as
soon
as
within
a
week
or
so
this
the
major
breaking
changes
are
outlined
in
the
rrfc
that
was
made
by
nilfu,
unfortunately,
was
able
to
jump
on
the
call
today.
I
know
that
garb.
A
Maybe
you
can
speak
to
the
fact
that
we
did
land.
The
one
feature
end
release
next
and
it's
gonna
go
out.
I
think
in
our
next
release
tomorrow,
did
you
wanna,
say
anything
more
on
on
that
feature?.
H
It's
actually
already
live,
there's
a
bug
fix
for
going
out
tomorrow,
but
right
now,
if
you
have
the
latest
npm
or
using
the
install,
that's
dot
sh,
which
will
pull
the
latest
of
that
sember.
If
it
notices
the
engines
is
not
correct,
it
will
refuse
to
install
something
called
npm
globally.
It'll
do
a
strict,
strict
engines
check
on
its
own
and,
yes,
jordan.
I've
actually
got
a
branch,
I'm
ready
to
push.
I
just
didn't
know
how
public
we
wanted.
I
can
start
the
pr.
H
The
changes
will
be
don't
test
in
node,
10
anymore
change
engines
to
be
greater
than
equal
to
12
and
change
main
in
the
package
json
to
a
file
that
throws
an
error,
saying
we
don't
have
a
programmatic
api
so
functionally.
The
only
difference
is
for
people
like
us
who
go
no
dot
to
test
the
cli,
we're
going
to
have
to
go
node.bin
and
pncli.js.
H
F
That's
great
the
programming
mac
api
hasn't
followed
senver
since,
like
npm3,
I
learned
it
the
hard
way.
As
far
as
the
engines
thing
do
you
want
to
start
at
12.0,
or
maybe
it
could
be
hoisted
to
12
point
esm
or
12
point
latest
just
to
save
yourself
problems
later
when
you
want
to
use
new
features.
E
I
would
probably
say:
well:
it
depends
on
our
dependency
or
not
r,
I'm
not,
but
the
npm's
dependencies
right.
It
depends
on
whatever
they
support
and
I
think
one
of
the
big
things
was
there's
something
that
yeah
there's
something
that
it
dropped
it
yeah
anyway
I'll.
Let
y'all.
A
Yeah,
so
we
were
going
to
open
up,
and
I
have
the
action
to
actually
open
up
an
issue
on
the
node
node
projects,
repo
just
to
inform
them
that
we're
planning
on
making
this
change
and
also
to
ensure
that
we
can
fall
within
the
the
current
major
release
line.
And
so
we
could
probably
flush
out
what
the
right
version
would
be
of
12.
Then
to
support.
F
H
F
A
It's
always
good
when
you're
your
past
self
helps
your
current
self
isaac.
I
see
your
hand
still
up.
Did
you
have
something
you
want
to
add
for
for
this.
A
Always
okay,
so
I
I've
taken
the
or
added
an
action
here
car.
Is
it
okay
to
get
you
to
potentially
determine
what
that
version?
Is
that
we'd
like
to
oh
sure,
and
I
will
change
that
exports
entry,
jordan.
A
Okay,
so
we
should
in
very
short
order,
potentially
be
cutting
the
next
major,
not
with
many
features,
but
ideally
this
portability
long
term
is
has
gone
up.
A
So
two
two
last
items
that
we
had
on
the
agenda
that
I
wanted
to
bring
some
level
of
attention
to
the
robust
lifecycle
scripts
rc,
which
was
a
draft
I
know
fritz.
You
said
there
was
no
update
and
I
think
that's
a
good
update,
but
just
wanted
to
ask
you
if
maybe
we
should
remove
the
agenda
for
now
and
later
on.
I
Yeah,
let's
remove
the
tag
and
back
burner
it.
I
think
there
is
some
utility
in
addressing
this
in
the
future,
but
probably
not
the
priority
right.
A
We'll
now
that
just
now
done
and
toony
the
auto
assertions,
is
there
any
update
here
or
anything.
A
E
I
mean
I,
I
don't
think
I
have
anything
action
on
my
end.
I
think
this
is
I
I
I
don't
recall
if
I
I
believe
we're
kind
of
a
stalemate
with
it,
not
in
like
a
bad
way.
Just
like
I
don't
have
anything
else
I
can
do.
I
I
did
the
things
that
we
talked
about
yeah,
I
I
think
yeah,
it's
in
a
state
where
it
could
be
accepted
is
my
understanding.
E
If
people
want
to
look
over
it
again
and
give
feedback
and
tell
me
if
it's
awful
or
tell
me
it's
great
or
tell
me,
it's
mediocre
feel
free,
but
I
I
think
it's
generally
in
a
state
where
it's
pretty
good,
I
I
think
the
exis.
The
final
thing
that
there's
kind
of
discussion
on
is
third
party
input
and
I'm
I'm
I'm
I'm
personally
pretty
against
it,
and
I
would
actually
prefer
to
close
it
and
not
accept
it.
E
If
we
do
it
that
way,
largely
because
I
I
don't,
I
don't
think
it's
a
good
approach
presently,
but
yeah.
I
I've
documented
my
kind
of
thoughts
on
that
in
here,
and
I
think
expanding
to
that
later
is
fine
doing
it.
As
a
separate
rfc
is
fine
but
yeah,
that's
that's
the
only
remaining
thing,
and
I
I
think
I
you
know,
as
I
said,
I'm
kind
of
I
would
very
much
prefer
not
to
do
it
if
we
do
it
that
way.
So,
okay.
A
E
I
A
We've
accepted
rc's
that
we
knew
weren't
going
to
be
actioned
by
immediately,
at
least
by
by
our
partners.
So,
okay,
we're
about
a
minute
over.
I
appreciate
everybody
jumping
on
today
and
thank
you
so
much
for
all
the
discussion.
Hopefully
we
can
keep
things
going
and
I'll
see
you
next
week.