►
From YouTube: Open RFC Meeting - Wednesday, July 21st 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
july
21st
2021.
A
A
A
We
just
ask
that
you
please
be
respectful
in
these
calls
and
as
we
discuss
features
and
and
issues
within
the
rfc's
repos
repo,
as
well
as
like
any
npm
repo,
and
if
you
can
please
raise
your
hand
if
you'd
like
to
interject
or
comment
on
these
calls
and
we'll
call
on
you
and
yeah
just
to
be
mindful
of
others
and
please
be
respectful
on
these
calls
apologize
that
we
haven't
been
able
to
meet.
A
So
if
you
haven't,
please
update
the
latest
npm
and
give
us
feedback
on
on
the
work
we're
doing
there
and
we'll,
as
I
said
before,
we'll
be
following
along
in
the
agenda
here.
I
just
wanted
to
open
up
the
floor.
For
anybody,
if
they
have
announcements
around
the.
A
Community,
if
there's
no
announcements,
let's
just
dive
in
the
first
item
that
we
had
was
this
rrfc
by
rebecca-
include
git
head
when
publishing
from
subdirectories.
So
this
is
issue
412,
which
I'll
link
here
and
rebecca
did
you
want
to
maybe
speak
to.
B
To
this
sure
this
this
appears
to
be
actually
pretty
minimal.
I
mean
it
was
a
pretty
minimal
suggestion,
which
is
just
yeah
that
you
know
get
head
is
included
when
you
publish
from
the
directory
that
has
your
package.json.
If
that's
a
get
folder,
if
it
doesn't,
if
the
git
folder
isn't
there,
then
it
doesn't
include
git
head.
So
this
means
publishing
from
workspaces
does
not
get
get
head.
B
This
is
a
and
this
this
actually
ends
up
showing
up
most
commonly
with
publishers
from
pnpm,
because
pnpm
uses
nvm
publish
under
the
hood
anyway
and
yeah.
It
turns
out,
there's
been
a
lot
of
discussion
about
this
and
which
it
seems
pretty
uncontroversial.
In
fact,
there
is
an
open
pr
that
implements
this.
That
was
failing
on
node
four,
but
that's
it.
So
I.
B
D
Right,
oh,
okay,
even
better,
then
I'm
just
just
checking
to
see
if
we
yeah
and
engines
is
node
greater
than
equal
to
10.,
so
yeah
we're
we're
fine.
Let's
look
at
this
anybody
saying
nay
I
mean
the
only
downside
is
we're
gonna
we're
gonna,
be
walking
up
the
folder
path
to
look
for
a
git
repo,
but
like
no
we're
not
we're
not.
E
There's
a
quick
way
to
do
it,
there's
a
get
way
to
do
it.
I
need
to
fix
npm
get
two.
The
is
get
function
is
all
wrong.
This
reminds
me
something
has
worked
on
two
weeks
ago:
okay,
there's
a
proper
way
to
ask
git:
hey
who
are
you
and
are
you
that's
what
we
should
be
doing.
A
D
A
little
tangential
I
remember
there
was
some
reason
why
we
didn't
do
that
in
is
get,
but
we
can
talk
about
that
later.
Yes,
so
that's
then,
if
there's
a
better
way
to
do
it
in
read
package
json,
that's
fine,
but
even
if
it
is
just
walking
up
the
folder
tree
to
find
it
that's
fine,
because
we
only
use
that
the
old
read
package
json
when
we
kind
of
don't
care
about
performance
right,
it's
it's!
We
only
do
it.
For
the
one-time
publish
time
thing,
everything
else
is
using
the
fast
one.
A
I'm
just
taking
notes
here
to
apologize
for
the
delay.
Our
resident
note,
taker
roy
is
actually
on
paternity
leave
now
for
the
next
six
months,
so
I'm
going
to
be
a
little
bit
slower
than
normal,
but
it
sounds
like
the
action.
A
couple
actions
here.
Gar,
are
you
considering
reviewing
the
get
lib?
Is
that
also
like
to
make
this
more
efficient.
E
It
was
a
skit
check.
I
need
to
get
back
to
where
I
was
on
that
train.
That
has
nothing
to
do
with
this
rfc.
Somehow,
in
the
last
two
weeks
when
I
was
doing
all
the
bug
fixing,
I
found
that
bug
in
git
and
I
need
to
find
what
it
was
related
to.
D
Cool,
so
we
can
have
get
do
the
walking
up
for
us
and
get
there's
a
get
rev
parts
that
also
shows
you,
the
the
current
head
shaw.
So.
D
I
don't
recall
what
that
invocation
is,
but
we
use
it
all
over
and
we
use
that
in
the
is
in
the
npm
class
git
repo,
so
yeah,
maybe
read
package
json
should
just
use
npm,
client,
git.
A
Yes,
if
it's
not
already,
okay,
okay,
sounds
good
to
me
cool,
so
we'll
queue
that
up
and
we'll
report
back,
hopefully,
next
week,
if
we've
done
anything
on
that.
A
So
queuing
up
the
next
rfc
we
had
issue
number
411.
This
is
a
discussion
around
and
I'll
paste
it
here.
Npm
in
it
should
initialize
a
git
repo.
I
know,
jordan,
you
had
some
comments
back
to
the
original
poster.
Raffy
did
you
maybe
wanna
speak
to
this
a
bit
in
terms
of
your
your
concerns
around
having
npm
in
it
essentially
initialize
gear
repo.
At
the
same
time,
it
creates
the
package
json.
F
Yeah
I
mean
I,
I
can
imagine
that
there
are
workflows
where
this
is
convenient,
certainly,
but
the
workflow
I
use
for
creating
my
many
many
packages
does
not
particularly
benefit
from
it.
That
doesn't
alone,
of
course,
have
any
impact
on
whether
it
would
be
useful.
A
D
There's
I
mean
there's
two
two
things
there.
The
first
is
like
gar
was
talking
about.
We
can,
we
can
use
the
npm
cloud.
Get
you
know
is
get
method,
so,
if
you're
already
in
a
sub
in
a
subdirectory
of
a
repo
we'll
just
not
do
that,
because
we
can
tell
that
you're
already
in
a
repo.
Second,
we
can
also.
We
can
also
check
in
a
number
of
places
whether
or
not
you
have
get
installed
on
your
path.
D
D
Initializing
I
mean
initializing
the
remote
like.
I
would
actually
like
it
to
go.
The
full
the
full
bore
and
also
say
like
also
set
the
remote
origin
to
you,
know
github.com,
whatever
the
name
of
the
thing
is,
but
I
could
do
that
in
my
own
init
script.
I
don't
have
to
necessarily
haven't
given
it
to
it.
E
A
So
somebody
can
create
a
template
package
like
create
package
with
and
get
or
something
like
that,
and
then
you
do
npm
see
like
how
many
people
like
that
behavior.
I
guess
like
npm
in
it,
but
like
it's
hard
to
get.
A
We
could
just
pull
it
as
well
and
see
how
many
people
are
actually
initialized
to
essentially
npm
in
it
and
then
do
get
in
it
right
after
that,
or
vice
versa,
even
and
and
just
see
like
you
know
how
many
people
are
doing
this
on
average,
if
that's
a
common
workflow,
yeah
yeah
like
cars,
saying
npm
kit
in
it,
you
know-
and
people
running
mp
a
minute
and
then
and
using
one
of
those
initializers
packages
to
like
do
this,
for
you
like
that's
an
option
for
them
today,
but
yeah.
A
And
give
the
link?
Is
it
just
called
npm
init
kit.
D
Yep
so
feature
request.
Let's
sure
sounds
good.
I
mean
the
way
that
we
say
if
you
submitted
a
patch
we
would
accept
it
is
we
approve
and
ratify
this
rfc
and
somebody
gets
to
it.
It
doesn't
have
to
be
necessarily
high
priority
or
you
know
the
next
thing.
The
core
team
is
working
on
yeah,
but
you
know
one
of
us
might
pick
it
up
as
a
small
mosquito
task.
At
some
point.
That's
fine.
D
A
This
is
so
this
just
want
to
make
sure
this
is
just
a
comment
like
a
request
for
request
for
content
right,
like
it's
just
a
conversation,
so
it
hasn't
been
even
proposed.
That's
like
an
rfc
where
we're
saying
you
know
this
is
where
we
something
we
accept.
So
next
steps
here
could
be
even
what
you're
saying
jordan
like.
A
Can
you
write
an
rc
for
the
fact
that
we
have
a
preference
for
get
and
that
commands
will
most
likely
prefer
to
initialize
or
interact
with
git
version
management
like
that
could
be
a
potential
like
action
or
comment
back
to
this
person
alongside?
If
you
want
to
see
this
feel
free
to
make
a
pr
happen,.
D
Yes,
I'm
saying
thumbs
up
to
your
request
for
request
for
comment.
Go
for
it
sounds
fine.
We
don't
really
need
to
keep
talking
about
it.
A
And
is
ryan
on
the
call
yep
yeah,
I'm
I'm
here
awesome.
You
want.
H
H
Yeah
yeah,
so
this
is
essentially
this
stems
from
some
use
cases
revolving
around
needing
some
code
to
run
prior
to
dependencies
being
installed
going
back
to.
As
far
as
from
my
recollection,
like
npm
version
3,
the
pre-install
hook
had
would
run
prior
to
dependencies
being
installed,
but
as
of
version
seven,
that's
no
longer
the
case.
I
think
that
there's
been
a
lot
of
discussion
around.
You
know
if
it's
a
bug
or
if
it's
not
a
bug,
but
I'm
not
here
to
discuss
that.
H
I
just
want
to
make
sure
that
we
have
a
path
forward
for
any
consumers
of
mpm
who
need
to
run
a
script
before
dependencies
are
then
installed.
D
So
I
think
I
think
your
versions
might
be
a
little
off,
so
the
pre-install
scripts
being
run
prior
to
the
existence
of
any
dependencies
has
never
really
been
a
guarantee,
and
you
know,
even
even
in
npm
1.0,
some
of
your
some
of
your
packages
dependencies
right
when
we're
doing
like
the
legacy.
Bundling.
D
Always
some
of
your
dependencies
might
be
deduplicated
up
to
a
higher
level,
and
so
they
would
of
course,
be
there
before
your
package
gets
installed
because
they're
at
a
shallower
point
in
the
tree,
the
what
it
and
so
pre-installed
back
in
those
days
was
sort
of
run
in
this
state.
Where
your
dependence,
some
of
your
dependencies,
may
exist,
but
none
of
them
are
guaranteed
and
I
think,
with
npm3
it
got
to
rebecca
is
on
the
call
would
probably
remember
better
than
I
do.
D
The
the
the
behavior
was
it's
still
indeterminate,
but
because
we're
deduping
up
front,
more
of
them
are
more
likely
to
have
already
been
unpacked
and
in
npm
five
or
six.
I
think
it
was
shifted
to
just
be
like
look
we're
just
going
to
unpack
everything
and
then
we're
going
to
pre-install
everything
and
then
we're
going
to
install
and
post
install
everything
and
with
npm
7.
That's
that's
how
it
works
now.
So
I'm
I'm
kind
of
curious.
D
I
guess
sort
of
the
overlap
or
the
intersection
between
this
and
a
top
level
sort
of
tree
mutation.
D
Script,
life
cycle
event,
in
other
words,
so
would
pre-unpack
happen
like
you
have
an
example
of
it
in
a
in
a
in
a
top
level
app.
But
if
I
install
that
module
as
a
dependency
does
pre-unpack
run
before
it
gets
unpacked.
F
D
It's
answered,
I
understand,
I
understand,
and
I
agree,
and
that
makes
a
ton
of
sense.
Another
thing
that
is
understandable
and
makes
a
ton
of
sense
and
is
a
hundred
percent
contradictory
to
that
is
that
people
use
their
dependency
scripts
in
their
pre-install
script
and
in
their
install
script.
So,
like
I
mean
okay,
that's
great,
but
if,
when
we
had
it
working
that
way,
the
common
complaint
was,
you
know.
Why
isn't?
Why
isn't
eslint
present
for
me
to
run
a
lint
prior
to
install
like,
and
it's
just
like?
I
F
F
A
E
Ships
sailed,
we
just
need
to
that
needs
to
just
absorb
into
people's
brains
that
it
means
it
runs
before
the
install
script.
We
can
fix
it
innate
sorry.
I
like
the
idea
of
this,
gets
us
towards
what
we
want,
which
is
having
these
mental
models
of
this.
These
are
the
scripts
that
run
before
I
have
my
dependencies
and
these
are
the
scripts.
E
I
have
a
run
after
my
dependency,
so
I
like,
I
don't
know
that
the
name
needs
is
you
know
what
we
want,
but
I
the
the
solution,
should
be
that
we
are
pushing
towards
having
this
model
of
I'm.
These
scripts
run
outside,
like
the
context
of
all
of
my
code,
even
like
this
is
gonna
happen
during
the
install
process
before
I
can
access
my
real
code
right,
so
I
can
set
things
up.
My
code's
gonna
run
after
this
versus
my
code's
ready.
I
could
run
eslant
right
and
that's
what
pre-install
is
today.
E
So
I
I
really
like
the
direction
this
is
going
and
that's
kind
of
what
we
need
to
have
in
our
minds
as
we
as
we
talk
through.
This
is
helping
with
that
problem
of
now.
We
have
these
mental
models
of
code
that
runs
before
anything
happens
in
code
that
runs
and
what,
where
the
mental
model
of
where
pre-install
currently
runs.
H
H
That's
fine,
but
I
can
we
have
a
method
of
doing
like
you
can
still
work
around
that,
whereas,
when
you're
trying
to
do
a
pre-install,
where
no
you
know
run
something
before
depending
dependencies
are
installed,
there's
no
real
way
to
hack
or
work
around
that
so
like
in
npm
six.
We
would
be
able
to
use
the
pre-install
script
npm,
seven,
we're
not
able
to
if
it's
something
that
needs
to
run
before
the
dependencies
like
in
the
case
of
getting
like
private
repository
details
from
like
a
cloud
provider.
D
D
D
In
other,
in
the
sense
that
they
happen
at
different
phases
in
the
process
right
if
we
want
to
be
and-
and
maybe
maybe
there's-
maybe
there's
two
life
cycle
events
to
add
here-
like
that's,
maybe
fine
in
both
of
those
cases,
though,
there's
no
way
that
you
could
access
your
depths
because
they're
we
haven't
even
resolved
them
right
or
we
haven't
unpacked
them
right.
Some
of
them
may
be
present,
you
know
and
then
there's
if
it's
if
it's
before
we
even
unpack
this
step.
D
A
B
D
So
for
the
top
level,
arborist
does
not
concern
itself
with
the
top
level
scripts.
That's
entirely
done
in
the
claw.
B
D
Let
me
just
look
I
I
don't
want
to
rely
on
my
meet
me
brain,
so
we
run
yeah.
We
run
all
of
them
after
reification,
so
the
how
it
differs
from
post
install
is.
It
runs
before
the
install
event
like
it's
just.
We
run
a
bunch
of
stuff
once
we've
reified
the
tree.
Okay,
the
reason
being
that
again,
like
because
of
the
complaint
that
I
want
to
run
linting
on
pre-install.
D
Or
or
you
know
more
or
more,
you
know
less
in
a
less
silly
example.
In
order
for
my
in
order
for
my
bin
script
to
exist,
I
have
to
run
this
command
to
build
it
right,
and
so,
if
you
try
to
link
my
bins
before
my
pre-install
script
happens,
it's
not
going
to
work
and
my
pre-install
script.
In
order
to
build
that
that
executable
file
has
to
use
one
of
my
dependencies
right,
I
have
to
use
webpack
or
something
or
babel.
I
guess.
H
The
idea
is
that
if
I
wanted
to
lint
or
something
like,
I
have
a
hook
available
to
do
that
like
I
can
do
that
in
the
install
script
or
I
can
you
know,
I
have
a
path
forward
on
that,
whereas
if
I
need
to
go
forward
with
something
from
like
an
application
level,
if
I
do
npm
install
if
I
need
to
go
forward
with
something
that
runs
before
my
dependencies
are
resolved,
that
used
to
be
pre-installed
now,
in
version
seven
I
mean
I'm
not
saying
it
was
like
the
you
know,
it
was,
you
know
best
practice,
but
that's
something
that
we
have
grown
dependent
on
from
previous
versions.
F
Yeah,
I
just
I,
I
think
we're
asking
the
wrong
question
here.
The
name
determines
where
it
when
it
runs.
If
we
want
it
to
run
in
a
different
place,
we
need
a
different
name.
There
is
no
ambiguity,
if
you,
if
you
narrow
to
app
use
case
versus
depth,
use
case
in
each
of
those
two
use
cases,
there's
no
ambiguity
about
when
it
runs,
I
think
to
because
a
user
is
typing
the
script,
so
the
user's
mental
model
applies.
Pre-Install
runs
before
install
like
I,
I
don't.
F
I
can't
see
how
that's
debatable
and
like
in
the
app
case
and
in
the
depth
case.
I
haven't
thought
about
it.
I
don't
know,
but
like
I
think
that
that
yeah,
that
we
should
always
be
looking
at
well
yeah.
So,
as
far
as
the
the
install
script
is
tricky
because
I've
tried
to
use
it
and
it
doesn't
work
historically
like
it,
I
don't
remember
if
it
breaks
the
install
entirely
or
if
it
just
ignores
my
install
script
or
whatever.
F
But
it
like
doesn't
do
what
I
it
didn't
do
what
I
expected
it
to
do,
but,
regardless
of
history
and
regardless
of
the
path
from
here
to
the
ideal
state,
I
think
the
ideal
state
should
be
that
two
things.
It
should
be
clear
when
looking
at
a
script
and
package
json,
whether
it's
going
to
run
when
I'm
being
installed
elsewhere
or
when
I'm
installing
my
things
app
use
case.
F
So
we
had
this
conversation
a
number
of
rfcs
ago,
where
I
think
gar
was
at
some
point
on
a
I'm
sure.
What's
a
long
list,
you
had
looking
into
like
how
to
sort
of
deconflate
the
app
use
case
versus
the
package
use
case
for
scripts.
I
think
that's
something
we
need
to
solve,
because
I
feel,
like
all
these
questions,
just
kind
of
fall
out
of
that
or
all
these
answers
rather
to
these
questions
fall
out
of
that.
A
Yeah-
and
I
I'm
not
sure
how
long
ago
that
was,
but
I
know
that
there
was
some
effort
to
clean
up
the
docks
that
we
had
around
lifecycle
events
as.
E
Far
as
I
know,
the
docs
reflect
reality
now,
it's
just
that.
We
all
know
that
the
reality
is
without
reading
those
docs
right
that
the
scripts
are
still
ambiguous
and,
honestly,
the
more
I've
thought
about
this-
and
I
know
nelf-
and
I
have
talked
about
this-
the
solution
is
going
to
be
a
new
top
level
attribute
in
the
package
json
that
is
backwardly
compatible.
E
That
allows
us
to
say
all
right.
E
A
E
By
doing
both
by
basically
saying
we
have
these
lifecycle
events
that
run,
but
we
also
are
gonna
run.
If
you
have
a
script
called
start,
we're
gonna,
keep
running
it
for
now
and
the
eight
break
as
we
stop
running
things
in
scripts
during
life
cycle
events,
we
only
refer
to
the
things
in
the
life
cycle
object.
We
could
just
refer
to
scripts,
that's
fine!
But
that's
how
you
get
there
from
here.
So
you
do
both
and
then
the
breaking
changes.
You
drop,
that
one.
D
D
Go
ahead
so
it
sounds
like
you
know,
so
the
problem
with
the
problem
with
having
pre-install
in
the
top-level
app
run
prior
to
calling
arborist.refi
right
six
style
is
that
and
which
I
think
was
originally
how
one
of
the
npm
7
betas
actually
worked,
and
we
found
it
didn't
properly
install
a
whole
bunch
of
projects,
the
reason
being
that
the
the
way
it
happened
in
npm
six,
I
want
to
save
like
the
depths
were
unpacked,
but
then
the
root
one
happened
before
they
got
built
or
something.
D
D
Yeah,
what
we
found
was
that
it
didn't.
We
got
some
some
failures
in,
I
want
to
say
canary
in
the
gold
miner
somewhere
where
it
was
not
able
to
properly
install
packages
and
we're
like
okay,
well,
we'll
just
put
it
put
it
after
the
refi,
but
still
before
all
the
other
things.
The.
D
Yeah,
so
are
we,
then
the
question
is
like:
is
it
worth
adding
a
pre-reification
script
now
in
the
current
structure
of
things,
or
should
that
just
be
or
should
our
task
be
like
garu
is
suggesting,
let's
make
a
list
of
all
of
the
relevant
points
in
the
life
cycle
process
right?
I
am
the
top
level
dep,
I'm
beginning
the
process
of
building
my
ideal
tree,
I'm
beginning
the
process
of
you
know.
Reading
the
shrink
wrap
file
like
all
of
these
things,
where
we
go
step
by
step
through
the
install
algorithm.
D
What
what
is
the?
What
is
the
kind
of
life
cycle
hook
that
we
want
to
fire
there
and
leave
that
apart?
You
cannot
run
those
manually,
like
all
that
they
can
be
is
like
a
command
that
is
right
in
that
spot.
Then
the
the
scripts
can
be
just
sort
of
you
know
your
your
npm
as
a
make
clone
list
of
tasks
that
you
can
run
at
various
times
arbitrarily
from
within
lifecycle
events
or
not,
and
we
have
backwards
compatibility
where
you
know
at
this
particular
life
cycle
event.
D
A
Yes,
so
we
need
an
rfc
for
that.
So
that's
the
action
item
here.
I
think,
if
most
folks
on
the
call
agree
with
that
kind
of
way
forward
that
cars
proposed
this
one.
C
C
If,
if
we're
already
talking
about
having
a
specifically
different
entry
point
for
life
cycle
events
and
leaving
the
old
behavior
for
backwards
compatibility,
maybe
it
should
revert
the
old
behavior
back
to
what
npm
6
did,
because
most
of
the
stuff
that
that's
going
to
rely
on
the
old
behavior
for
an
extended
period
of
time
is
stuff
that
was
created
when
npm
was
six
or
earlier
than
that.
A
D
On
that's
my
that's
my
foggy
recollection,
which
is
probably
at
least
10
percent
wrong.
A
So
now
that
v7
has
been
out
for,
like
yeah
at
least
g8
for
at
least
six
months,
and
some
people
might
be
relying
on
the
how
this
is
operating
today.
Do
we
like
I'm,
not
sure
we
want
to
check.
D
Sure,
but
there's
still
quite
a
quite
a
few
people
using
it,
the
the
real
the
real
thing
that's
being
brought
up
here
and
the
feedback
for
this
rfc
for
for
ryan,
I
think
is,
should
this
you
know
pre-unpack.
Basically,
there's
two
there's
two
separate
life
cycle
events.
I
think
that
we
are
sort
of
talking
about
and
conflating
here.
One
of
them
is
before
beginning
the
process
of
build
ideal
tree
and
the
other
is
before
beginning
the
process
of
reify.
A
H
H
I
know
a
lot
of
npm
users
are
are
relying
on
the
idea
of
pre-install
running
prior
to
dependencies
being
installed,
and
so
I
mean
it's
out
there
and
I
think
that
the
the
user
base
that
you
know
has
this
breaking
change
in
v7
doesn't
have
a
path
forward,
whereas
if
it
you
know
was
the
reason,
the
reasoning
before
was
you
know
somebody
wanted
to
run
linting
or
something
prior.
H
I
think
that
they
still
have
a
way
forward,
whereas,
like
this
use
case
does
not
have
a
way
forward,
so
I
mean
I,
I
think,
if
possible,
we
might
want
to
going
forward,
take
a
look
and
see
why
we
weren't
able
to
reproduce
this
functionality
in
version,
seven.
D
Yeah
at
this
point,
I
think
the
only
challenge
there
is
that,
like
right
or
wrong,
maybe
it
was
a
foolish
decision
at
this
point.
The
moving
pre-install
that
happened,
but
at
the
root
level
prior
to
calling
arborist
refi,
is
going
to
be
a
breaking
change
and
it's
kind
of
like
well.
We
we
made
this
breaking
change,
maybe
even
unintentionally,
going
from
six
to
seven,
but
that
doesn't
necessarily
mean
that
we
can
make
a
breaking
change
within
seven.
You
know
what
I
mean.
H
Yeah
I
and
that's
fair.
I
I
just
I
feel
like
yeah,
it's
a
difficult
situation
to
be
in,
but
if
I
had,
if
I
were
playing
straight
numbers,
I
would
guess
that
the
breaking
change
that
occurred
from
six
to
seven
has
more
of
an
impact
than
if
we
were
to
break
with
inside.
H
D
You
may
be
right,
I
mean
it
may
be
worth
incurring
some
semver
sin
points
in
order
to
improve
lives
of
users.
That's
what
really
matters.
F
B
Yeah,
but
where
are
the
docs
that
cover
this
this
detail,
because
the
the
link
docs
don't
seem
to
discuss
when
it
runs?
It
just
says
the
order
they
run
in
it's.
D
The
scripts
doc
darcy
linked
it
in
chat.
B
D
You're
right,
but
they
don't,
they
don't
specify
the
context.
Yeah.
D
D
A
So,
just
to
be
mindful
of
time,
I'd
love
to
get
a
couple
action
items
and
then
move
on.
I
think
the
one
is
to
one
at
least,
is
to
introduce
or
create
an
rfc
for
this
net
new,
potentially
lifecycle
field.
Lifecycle
events
object
if
we
do
intend
to
move
away
from
scripts,
essentially
having
these
lifecycle
scripts
like
muddy
the
the
scripts
object
and
then
the
second
would
be
essentially
queuing
up.
What
we
believe
is
a
patch
to
existing
pre-install
to
run
and
mimic
the
behavior
of
the
mpm6
lifecycle
event.
A
A
Okay
I'll
write
those
two
down
and
then
we
can
move
on
to
the
next
rc
feel
free.
If
you
had
any
other
comments
to
add
them
to
that
previous
rfc
itself,
the
next
one
was
by
roy
who's,
not
here,
unfortunately,
pr
number
343.
This
is
the
automatically
switching
context
rc.
I
believe
we've
left
this
open
in
while
we're
considering
implementing
the
workspace
some
workspace
root
filtering
within
our
burst
itself.
I'm
not
sure
isaac.
A
D
Yeah,
I
don't,
I
don't
think,
there's
been
any
updates
since
our
last
conversation,
but
where
I
recall,
is
kind
of
landing
on
was
we
add
a
workspace
dash,
root,
config
value
which
will
allow
you
to
specify
the
the
workspace
root
and,
if
you're,
in
a
current,
you
know
if
you're
in
a
directory
that
has
data
that
has
a
workspace
root.
Config
then
it'll
be
like
okay.
D
Well,
I
guess
I'm
a
workspace
within
that
workspace
root
and
if
your
current
working
directory
is
not
a
valid
workspace
within
that
workspace
root
project,
then
I
don't
know
we
throw
an
error
or
something.
Otherwise.
D
We
basically
treat
the
workspace
root
as
the
prefix
and
the
current
working
directory
as
the
workspace
config,
the
the
second
step
of
that
to
make
that
extra
nice
is-
and
there
was
some
some
debate
on
exactly
when
if
we
do
this,
but
we
could
put
a
project
level
npm.npmrc
file
in
all
of
the
workspaces
to
specify
the
workspace
root
as
the
current
working
directory,
we
can
do
that
either
on
initial
on
first
reify
or
on
npm
init
dash
w
and
I
or
both
I
think
either
one
is
kind
of
fine.
D
D
D
D
The
yeah,
the
reason
it
would
get
shut
down
right
what
we
should.
We
should
probably
write
an
rc
for
switching
from
json
to
from
ini
to
json,
but
like
that
should
be
what
yes,
that
should
be
a
one-way
switch.
It
should
not
be
now
we
support
both.
Yes,.
A
If
not,
I
think
we.
B
A
There
cool
the
next
rc
was
273
npm
workspaces,
config
management.
Again
we
haven't
really
moved
forward
with
this.
A
Really
this
essentially
would
be
probably
introducing
a
new
workspaces
sub
command
and
allowing
you
to
quickly
and
easily
add
remove
workspaces.
We
sort
of
introduced
this
behavior
since
npm
init
does
support
workspaces,
so
you
can
essentially
add
you
just
can't
remove
a
workspace
to
your
package.json
easily
and
now
with
the
mpmpkg
subcommand.
You
can
also
sort
of
manage
the
workspaces
field
within
package.json
as
well.
A
So
there's
a
couple
options
there,
but
we-
I
imagine
in
the
future
we
might
want
to
revisit
this
and
flush
this
out
again,
I
think
there's
some
updates
that
need
to
happen,
so
I'm
going
to
remove
the
agenda
label
unless
other
folks
had
comments
for
that.
Rc
specifically,
I
think
it
needs
to
be
updated
based
on
the
work
we've
done
since
it
was
originally
created.
D
Yeah,
I
I
think
this
is
straightforward
until
we
kind
of
get
a
new
champion
for
it,
I
don't
see
it
getting
super
high
priority,
but
you
know
that
that
can
happen.
It's
just
we're
not
likely
to
get
roy
back
in
the
immediate
term.
A
Moving
on
to
the
last
rfc,
we
had
on
agenda
and
hopefully
have
a
couple
minutes
extra
as
well
for
any
other
items
that
we
might
not
have
gotten
to
pr
and
rce1a2.
This
is
the
npm
audit
licenses
tierney.
I
know
you
worked
with
roy
just
before
you
left
a
little
bit
and
you
have
a
pr
drafted.
I
think.
G
Yes,
there's
a
draft
pr
on
cli
it's
by
no
means
done
like
not
even
close,
but
it
has
the
basics
there.
I
need
to
find
some
time
to
continue
working
on
it.
I
think
honestly
roy
got
me
a
pretty
decent
amount
of
the
way
there
on,
like
figuring
out
what
I
need
to
do
to
make
mpmci
work
so
yeah,
if
I
need
help
I'll
ask
but
should
be,
should
be
good
for
now.
I
also
like
I'm
not
unless
there's
a
timeline
for
mpm8.
I
I'm
not.
G
I'm
probably
not
gonna
be
like
aggressively
pushing
this,
but
I'm
I'm
happy
to
prioritize
it.
If
it's
something
that
the
the
cli
would,
the
team
would
prefer
to
be
prioritized.
A
For
sure,
given
that
is
there
any
other
comments
or
any
other
subjects
that
folks
want
to
bring
up
well,
we
have
10
minutes
of
time.
C
C
C
Thanks,
no
rush
just
just
wanted
to
grab
your
attention
and
this
meeting
is
good
for
them
and
I
also
fulfilled
the
last
of
my
action
items
from
a
meeting
like
three
meetings
ago
or
something
where
I
was
to
report
a
an
issue
on
the
cli
for
npm
audit
fix
dash
json
to
return
a
diff,
so
that's
reported,
but
I
I
don't
know
if
well
I
I
might
be
able
to
help
with
that,
but
I
would
probably
need
some
pointers
before
I
can
even
start
and
when
we
last
talked
about
it,
you
sounded
like
in
it's
kind
of
obvious
for
you,
so
I
don't
know
if,
if
I'm
just
gonna
waste
more
time
and
there's
one
more
item,
so
I
linked
to
issues
filtered
by
author.
C
I
hope
the
link
works.
So
the
second
thing
I
reported
is
an
issue
I
found
where
there's
content
missing
in
audit
output
from
npm
seven,
where
there's
via
fields
missing
on
items
that
are
definitely
not
top
level,
and
I
have
one
example
there
so.
A
C
It
can
be
reproduced
on
a
repository
I'll
link,
to
got
that
as
a
report
to
npm
audit
resolver
debugged.
That
found
out
that
my
algorithm
for
figuring
out
the
tree
is
a
bit
naive
and
fixed
it,
but
then
found
out
that
there's
stuff
literally
missing
from
the
output.
A
Thanks
tb,
I've
added
some
notes
there,
capturing
that
and
we'll
follow
up
for
sure
did
any
other
folks
have
any
other
items
they
want
to
bring
up
or
any
other
issues.
A
Feature
requests
got
seven
minutes,
give
you
seven
minutes
back
if
you'd
like
or
six
minutes
now
at
this
point,
awesome
so
feel
free
to
continue
to
submit
prs
and
and
rcs
appreciate
everybody
jumping
on
today
and
we'll
hopefully
see
you
next
week
as
well
and
expect,
as
usual,
a
weekly
release
of
the
cli
to
be
cut
tomorrow,
and
thank
you
so
much
for
jumping
on
and
we'll
see
you
next
week
cheers
thanks.