►
From YouTube: Open RFC Meeting - Wednesday, August 25th 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live.
Welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
august
25th
2021..
A
I
will
be
following
along
in
the
agenda
that
was
posted
in
issue
439
in
the
ampm
rfcs
repo
and,
if
you
haven't
already
feel
free
to
add
yourself
as
an
attendee
to
the
meeting
note
stock,
the
hackamd
dock
that
I
shared
in
chat
and
I
have
poked
a
few
slack
channels-
hopefully
folks
will
will
trickle
in
if
they
wanted
to
join
today,
quicker
night
reminder
and
acknowledgement
that
these
calls
in
all
cons
on
the
rfc's
repo
are
governed
under
a
code
of
conduct,
and
we
ask
folks
to
please
be
kind
and
in
these
calls,
if
someone's
talking,
please
raise
your
hand
and
I'll
call
on
you
and
just
to
be
mindful
and
thoughtful
of
each
other.
A
As
we
discuss
work
in
flight
here
and
and
and
the
proposals,
I
want
to
give
some
time
also
for
any
announcements
folks
might
have.
A
If
not,
we
can
jump
right
into
the
agenda.
There's
also
notes
for
the
previous
meeting
notes
from
last
week
there
so
there's
a
link
if
folks
want
to
catch
up
on
what
we've
been
discussing
lately.
The
first
rfc
that
we
had
queued
up
is
number
126..
A
This
is
a
proposal
for
adding
types
information
to
the
package
json
in
the
registry.
I
noticed
that
gar,
you
added
the
agenda
label
to
this
in,
I
think
in
the
last
couple
days.
I'm
not
sure
if
you
want
to
know
why
we
want
to
bring
this
back
up.
I
was
more
about
the
pull.
B
This
pull
request
is
old
and
things
have
changed
a
lot
in
the
in
the
website,
because
we
now
show
whether
they
have
type
strip
script.
I
wasn't
sure
if
this
was
still
something
we
wanted
to
do
so
I
just
out
of
the
agenda.
B
Any
historical
knowledge
holders
can
weigh
in
it
seems
pretty
straightforward,
but
I
don't
know
if
this
is
the
direction
it
goes
to.
A
Yeah,
so
if
my
memory
serves
me
right,
I
think
ordo
had
done
a
bit
of
work
to
add
to
add
this
information
right
and
and
open
up
the
pull
request,
and
we
just
never
followed
up
on
and
pulling
it
in,
so
the
corresponding
pr
that
you're
speaking
to
is
number
92.
I
believe
yeah
go
to
the
chat.
Okay.
A
So
if
this
lands,
this
information
should
be
readily
available,
based
on
the
fact
that
we
are
pulling
out
package
metadata
and
serving
that
in
the
registry
today,
or
would
we
have
to
queue
up
the
registry
team
to
do
any
work
to
ensure
that
this
is
being
served.
B
It
wouldn't
backboard
anything
because
I
don't
think
existing
pacuments
can
change
so
this
all
this
does
is
when
you
read
your
package,
json
it'll,
add
those
two
fields
so
any
I
I
think
anything
that
touches
or
changes
the
package.
Json
will
add
those
yeah.
I
don't
I
like.
I
said
I'm
not
fully
versatile
use
case
here.
C
B
B
Okay,
I
mean
this
seems,
I
mean
fine.
I
just
like
I
said
it
predates
any
involvement
I
have,
and
I
just
want
to
make
sure
this
was
still
something
I
wanted
to
do
cool,
so
action
is
pulling
that
into
the
next
yeah
I'll,
merge
it
it'll
ship,
thursday
and
jordan,
thanks
for
weighing
in
on
newer
models
of
dot
slash,
I
didn't
realize
that
was
the
thing
we
wanted
now.
So
I'm
by
moving
that
in.
B
C
I
haven't
looked
at
it
and
probably
if
I
had
any
opinions
about
it,
I
forgot
them
years
ago.
If
you
want
another
set
of
eyes,
I'd
be
happy
to
do
a
review
of.
B
It
but
I
got
it
rebecca.
A
Yeah
and
if
you
need
more
context,
you
can
always
reach
out
to
order
internally
as
well.
You
can
book
them
so
awesome.
Thank
you
so,
just
giving
you
the
action
to
update
pr
and
share
the
link
test,
pass.
A
Moving
on
then,
I
know
this
is
a
draft
pr
fritz,
but
I
want
to
pull
this
up
so
I
added
the
agenda
label
here.
Pr
number
437,
the
rfc
to
add
robust
lifecycle
scripts.
Did
you
want
to
give
kind
of
like
an
overview
of
what
you're
starting
to
to
work
on
here?
That's.
E
Yeah
so
again,
like
you
said
it's
a
draft,
so
it's
just
a.
I
just
wanted
to
get
a
discussion
started
on
this.
It
was
inspired
by
the
bug
in
3042,
where
in
npm
v6
we
had
pre,
uninstall
and
install
and
post
and
install
lifecycle
scripts,
and
we
don't
have
that
anymore
after
discussing
it
with
people
and
investigating
it's
just
sort
of.
E
It
became
clear
that
what
we're
missing
the
reason
why
we
can't
really
have
these
scripts
is
because
we're
missing
context
like
these
scripts,
wouldn't
know
why
why
they
were
run
and
it's
unclear
when
we
would
run
them,
because
when
you
uninstall
a
package,
that's
you
uninstalling
the
package.
E
Okay,
that's
user
intention,
that's
one
scenario:
right:
you're,
uninstalling,
a
route
or
a
global
package,
but
if
say
a
dependency
changes
a
version
a
little
bit
and
now
a
package
version
can
be
deduped,
so
we
don't
have
to
have
it
in
the
tree
in
two
places
with
two
different
versions
anymore,
and
so
one
of
those
instances
goes
away.
Is
that
really
an
uninstall
right
and
there's
all
sorts
of
scenarios
like
that
for
really
all
of
the
lifecycle
scripts
that
involve
arborist
reifying,
the
the
tree
right?
E
So
these
scripts
don't
have
enough
context
to
know
exactly
what's
going
on,
and
so
this
rfc
is
just
a
starting
discussion
on
okay.
How
do
we
solve
this
problem
in
such
a
way
where
those
scripts
get
the
necessary
context?
E
Do
we
do
we
pass
arguments?
Do
we
templatize
the
command
line
parameters?
Do
we
just
add
more
events
that
are
more
specific
and
then
also?
How
do
we?
How
do
we
deal
with
the
current
lifecycle
scripts?
Do
we
just
make
them
the
default
entries
in
a
life
cycle?
Sub-Object
like
I
suggested,
or
do
we
do
something
else?
Some
of
the
discussion
is
interesting,
especially
around
already
around
you
know
how
much
of
the
internals
of
the
way
the
npm
cli
works.
E
A
E
So
yeah,
I
don't
know
if
anyone
else
has
had
a
chance
to
read
through
it
or
think
about
it,
but
yeah.
I
think
I
think,
there's
a
lot
of
a
lot
of
potential
here
for
improvement.
A
Awesome
so
I
guess
the
action
here
is
for
for
this
group
and
and
folks,
listening
or
watching
afterwards
to
provide
feedback
in
in
the
rc
itself
you're
going
to
keep
this
open
for
a
bit,
I
think
and
just
continue
to
design
it
in
the
open.
I
is
what
I
understand:
fritz
and
yeah.
E
Yeah
I'll
take
it
out
of
draft
as
soon
as
at
least
I've
filled
in
all
the
sections,
but
yeah
it
definitely
will
need
to
be
iterated
on
even
after
it's
out
of
draft.
E
A
C
One
comment:
I
I
think
the
the
thing
about
like
how
much
implementation
detail
do
we
want
to
expose
is
is
pretty?
Is
the
exact
right
thing
to
be
concerned
with,
especially
as
we're
going
through
what
I
assume
we'll
spend
most
of
our
time
today
on
this
pure
mode
proposal.
C
I
I
sort
of
brought
that
up
like
before
tree,
changing
after
unpack
or
something
as
as
phases,
just
because
we
we
really
part
of
the
challenge
with
uninstall,
is
that
we
really
can't
like
we
can't
run
you
there's
phases
in
the
npm
install
process
where
we
cannot
run
user-led
code
for
security
reasons,
for
the
fact
that
if
you
do
almost
anything,
it
will
potentially
blow
up
it's
just
a
foot
gun
like
there's,
there's
a
lot
of
good
reasons
why
we
can't
let
the
tree
change
at
certain
phases,
where
we're
relying
on
it
being
consistent.
C
But
yeah,
that
being
said,
we
don't
want
it
to
be
like.
I
am
going
to
write
these
files
and
now
we're
like
now
in
some
future
worlds.
We're
not
writing
files
anymore.
We're
just
writing
an
import
map
to
a
central
location,
and
we
have
to
like
shim
it
because
now
everybody's
depending
on
it
and
we
break
react
if
we
don't
do
it
or
whatever.
I
do
want
to
try
to
avoid
that.
C
I
I
think,
though,
there's
there
are
some
very
like
high
level
conceptual
phases
that
we
can
think
about
like
I
am
you
know,
maybe
maybe
before
tree
change
is
the
is
the
wrong
way
to
think
about
it.
C
But
like
I'm
about
to
read
what
is
currently
the
state
of
the
world
right,
like
that's,
always
going
to
be
a
phase
we're
going
to
have
or
I've
I've
resolved
the
packaged
trees
like
I've
resolved
the
ideal
tree,
and
these
are
the
changes
I'm
about
to
make
and
kind
of
giving
users
a
way
to
kind
of
hook
into
that
part
of
the
process,
and
then
they
could
just
see
like
is
my
package
in
the
like
to
be
removed
list
or
something
or
you
know,
have
we
added
xyz
as
a
dependency
or
something
I
think
that
will
if,
if
we
try
to
zoom
out
and
make
a
list
of
like
those
kind
of
conceptual
phases,
that's
something
that's
got
a
little
bit
more
staying
power
than
implementation
details.
E
Yeah,
I'm
glad
you
brought
up
import
map
because
I
mean
just
with
the
you
know:
if
we're
going
to
add
multiple
resolution
engines
and
we're
going
to
add
multiple,
you
know
reifying
strategy
strategies,
it's
yeah,
it's
good
that
we
we
think
about
this
in
a
more
broad
way.
D
A
A
This
is
rc436.
This
is
new
installation,
installation
or
mode
or
strategy
that
vince
bailey
who's
on
the
call
today
has
been
working
on
and
we've
actually
been
discussing
quite
a
bit
internally
for
a
while.
Now
and
historically,
I
think,
we've
been
even
spoken
to
the
idea
of
configurable
strategies,
reflication
strategies
in
the
past-
and
this
is
sort
of
like
one
of
the
first
four-
is
into
that.
So
I'm
not
sure
vincent.
A
If
you
want
to
give
a
maybe
high
level
overview
of
of
what
the
proposal
is
sort
of
outlining
and
then
any
kind
of
follow-ups
as
well.
F
Sure
so
this
is
a
proposal
to
add
a
different
installation
or
verification
strategy
to
npm.
I
think
npm
already
has
three
with
one
called
legacy,
and
one
code
bundle.
I
think
so
and
there's
the
default,
which
I
don't
know
if
it
has
a
name.
I
call
it
hoisting,
because
this
strategy
aims
to
remove
duplication
of
dependencies
by
hoisting
them
to
the
root
of
the
project,
so
that
every
workspace
or
every
dependencies
installing
that
project
have
access
to
that
one
dependency.
F
So
the
the
proposal
of
that
rfc
is
to
add
a
fourth
optional,
reification
strategy,
so
the
the
the
reason
for
that
is
that
we
found
limits
with
the
current
hosting
our
default
strategy,
and
this
is
kind
of
a
suggestion
for
coming
up
with
a
strategy
that
doesn't
have
this
drawbacks.
So
there
is
like
two,
the
two
drawbacks
that
I'm
interested
into
addressing
is
the
first
one
is
perf
or
yeah
perf
and
the
second
one
is
strictness.
F
So
perf
is
the
hoisting
strategy
will
drag
up
in
the
in
the
folder
structure
packages,
so
they
can
be
shared.
But
when
there
is
conflict
version
conflicts
when
two
packages
with
different
version
have
to
be
installed,
only
one
can
be
installed
at
the
root.
The
other
one
needs
to
be
installed
further
done
in
the
dependency
tree,
and
that
can
end
up
in
a
lot
of
duplication.
So
you
can
have
one
package
at
a
given
dependency,
which
is
installed
several
times
on
disk
and,
and
that
happens
in
in
reality,
in
real
life.
F
We
have.
We
have
we
see
this
over
and
over.
So
there
is
a
huge
cost
in
disk
and
in
time,
install
time
to
actually
do
that
verification
on
disk.
F
So
that's
the
first
problem
that
we're
trying
to
improve
and
the
second
one
is
what
I
call
strictness,
which
is
the
side
effect
that
when
we
hoist
all
the
dependency
as
high
as
possible
in
the
in
the
directory
structure,
that
basically
makes
like
we
over
share
the
dependencies.
F
So
a
workspace
that
doesn't
have
any
dependency
declared
on
package
foo
will
still
be
able
to
require
foo
because
someone
else
added
a
dependency
to
it,
and
that
creates
a
problem
as
we
scale
because
as
we
scale,
that
means
that
any
dependency
modification
in
one
workspace
can
potentially
affect
any
other
workspace
so
for
large,
very
large
repos,
with
many
workspaces,
where
you
it's
very
advantageous
to
be
able
to
predict
the
scope
of
the
impact
of
of
a
dependency
change.
F
That
is,
that
is
a
big
problem
with
hosting.
So
that's
the
second
problem
we're
trying
to
to
address
with
this
proposal
any
questions
so
far.
G
G
G
Current
maintain
the
number
of
projects
that
have
bug
open
issues
filed
well
no
longer
open,
but
issues
filed
because
pnp
breaks
them.
I
have
many
others
that
yarn
breaks
yarn
works
around
them
because
it
hacks
the
run
time
and
actually
like
even
hacks.
It
even
like
injects
itself
into
what
should
be
node
modules
files
and
like
swaps
them
out
so
that
it
works.
But
neither
of
these
approaches
is
without
significant
drawbacks
and
eslint.
Plug-In
import,
for
example,
which
is
a
heavily
used.
G
Eslint
plug-in,
has
always
relied
on
this
behavior
for
its
node
resolver,
which
users
do
not
have
to
install,
but
their
configuration
can
reference,
and
that
gets
11
million
downloads
a
week.
G
So,
like
the
I
I
I
hear
that
it's
it
would
be
opt
in,
but
someone
opting
into
it
would
then
things
would
break
that
they
would
have
no
control
over
no
way
to
fix,
and
so
the
end
result
is
either
they
will
they
will
then
it
would
that
will
force
them
not
to
to
no
longer
use
this
dependency,
which
is
an
unfair
disadvantage
for
dependencies.
Relying
on
this
decade-long
old
behavior
or
that
will
cause
them
to
be
unable
to
use
the
new
mode
which
defeats
the
purpose
of
adding
it.
F
Yeah
this
is
where
actually,
this
is
the
you
touched
on.
The
big
question
is
how
compatible
or
heartbreaking
in
in
practice-
I
I
don't
know,
I
don't
have
this
data,
so
you
you
know
you.
You
mention
one
that
has
a
lot
of
usage
and.
G
Yeah,
I
don't
use
either,
so
I
don't
have
concrete
examples.
I
just
know
that
I've
received
over
the
years
many
bug
reports
on
my
many
projects,
most
about
yarn
and
a
few
about
p
pnpm
and
in
the
in
like
irc
and
other
chat
communities.
G
The
common
advice
is
to
tell
people
not
to
use
those
those
things,
because
they
have
too
many
caveats
and
the
type
of
people
who
come
to
ask
for
help
tend
to
have
an
easier
time
when
they
don't
choose
those
paths,
obviously
again
being
opt-in,
feeds
into
that
somewhat,
but
it
like
yeah,
I
mean
and
just
to
say
as
well
like
when
it
comes
to
workspaces.
G
I've
talked
many
times
on
this
rfc
call
about
the
insufficient
that
the
current
workspaces
are
insufficient
because
they
hoist
like
the
hoisting
of
child
project
dependencies
to
the
root
making
them
available
in
sibling
projects.
That
is
actually
a
much
larger
likelihood
of
bugs.
In
my
experience
than
the
hoisting
of
transitive
dependencies
to
the
root
of
a
single
project,
and
so
I'm
very-
and
that
was
when
my
initial
fervor
on
the
pr
was-
was
about
that
trying
to
fix
that
problem.
G
A
So
I
have
one
question
on
that,
but
I'll
let
isaac
jump
in
here.
First.
C
Yeah,
so
I
I
think
there's
I
I
made
this
comment
on
the
pr
you
know
minutes
before
this,
or
maybe
even
as
this
meeting
was
starting.
So
I'm
sure
it
didn't
really
get
seen,
but
I
I
think
it
makes
sense
to
talk
about
this
reification
mode
like
100,
apart
from
workspaces
per
se
right
workspaces,
might
be
the
the
kind
of
the
motivating
factor,
at
least
for
like
why
the
microsoft
one
js
project
cares
about
it
because
they
have
this.
C
You
know,
however,
like
like
100
terabyte,
mono,
repo
project
or
whatever,
but
I
I
think,
even
if
you're
not
using
workspaces,
there's
some
there's
a
real
interesting
trade-offs
that
we
could
start
to
explore
and
the,
and
I
really
want
to
make
sure
before
we
you
know
like
if
we
say
okay
well,
look
pnpm
has
this
particular
problem
with
yes,
what
is
it?
Esl
plugin
imports
right?
C
We
can
look
at
a
couple
of
other
projects
that
are
broken
by
pnpm's,
specific
implementation
of
this
and
look
at
how
pnpm
you
know
what
workarounds
exist.
Maybe
we
could
like.
Maybe
we
could
actually
address
those
problems
with
this
proposal
and
and
make
it
a
little
bit
easier
to
opt
into,
but
jordan,
I
think
you're
coming
at
it
from
the
right
point
of
view
of
like
what.
What
is
the
concern
that
needs
to
be
brought
up
and
really
fleshed
out
and
explored
and
addressed
two.
C
I
think
this
is
this
is
not
like
if
anybody's
like
watching
or
you
know
on
this
call
like
this
is
not
a
thing
we're
going
to
implement
tomorrow.
I
think
it
does
need
quite
a
bit
of
kind
of
exploration
and
it
will
almost
certainly
be
in
december
major,
although
it's
you
know
from
a
strict
sember
point
of
view,
if
it's
opt-in,
it
could
be
assembler
miner.
C
I
suspect
that
there's
gonna
be
other
changes
that
we
need
to
make
to
our
architecture,
to
kind
of
enable
it
and
and
make
it
work
in
the
way
as
it's
as
it's
being
proposed,
and
some
of
those
might
end
up
being
december
major
or
have
just
consequences
that
are
easier
to
just
make
as
a
breaking
change.
C
The
the
two
kind
of
thoughts
that
I
had
one
one
is,
I'm
not
sure
we
need
to
kind
of
make
a
decision
about
what
we
do
with
things
that
are
currently
an
e-resolve
error,
because
you
have
two
dependencies
that
have
a
conflicting
peer
dependency,
whereas
right
now
we
won't
allow
those
two
things
to
be
installed
at
the
same
level
in
the
tree,
but
it
seems
like
with
pure
mode
you
would
be
able
to
because
they
would
just
get
different
versions.
C
C
It
seems
like
a
change
to
a
change
to
transitive
dependencies
results
in
being
an
entirely
different
folder
tree
right.
So,
if
I
have
you
know
a
that
depends
on
b
at
one
dot
x.
If
I
want
to
update
b,
I
have
to
also
swap
out
the
sim
link
for
everything
that
depends
on
b,
because
now
their
locations
on
on
disk
is
is
going
to
be
different
and
yeah.
Just
to
the
to
the
question
to
the
question
brought
up
in
in
chat,
it
seems
yeah.
C
It
seems
like
the
way
that
things
are
going
like
fritz
said,
the
the
future
of
something
like
tink
or
a
virtual
file
system
or
fallback
fs
kind
of
approach
is
going
to
be
import
maps
like
actually
import
maps
is
pretty
oddly
pretty
similar
to
to
what
tink
would
have
provided,
but
without
needing
to
hack,
the
you
know,
hack
the
operating
system
or
hack,
the
the
node
fs
module,
because
you
just
gave
a
json
blob.
C
That
says
when
you
require
this
thing,
it
goes
over
here
and
you
can
essentially
do
all
of
this
without
siblings,
but
that
is.
That
is
something
that
should
be
like.
That's
not
gonna
be
possible
in,
like
node
less
than
probably
18..
I
wouldn't.
I
wouldn't,
pin
anything
to
it
just
yet.
It's
definitely
something
we're
tracking
and
we're
gonna
try
and
guide
that
in
a
direction
where
you
know
it
makes
sense
for
us
to
be
able
to
just
generate
import
maps
as
npm
and
maybe
basically
do
you
know
it
could.
C
A
Other
than
it
seems
like-
and
we've
discussed
this
internally-
that
there's
about
three
different
pieces
of
work
that
all
align
so
improvements
to
npm
link
overrides,
which
is
on
our
immediate
sort
of
roadmap,
and
then
also
this
new
reofficiation
strategy,
which
I
I
think,
which
you
originally
touched
on
jordan
and
what
vincent
alluded
to
is
trying
to
solve.
You
know
three
different
aspects
of
of
that.
A
We
realize
are
problems
on
for
end
users
today,
so
like
performance,
strictness
and
and
just
the
accuracy
and
so
yeah,
not
not
hoisting,
but
also
not
incurring
a
penalty
for
not
hoisting
your
dependencies
and
then
the
shared
first,
not
shared
transitive
dependency
problem
that
jordan
and
isaac-
and
we
have
had
many
conversations
on
in
this
forum
on
this
again-
is
sort
of
like
trying
to.
A
I
think
this
rfc
is
trying
to
to
solve
for
all
those
use
cases
and
how
we
do
that,
potentially,
is
you
know
in
the
future?
We
can
utilize
import
maps,
but
how
we
do
that
today
might
look
a
little
bit
differently
and
could
piggyback
on
potentially
the
work
that
we
do
for
overrides
and
and
in
the
future.
Here
also
fritz
for
any
improvements
we
make
to
mpm
link.
So
I
see
your
hands
up,
phil
feel
free
to
comment
yeah.
So
I.
E
E
What
if,
what
if
we
solve
the
workspaces
side
of
it,
just
isolate
isolated
on
its
own,
like
jordan's,
suggested,
suggested
and
then
make
a
holistic
approach
to
a
lot
of
these
problems
like
npm
link,
and
you
know,
resolution
strategies
in
general
and
get
all
of
our
ducks
in
a
row
behind
import
maps,
and
so
we
solve
the
immediate
problems
in
as
narrow
of
a
of
a
focus
as
we
can.
Maybe
we
punt
on
some
of
them
and
go.
E
You
know:
hey
it's
not
worth
solving
npm
link
right
now,
when
we
know
in
you
know
a
year
and
a
half
a
year
and
a
half
from
now
we're
going
to
have
import
maps
right,
so
I
think
yeah.
I
think
we
could
make
a
really
clear
vision
for
what
that's
going
to
be,
and
it's
going
to
solve
just
all
of
these
related
problems,
and
we
can.
We
can
solve
the
immediate
problems
in
a
narrow
way.
A
Yeah,
I'm
gonna
take
some
some
notes,
but
I'm
not
sure
if
anybody
else
had
anything
they
want
top
up
here.
I
my
biggest
concern
is
like
I
don't
want
us
and
I
think
you're
taking
the
right
approach
by
recommending
we
can
solve
this
for
workspaces
first.
That
would
also
like
you
know.
I
know
that
vincent's
team
is
is
hoping
to
to
make
movement
here
and
help
contribute
to
this.
So
we
have
extra
resources.
A
Obviously,
behind
you
know
going
forward
with
an
opt-in,
reification
strategy
like
and
work
around
this
proposal
so
like
I
don't
want
to
stall
and
block
to
to
get
something
done
here,
but
I
also
don't
think
it
makes
sense
for
us
to
like
build
the
wrong
thing
so
like
if
we
can
learn
from
doing
this.
Just
let's
say
for
workspaces,
then
maybe
that
helps
us
solve
this
more
holistically.
A
You
know
six
months
to
12
months
down
the
line
when
we're
looking
at
potentially
like
the
npm
link
story
and
and
yeah
like
then,
we
are
potentially
generating
and
consuming
important
maps.
Go
ahead.
G
Yeah
and
just
in
practice
both
in
many
small
projects
and
also
like
large
company
things,
the
the
bugs
that
people
fear
from
being
able
to
require
things
that
aren't
in
package.
G
Json
are
uncommon
problems
historically
in
my
experience
and
are
virtually
non-existent
problems
because
things
like
typescript
and
eslint
plugin
import
check
that,
for
you,
the
tooling's
been
around
for
the
better
part
of
a
decade
to
verify
that
and
everyone
pretty
much
uses
it,
and
these
bugs
just
don't
happen
and
the
use
cases
I'm
talking
about
like
the
eslint
plug-in
import,
one
that
relies
on
it
is
because
it's
not
required
from
javascript
and
so
there's
no
static.
Tooling.
G
That
can
let
you
know,
and
so
it
would
simply
be
forcing
pain
on
users
to
require
them
to
add
the
dependency.
So
like
yeah
there's,
I
I
think
that
the
the
problems
that
workspace
hosting
causes
are
going
to
be
very
common.
I've
run
into
them
already
in
yarn
workspace
and
you're
learning
workspace,
repos
and
I'm
very
interested
in
seeing
those
solved.
G
But
I
I
my
very
strong
intuition
is
that
once
those
are
solved
that
we
may
decide-
and
we
may
discover
that
there
is
in
fact
not
much
of
a
need
for
further
strictness
other
than
to
scratch,
like
an
ideological
itch,
and
I
think
it's
worth
kind
of
demonstrating
that
either
way
before
we
go.
E
So
I
I
have
a
question
out
of
ignorance
here.
If,
if
we
were
to
say
change
the
way,
you
know
basically
remove
hoisting
in
workspace,
workspace
hosting
right
without
a
configuration
option
just
make
that
just
a
flat
out
change.
Would
that
break
anybody
right
now?
Would
that
really
be
a
a
breaking?
Change?
Would
is
workspaces
considered
in
preview
right
now,
or
is
this
like
a
production
thing.
G
Yeah
I
mean
I,
I
think
that
on
a
semver
level,
it
would
absolutely
be
a
breaking
change
on
a
practical
level.
It's
probably
not
going
to
break
anyone,
because
theoretically,
no
one's
relying
on
it
yet,
but
it
might
and
also
theoretically,
if
it
did
break
them,
it
would
break
them
in
a
way
that
tells
them
quickly
how
to
fix
it
by
putting
the
dependency
in
the
right
place.
So
maybe
it's
fine,
but,
like
my
guess,
is
you
know
that
npm
will
choose
not
to
be
cavalier
about
the
possible
risk
there.
C
No,
we
we
would
do
that
in
a
major
bump
for
sure,
but
you're
right
it
would
be.
It
would
be
a
small
one.
I
would
not
consider
it
a
a
big
change
for
a
summer
major
bump,
I'd
I'd.
Consider
that
a
much
smaller
thing
and
because,
like
you,
said
it's
going
to
break
your
tests
and
then
you're
going
to
see.
Oh
it
couldn't
require
a
modular
flu.
I
guess
I
have
to
end
kim,
install
foo
in
that
workspace,
probably
like
it's
it's
easy
to
solve.
C
So
the
the
the
problems
I
think
with
I.
I
have
heard
very
mixed
results.
Unlike
pnpm
broke,
my
entire
world
versus
pnpm
saved
us
from
these
catastrophic
issues
and
everything
in
between
right,
and
I
think
I
think,
shadow
depths.
What
makes
what
makes
shadow
dependencies
a
little
bit
more
of
an
issue,
at
least
in
some
cases,
is
that
they
are
they're
difficult
to
detect
until
the
problems
that
they
cause
are
difficult
to
detect
at
the
point
of
solving
them
right.
C
If
you,
if
we
stop
hoisting
something
and
you
and
now
all
your
test
break
in
one
of
your
workspaces,
like
you
notice
that
when
you're
there
at
the
point
where
you
can
fix
it,
but
if
there's
a
shadow
dependency
which
is
being
hoisted
or
you
know
or
like
it's
a
it's
a
dependency
of
the
root
project
or
something
else
and-
and
you
don't
declare
it
then
far-
far
away
down
the
line
when
you're
deploying
your
service
or
when
somebody
is
installing
your
dependency,
then
it
stops
working.
C
C
This
shadow
dependency
there
and
then,
when
we,
when
we
removed
that
dependency,
that
you
know
shadow
dependency
from
the
clay
it
stopped
working
right
and
so,
and
that
was
kind
of
like
now
you're
nowhere
near
the
problem
when
you
actually
encounter
it,
so
I
think
it's
it's
worth
exploring
a
way
to
fix
it,
and
certainly
like
pure
mode
or
pnp
mode
will
surface
that
problem
much
earlier
and
that's
kind
of
a
benefit
and,
like
I
said,
we
just
really
need
to
delineate
like
these
cases,
where
it's
where
pnpm
currently
causes
problems
and
so
mimicking
pfp
will
probably
cause
the
same
problems
and
see
if
we
can
avoid
them.
C
Somehow.
I
I
think
that
there
may
be
cases
there
may
be
more
options
that
we're
kind
of
gonna.
Think
of
in
the
next
20
minutes.
A
F
Yeah
I
have
so
so
there's,
obviously
the
unknown
of
you
know
how
much
of
a
breaking
change
it
will
be
in
the
current
state
of
the
rfc
and-
and
you
know
that
we
need
to
go,
collect
the
data.
But
there
is
also
something
that
I
don't
know.
Is
that
the
the
thing
that
are
breaking?
F
What
are
they,
depending
on
this
behavior
as
a
feature?
Or
is
it
just
a
mistake
that
can
easily
be
fixed
in
their
dependency
by
adding
a
pure
dependency
or
or
dependency
in
the
packages?
And
because
these
are
two
different
things?
G
Yeah-
and
I
have
seen
also
packages
just
saying,
shutting
themselves
up
and
just
adding
it
as
a
pure
dependency,
even
though
it
shouldn't
be
one
because
that's
a
way
to
clue
in
to
pnpm
and
pnp
that
this
package
should
have
access
to
that
dependency.
G
So,
like
there's,
probably
a
solution
to
that
along
the
lines
of
like
provide
a
mechanism
for
explicitly
saying.
I
want
access
to
this
thing.
I
don't
declare
that
isn't
a
peer
dependency,
because
that
comes
with
additional
semantics.
So,
like
there's,
there's
like
isaac,
saying,
there's,
surely
multiple
paths
through
this
and
it's
probably
you
know
it'll,
probably
be
helpful
to
list
those
cases
out.
A
Rebecca
see
your
comment:
do
you
want
to
say
that
out
loud
explicitly,
you're
curious,
how
a
global
style.
H
Impacts
these
problems,
just
that
the
global
style
is
a
you
know,
fairly
obscure
command
line,
option
that
makes
it
so
that
your
direct
dependencies
are
have
all
their
dependencies
installed
inside
of
their
folder,
not
hoisted
to
the
very
top.
So
it
just
pushes
the
wasting
out
one
level,
which
is
how
your
global,
the
the
global
directory
is
installed
when
you
install
globals
so
like
that,
that
makes
it
impossible
to
accidentally
require
a
shadow
dependency
in
your
project.
Although
your
dependencies
could
still
do
that.
F
C
That
but
yeah
it
does
so
the
downside
of
global
style,
as
far
as
duplication,
like
makes
duplication,
look
much
worse
right.
Essentially,
everything
that
is
not
a
direct
dependency
is
duplicated
it
it.
It
does
help
prevent
and
I
have
heard
of
people
using
it
or
suggested
people
use
it
as
a
way
to
kind
of
detect
shadow
dependencies
within
your
project,
and
it's
pretty
effective
there,
but
it's
it's
also.
It
is
obscure,
it's
it
doesn't
have
it,
it
doesn't
get
a
ton
of
use.
H
A
A
So
I've
I've
taken
down
two
action
items
in
terms
of
trying
to
bubble
up
some
more
information
about
one,
how
big
of
a
breaking
change
would
this
be
if
it
landed
in
the
current
release
line
or
in
just
within
a
major
release
line?
So
if
it
was
like
shipped
under
a
miner,
is
that
acceptable
so
like?
If
it's
behind
a
flag?
Is
that
acceptable
and
then
also
bubbling
up?
Maybe
what
projects
today
are
breaking
that
are
used
at
pmpm
that'd,
be
good
to
just
discover.
A
Add
to
this
rfc,
some
more
information
about
you
know,
feedback
that
people
have
and
and
maybe
use
cases
where
pmpm
breaks
down,
or
that
this
strategy
breaks
down.
I
think
just
being
able
to
show
that
shows
that
we're
like
going
to
this
like
eyes
wide
open,
so
that
you
know
we're
managing
like
the
trade-offs
of
and
the
benefits
here.
So
I
think,
there's
a
lot
of
benefits
to
isaac's
point.
A
I've
heard
you
know
resounding
that,
like
not
that
resounding
thanks,
but
a
lot
of
people
have
said
that
pmpm
has
you
know,
sped
up
and
cleaned
up
their
their
projects
significantly
and
have
you
know
praised
it
for,
for
obviously
say,
being
disc
efficient,
so
that's
at
least
indicator
that
we
should
be
exploring.
You
know
this
and
trying
to
do
something
or
provide
something
similar
right.
C
You
know
another
thing
that
occurs
to
me:
we
haven't
really
explored
this,
but
we
could,
if,
if
it,
if
the
goal
was
merely
disk
efficiency
right,
like
don't
take
up
as
many
blocks
on
your
hard
disk,
we
could
potentially
do
some
some
interesting
tricks
where
we
unpack
unpack
a
package
tarball
into
the
cache
and
then,
instead
of
instead
of
actually
creating
new
files
within
the
node
modules
folder,
we
hard
link
every
file
from
that
from
that
package
into
their
respective
locations
and
node
modules.
C
So
you
know
you
would
just
have
an
extra
an
extra
entry
in
the
file
or
the
you
know,
links
table
without
actually
having
more
blocks
on
your
disk
being
written,
and
it's
it's
a
lot
faster
to
it's
significantly
faster
to
create
a
hard
link
than
it
is
to
write
a
new
file.
We
just
kind
of
haven't
explored
it
because
it
hasn't
been
a
priority
and
it's
it's.
C
You
know
just
a
bunch
of
typing
to
to
make
that
work,
but
that
might
be
something
that
you
know
as
we
get
more
large
projects
using
using
workspaces
and
and
using
large
mono
repos.
That
may
be
something
where
we
can
actually
sort
of
alleviate.
C
You
know
in
a
lighter
way
than
pure
mode
and
with
less
overhead
than
pure
mode
and
also
in
some
ways,
less
benefits,
but
we
could
still,
maybe,
in
the
shorter
term,
alleviate
some
of
the
some
of
the
disk
space
issues,
in
particular,.
F
Yeah
so
the
disk
space
issue,
I
see
it
more
of
an
issue
because
of
the
time
it
takes
to
set
up
then
of
the
disk
it
consumes.
F
Like
I
think,
oh,
I
have
the
impression
that
the
non-module
folder
is
size
is
not
an
issue
compared
to
the
size
of
our
hard
drive
these
days,
but
maybe
I'm
wrong
following
some
memes
on
the
internet,
but
what
I
think
is
more
limiting
resource
and
something
every
developer
feels
is
the
install
time
and-
and
there
is
a
cost
of
copying
over
so
so
this
idea
to
in
the
cache
to
have
to
have
the
cache
you
know,
have
the
files
in
cache
and
just
hard
linking.
D
F
F
And
there
was
also
yarn
version
one
they
had
this
flag
called
hard
link
or
something
like
that
where,
if
two
files
will
have
to
be
copied
to
some
location
on
the
non-modal
folder,
because
the
the
yarn
cache
is
uncompressed
archive,
they
will
actually
copy
the
first
file
to
the
non-module
folder
and
the
second
one
will
be
a
hard
link
to
the
first
one
in
the
normal
folder
and
that
needs
to
be
confirmed.
F
But
in
my
experiments
that
didn't
the
perform
that
was
similar
as
just
copying
the
file,
but
that
that
needs
to
be
validated.
I
don't
have
a
strong
confidence
in
that
statement.
F
So
so
these
are.
F
The
hard
link
are
good
ideas
that
have
been
implemented,
so
that's
definitely
something
we
can
look
into.
A
Yeah,
so
I
just
shared
the
reference
there.
It's
link
duplicates
from
yarn
is
the
flag,
I
believe,
you're
speaking
to.
F
Yeah
and
and
from
pnpm
it's
just
the
default
so
because
the
package
can
be
can
be
like
when
you
have
different
peer
dependencies
result,
you're
going
to
have
one
version
of
one
package
being
multiple
in
multiple
folders,
multiple
different
sim
links,
and
but
the
content
of
that
folder
will
be
the
same.
The
only
difference
will
be
its
it's,
not
their
own
non-module
folders.
So
the
content
of
that
is
actually
hard
link
on
pnpm.
C
F
And
maybe
that
has
changed
because
now
they
have
implemented
their
content,
content
based
storage.
So
I'm
not
sure,
but
at
least
at
some
point
that's
what
pnpm
was
doing.
A
Did
any
other
folks
have
any
comments?
I
know
that
we've
made
a
number
of
comments
and
references
to
pmpm.
Obviously,
in
the
in
this
call
I
did
reach
out,
notably
to
zoltan
and
asked
for
him
to
to
comment
on
the
rc
and
and
did
that
and
hoping
that
you
know
we
can
potentially
collaborate
there
or
bubble
up.
You
know
the
the
you
know,
problems
that
they've
found
in
terms
of
going
with
this
kind
of
strategy
so
that
we
we
work
around
those.
A
So
I
think
there's
opportunity
here
obviously
to
to
to
collaborate
really
closely
with
those
folks.
So
I'm
hoping
they
engage
a
bit
more
on
the
rc,
notably
this
time
isn't
very
good
for
resultant
to
come
to
so
hopefully,
if
we
have
to
and
if
we
decide
to
do
a
deep
dive,
we
can
change
the
time.
So
it's
a
little
bit
easier
for
for
folks,
we
want
to
to
jump
on
to
I
see
fritz
you're
commenting
a
bit.
Is
there
anything
else
you
want
to
share.
E
Oh,
I
just
kind
of
side
conversation
about
you
know
storing,
storing
unpacked
packages
in
in
the
cash.
You
know
what
the
implications
are
for
that,
like
you
know,
isaac
pointed
out
that
I
pointed
out.
You
know
that
people
that
are
really
aggressive
with
clearing
their
cash
could
could
run
into
problems.
Isaac
said
that
you
know
worse
than
that.
Somebody,
you
know,
adding
you
know
going
into
their
node
modules
and
and
adding
a
console
log
would
then
affect
multiple
projects
potentially
and
yeah.
So
just
conversation
around
that.
C
A
F
Yeah,
so
pnpm
has
integrity
check
so
when
I
think
I
don't
know
if
it's
activated
by
default,
because
it's
obviously
cpu
intensive,
but
with
this
option,
when
you
install
it
will
check
the
integrity
of
your
own
module
folder
and
if
someone
change
something
it
will
just
you
know,
re
put
it
back
to
the
way
it
should
be
so.
But
the
the
issue
with
that
is:
is
the
cpu
cost
during
uninstall
a
yarn
install
during
the
install
process,
so.
C
I'll
just
read
the
comments:
if
they
are,
if
they
are
hard
links,
then
edits
you
make
in
one
location
might
well
it
wouldn't
wipe
out.
It
would
take
away
the
debugging
work
in
project
b,
like
that.
This
is
kind
of
we're
getting
we're
getting
off,
subject
and
running
out
of
time.
But
essentially
you
add
a
console
log
in
you
know
a
slash
node
module
that
console
log
shows
up
in
a
slash,
node
module
b.
C
If
you
cleared
your
cache
and
then
reinstalled
b,
a
would
still
have
the
the
logging,
but
b
no
longer
would,
if
you
just
reinstalled
in
b,
and
we
edited
the
console.
We
edited
this.
You
know
hard
link
to
essential
store
and
you
didn't
clear
away
the
central
store
and
it
said:
oh,
I
already
have
this
file.
I
can
just
reuse
it.
You
would
just
put
that
console
log
right
back
into
b,
because
it
would
just
be
another
hard
link
to
the
same
central
location,
so
it
it's.
It's
kind
of.
C
It's
got
a
lot
of
weird
little
little
things
to
consider
and
it
may
be
something
to
kind
of
explore
and
do
a
future
rfc
on
or
maybe
a
spike
and
just
see
how
bad
it
is
and
then
rfc
it.
So
we
can
get
like
a
proper
kind
of
spec
and
feedback
about
it.
A
Yeah,
that's
another
thing
actually
getting
down
to
work
and
actually
seeing
how
this
can
be
implemented
on
earth.
Some
answers
to
some
of
these
questions
as
well
for
sure
yeah.
A
So
we
only
have
a
couple
minutes
left
and
I
don't
think
we're
gonna
get
time
and
tierney
is
not
here
to
provide
any
updates
on
the
audio
assertions
rfc
number
422,
which
was
the
last
item
here.
I
was
hoping
just
to
have
a
bit
of
an
update
there.
It's
been
open
for
a
couple
weeks
and
I'm
hoping
folks
are
continuing
to
give
feedback.
A
There's,
definitely
something
we
want
to
do
in
this
space
soon.
So
yeah,
please,
please
continue
to
to
get
feedback
in
in
that
rfc
and
and
this
one
as
well,
but
with
that
we're
essentially
a
time.
So
I
want
to
thank
everybody
for
jumping
on
again
today.
Thank
you,
vincent
for
for
opening
up
this
rc
and
hopefully
we'll
get
to
a
place
where
we
can
actually
do
something
and
and
build
something
that
essentially
is
in
this
shape
or
similar
and
yeah.