►
From YouTube: Open RFC Meeting - Wednesday, April 20th 2022
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
we're
live
on
youtube.
Welcome
everyone
to
another
mpm,
open
rc
call.
Today's
date
is
april
wednesday
april
20th,
2022
we'll
be
following
along
in
the
agenda
that
was
posted
at
the
mpm
rfcs
repo
issue,
number
574
and
quick
reminder.
These
calls
and
all
comms
on
the
npm
rfc's
repo
are
covered
under
code
of
conduct.
B
A
I
will
share
the
meeting
notes
stock
feel
free
to
add
yourselves
to
that
as
attendees
and
we'll
be
jumping
in
in
just
a
second
one,
quick
announcement
I
want
to
make-
and
I
shared
I
think,
a
couple
weeks
back,
our
team
has
put
together
a
long
list
of
items
that
we're
hoping
to
queue
up
for
npm
v9.
A
I
guess
one
quick
reminder
as
well:
the
openjs
world
conference
is
coming
up
and
I
know
that
a
few
folks
from
our
team
will
be
headed
down
to
austin
to
to
join
much
of
the
node
ecosystem,
hopefully
in
person
for
the
first
time
in
a
long
time,
and
that
would
be
nice
to
see
some
familiar
faces
and
hopefully
some
new
faces
as
well.
So
that's
in
early
june,
I
believe
it's
june
6th.
Somebody
could
correct
me
if
I'm
wrong,
but
just
wanted
to
make
a
note
of
that.
A
Our
very
own
miles
borns
will
be
speaking
about
supply
chain
security,
which
is
very
relevant
these
days
at
that
conference.
So
quickly,
let's
jump
into
the
agenda,
we
have
here.
The
first
item
that
we
have
was
the
command
specific
configuration.
A
I
believe
you
had
made
the
initial
note
when
I
I
pushed
this
rfc
that
why
the
heck
have
we
not
had
this
for
ever,
and
I
apologize
that
that's
not
the
case,
but
I
was
just
wondering
if
folks,
if
there
was
any
comments
from
last
week
that
were
surfaced,
sort
of
with
concerns
I
I
saw
there
was
a
note
about
holding
off
on
actually
landing
in
this
feature
until
v9,
potentially,
if
we
consider
it
to
be
a
breaking
change,
but.
C
Yeah,
I
mean,
I
think,
the
commentary
that's
popped
up
on
the
issue
since
it's
worth
talking
about
the
like,
for
example
like
np,
when
you
run
npm
publish
it,
runs
npm
pack
implicitly
and
if
I
put
pac-specific
config.
Obviously,
when
I
run
npm
pack
that
should
work,
it
should
run
it
or
should
use
it.
But
if
I
run
npm
publish
should
that
also
use
the
pack
specific
config
and
I
feel
like
my
gut
reaction-
is
yes,
of
course,
npm
publishes.
C
However,
I
say
like
I,
I'm
not
100,
confident
that
that's
actually
the
case,
it's
just
my
intuition
and
the
reason
I'm
not
confident
is
because
the
reason
that
I've
wanted
this
rfc
for
years
is
because
it
is
because
I
actually
wanted
my
invocations
to
use
different
config,
and
I
wanted
that
to
be
reified
in
the
repo
in
npmrc,
so
that
every
developer
in
the
repo
didn't
have
to
think
about
it.
C
And
it's
possible
that
in
my
specific
case,
there's
a
conceptual
difference
enough
that
that
even
if
npm
publish
invoking
npm
pack
uses
tax
specific
config,
even
if
that
velocity
is
applied
everywhere.
Maybe
my
use
case
would
still
be
fine,
but
I
think
it's
worth
like
auditing,
all
of
those
implicit
relationships
of
which
commands
like
in
pre.
C
You
know
invoke,
which
other
commands,
whether
they
actually
do
or
not,
is
irrelevant,
but
like
conceptually
just
to
make
sure
that
that
that,
if
everyone
agrees
with
my
gut
reaction,
just
to
make
sure
that
that
is
actually
the
right
thing
to
do.
A
Yeah,
I'm
I'm
totally
on
board
with
this.
My
comment
back
there
was
about
this
because
I
know
don
brought
it
up.
Dominick.
Yes,
like
I
guess
I
am
interested
in
right
now
and
how
we
handle
this,
because
I
I
I
know
that
there's
specific,
like
boundaries
like
domain
boundaries
that
we
do
cross
like
when
we
are
spawning
like
a
a
new
command
and
I'm
not
sure
if
we
do
share
config
completely
between
those
boundaries.
A
A
good
example
of
that
is
installing
git
dependencies,
let's
say
and
not
passing
along
the
ignore
scripts
flag,
potentially
there's
other
reasons
why
we
may
not
be
wanting
to
share
config
configuration
for
let's
say,
npm,
install
or
some
subsequent,
let's
say,
install
and
test.
Let's
say
you
want
to
add
or
provide
registry
configuration
for
npm
install.
You
do
not
want
that
to
then
be
shared
with
test
so
npm
it
shouldn't.
You
know.
A
A
Let's
say
if
you
want
to
have
configuration
that
will
work
for
both
those
use
cases
which
is
npm,
install
and
npm
pack
and
npm
install
an
npm
test.
Then
you
would
essentially
double
up
on
the
configuration
in
the
npmrc
file.
If
that's
the
way
you
want
that,
I
think
that
would
be
the
most
explicit
way
and
help
ensure
that
there
wasn't
like
any
unknown
sort
of
like
shared
config
across
those
things.
C
You
know
like
potentially
so
like
there's
a
there's
a.
It
is
definitely
more
explicit
and
powerful
to
do
that,
but
it's
also
like
a
potential
huge
foot
gun
because
there
it,
because
there
is
this
inter-relation
like
dependency
web,
conceptually
of
like
a
bunch
of
different
commands
that
conceptually
invoke
a
bunch
of
different
other
ones
and,
like
I
don't
think
anybody
has
all
of
those
in
their
head
like
I
I
would
be.
I
wouldn't
be
surprised
if
half
the
npm
team
didn't
even
know
that
npm
it
existed
right
like
anyway,.
A
Yeah
so
and
sorry
I
I
know,
roy's
got
to
stand
up.
I
I
think
what
you
just
said,
though,
was
I'm
still
suggesting
that
you
can,
when
you
run
mpmit,
it's
going
to
load
the
configuration
for
npm,
install
and
mpn
test,
but
those
separate
would
be
separate
right.
So
if
you
had
npm
it
configuration,
it
wouldn't
be
passed
on
down
to
those
like,
essentially
that.
B
So
I
think
we
also
need
to
map
the
type
of
relationships,
not
only
what
are
the
relationships,
but
also
the
type
because
some
of
them
are
really
tied
together,
like
exactly
like
both
of
them
share
the
internal
liberty
and
exact
modules.
So
it's
basically
the
same
thing
internally,
but
but
yeah
should
it
forward
configs
or
not
yeah,.
A
A
Let's
see
if
I
can
use
a
mermaid
js
to
map
that
make
a
nice
diagram
and-
and
have
it
render
nicely
here
and
mark
down
just
to
make
my
life
a
little
bit
easier,
not
to
have
to
go
between
tooling,
okay.
So
I've
had
an
action
item
for
myself
to
take
this
away.
To
do
this
work
and,
and
potentially
with
the
team,
also
get
some
help
doing
this.
A
I
think
in
general
it's
a
good
exercise,
but
I
would
like
you
know,
as
you
know,
and
could
be
live
somewhere
else
even
entirely
that
kind
of
mapping,
but
I'd
like
to
at
least
attach
it
to
this
work
item,
so
that,
like
it
gets
done
because
something
like
this
often
like
just
lingers
something
like
hey:
let's
go
and
audit
all
the
life
cycle
events.
You
know
it's
like
okay,
but
if,
if
we
attach
it
to
a
specific
work
item,
then
I
think
that
that
it's
actually
going
to
get
done
so
yeah.
C
To
be
to
be
clear,
I
think
it
would
be
a
useful
thing
to
keep
have
an
updated
thing
like
that
around
at
all
times,.
C
A
Okay,
I
I
totally
agree
so
that's
the
next
step.
There
is
to
document
that
and
those
relationships
and
yeah
we
should
have
a
like.
I
want
to
have
a
really
rock
solid,
like
rc
for
this,
so
it's
extremely
clear
like
what
what
config
is
shared
and,
what's
like,
not
essentially
like
so
cool.
A
Moving
on,
I
think,
unless
anybody
else
had
any
comments,
any
other
comments
on
command
specific
config,
no
moving
on
to
one
of
the
more
or
most
another
exciting.
I
guess
rc
that
I've
proposed
here.
This
is
five
six
four
dependency,
selector,
syntax
and
npm
query
command
I'll
reference
it
here
for
folks
and
want
to,
I
guess,
open
up
the
floor
for
some
discourse
on
this.
A
I
know
jordan,
you've,
given
some
feedback,
which
I
haven't
been
able
to
get
to
all
of
it,
but
maybe
you
could
highlight
maybe
a
few
of
the
items
that
you're
really
you
had
questions.
C
Yeah
we
talked
about
this
about
a
bit
last
week.
The
two,
I
think
the
two
main
things
is
the
functionality
for
like
class
selection
makes
perfect
sense
to
me,
but
I
think
the
terminology
is
vastly
overloaded
and
needs
to
be
avoided
very
strenuously.
So
I
think
we
need
to
come
up
with.
I
think
ibm
should
come
up
with
that
with
our
own
names,
for
what
these
things
are.
That
is
completely
distinct
and
separately
googlable
and
learnable
from
css
syntax,
and
it's
fire
css
terminology.
It's
fine.
C
If
we
use
css,
syntax
and
just
say,
css
class
syntax
is
npm,
category
syntax
or
I
don't
know
whatever,
but
I
think
that's
really
important,
because
the
word
class
needs
to
just
stop
being
used
for
things
and
then
the
other
item
was.
C
I
talked
about
eslint
for
as
an
example,
they
have
a
no
restricted
syntax
rule
which
takes
ast
node
selectors,
and
this
by
adding
this
rule
that
allowed
them
to
decline.
A
lot
of
feature
requests
with.
Oh,
you
can
just
use
an
ast
selector
and
a
custom
message,
and
then
we
don't
need
to
make
a
rule
for
it,
which
is
good.
C
But
I
do
worry
that
there
that
will
create
a
world
where
the
npm
team
sees
the
marginal
utility
of
adding
a
specific
command
versus
telling
people
to
just
use
a
query.
An
npm
query
command
is
so
small
that
a
bunch
of
important
new
commands
might
not
be
added
in
the
future.
D
Go
ahead
turn
I
yeah.
I
definitely
want
to
speak
to
that.
I
I
could
totally
see
where
that's
coming
from,
and
I
I
I'm
trying
to
look
at,
at
least
in
a
very
different
way
where
I
see
this
is
a
very
good
way
to
begin
to
prototype
things
and
find
what
can
be
added
much
faster
and
significantly
reduce
the
barrier
to
adding
those
things.
So,
for
example,
the
you
know
the
audit
licenses
stuff
the
way
the
the
query
language
is
defined
right
now
that
could
be
added
with
an
alias
to
a
query.
D
I
I
think,
that's
an
important
thing
and
I
think
that's
a
good
distinction
to
making
not
necessarily
commitment
but
like
understanding
of
where
the
team
stands
on
that,
I
I
think
it's
really
good
to
have
and
yeah
I
I've
been
assuming
or
operating
under
the
assumption
that
that
kind
of
thing
will
shift
more
often
faster
and
so
yeah.
I
I
guess
I
would
also
like
clarification
on
that,
but
my
you
know
in
talking
with
darcy
about
this
and
stuff.
D
My
assumption
is
that
it
is
kind
of
the
we'll
be
able
to
ship
stuff
faster
now,
so.
A
Yeah,
if
we
have
to
add
that
to
the
rfc
explicitly
to
say
this
is
to
expedite
the
evolution
of
and
sort
of,
you
know,
determination
of
what
information
is
important,
that
we
make
top
level
commands
and
alias
sort
of
these
things,
because
we
don't
want
to
make
it
harder
and
we
also
don't
want
to
have
a
unbound
top
level
alias.
So
that's
that's.
What's
we?
That
is
what
we've
pushed
against
for
a
long
time
against
right.
B
A
Yarn
strategy
of
of
not
controlling
our
top
level
sub
commands
and
that
name
space
so
we're
we
are
mindful
about
what
does
eventually
become
an
subcommand
and
that
this
at
least
allows
sort
of
at
least
unlocks
a
new
ability
for
for
the
community
to
self-serve
in
a
lot
of
cases
and
then
come
to
us
and
propose
you
know
new,
you
know
standard,
you
know,
queries
that
should
exist
and
shouldn't
have
to
be
copy
and
pasted
everywhere,
but
yeah.
C
C
My
concern
is
that
the
exi,
the
fact
that
npm
query
exists
would
be
used
as
effectively
as
a
reason
alone,
why
not
to
add
a
sub
command
and
if,
if
the
npm
team
is
willing
to
effectively
commit
to
not
ever
using
that
as
as
as
a
reason
not
to
do
it,
there's
plenty
of
other
reasons
not
to
add
a
new
sub
command
right
like
and
those
already
are
there
and
those
will
be
there
with
or
without
mq
of
gray.
C
I'm
just
saying
I
don't
want
the
rubric
for
top
level
sub
commands
to
change
like
like,
in
other
words,
for
npm
audit
licenses.
Should
we
add
it
is
one
question:
how
do
we
add?
It
is
a
different
question.
I
completely
agree.
Npm
query
answers
the
second
one
in
a
very
dissatisfying
way.
I
want
to
make
sure
it
doesn't
affect
the
first
one.
A
I
do
not
like
the
idea
of
like
grandfathering
anything
or
grand
grandparenting
anything
into
into
existence
which
creates
us
like
like.
Why
do
we
like?
What's
special
about,
let's
say,
test
and
and
yeah?
You
know
et
cetera,
so
I'm
totally
okay
with
us,
adding
into
the
criteria
here
that,
like
we
have
some
sort
of
it
almost
sounds
like
a
separate
rc
or
like
a
separate
like
how
we
do
make
decisions
that
that
hasn't
documented,
but,
like
I'm,
okay
with
us,
saying
that
this
will
never
affect
our
decision
making
around.
C
A
That
does
or
doesn't
have
certain
capabilities,
and
that
is
something
that
we've
struggled
with
with
exactly
the
question
of
should
or
shouldn't,
we
add
a
new
command
to
npm
we've.
We
have
a
slow
process
here
with
the
rfc
process.
If
we
give
you
the
tool
to
essentially
go
write
some
command
to
unlock
that
information
for
yourself
and
self-serve,
like
you
know,
this
is
going
to
it's
obviously
going
to
ex
like
expand.
A
How
many,
how
often
folks
are
asking
us,
can
you
just
alias
this
one
thing,
and
so
it's
not
that
I
I
yeah
I
just
want
to
be
mindful
like
we're,
locking
ourselves
into
saying.
We
know
we
like
won't
use
the
fact
that
you
can
do
that
with
npm.
Query
is
a
reason
why
we
would
say
no,
but
we
are
definitely
going
to
see
expanded
totally.
C
Yeah,
like
I'm
and
I'm
I
yeah
all
I'm
asking
for
is
for
the
rubric
to
be
unchanged,
not
for
it
to
be
loosened
or
or
tightened,
and
my
I
just
wanted.
If
I
didn't
say
anything,
my
concern
would
be
that
it
would
inherent
implicitly
be
tightened,
and
I
didn't
want
that,
but
yeah.
I
agree
with
I'm
happy
to
hear
all
those
expectations.
C
That
would
be
an
ideal
outcome
and
you
know
I'm
not
looking
to
see
an
explosion
of
sub
commands.
I
just
don't
want
to
close
off
potentially
useful
ones
that
might
come
up
in
the
future
cool.
A
Yeah,
I
still
see
there
being
a
like
yeah
future
for
like
more
sub
commands
that
are
similar
to
let's
say
list
outdated,
update
and
like,
like
all
that,
all
the
ones
that
we
expect
that
we
can
alias
and,
like
essentially
shell
out
to
the
new
query
capabilities.
A
There
was
one
thing
that
I
did
want
to
note.
That
was
brought
up,
I
think
by
yourself,
jordan,
as
well,
which
I
I
wanted
to
speak
to
and
maybe
speak
about.
So
there
was
the
the
class
syntax,
the
class
sort
of
understanding
of
which
classes
were
are
available
to
end
users,
because
essentially
there
is
no
like
there's,
no
actual.
Like
user-generated
content
there,
the
beyond
that,
there's
also
the
understanding
of
anything
that
exists
within
a
package.json.
A
It
will
be
available
to
you
to
do
attribute
selection
and
within
the
rfc.
I
explicitly
came
up
with
during
a
pairing
session
with
roy
came
up
with
an
idea
to
allow
you
to
iterately
select
attributes,
and
this
is
through
a
almost
pseudo
selector
syntax,
which
expands
upon
like
did
some
like
some
sort
of
known
patterns
within
css
for
pseudo-selectors,
but
gives
you
the
ability
to
essentially
select
array
values
and
also
objects
or
array,
arrays
of
objects
and
their
values.
And
so
the
one
thing
to
note
there
is
that
we've.
A
A
I
think
that
I
saw
some
questions
around
that,
but
I'm
not
sure
if
other
folks
have
seen
or
read
that
specific.
C
Area
yeah,
I
mean
my
main.
I
think
the
main
alarm
bell
that
I
was
asking
the
question
about
was
in
the
same
way
that
tests
start
stop
and
a
few
other
build
or
a
few
other
commands
are
like
or
a
few
other
npm
scripts
are
special
because
they
have
top
level
sub
commands
and
they
arguably
shouldn't
be
the.
I
don't
want
to
see
a
world
where
some
things
are
special
and
other
things
aren't,
and
so,
if
we're
going
to
bless
specific
package
json
fields,
then
I
think
that
the
it
becomes
in
any
way.
C
Even
if
there's
a
escape
hatch
for
everything
else,
then
I
think
that
it
becomes
incumbent
on
npm
to
like
it
would
become
incumbent
on
to
actually
like
have
a
pretty
expansive
list
of
known
package.
Json
fields
and
that's
a
long
list.
Node
looks
at
a
few
typescript
looks
at
some
bundlers
look
at
some
like
there's
just
a
long
and
so,
and
that
seems
to
be
not
a
scalable
approach,
and
so
it
seems
like
it
would
be
better
to
come
up
with
something
where
no
attribute
names
are
special.
C
And
if
you,
you
know,
if
you
have
brackets
or
quotes
or
whatever,
but
like
all
of
them,
use
that,
even
though,
like
the
ones
even
like
name
and
version,
even
though
those
are
special
right
like
just
because
then
that
then
it
is
an
intentionally
unbounded
and
egalitarian.
Set
of
package.
Json
attribute
names
and
there's.
A
C
A
A
So
essentially
that
would
create
a
pseudo
pseudo
class
with
a
bracket
notation
that
you
would
then
pass
the
selector
so
so
take
what
I
was
speaking
to
before
the
the
the
syntax
that
we
are
have
coupled
together
here
for
selecting
array,
arrays
of
values
and
doing
attribute
selection
in
that
way
and
put
that
into
and
nest
it
essentially
in
this
adder,
which
is
an
attribute
pseudo
pseudo
class.
C
If
those
have
you
know,
sort
of
blessed
specific
package,
json
fields
like
name
or
version
or
dependencies
or
whatever,
because
those
are
kind
of
always
inherently
a
part
of
npm
but
like
when
you're
doing
that
you're
using
special
syntax
you're,
not
typing
name
in
a
different
way,
then
you're
typing,
like
jordan
right
or
whatever
package
json
field
you
want
and
so
like.
C
I
think
it's
okay
to
have
some
differentiation
there,
because
it's
npm
and
you
can't
get
around
that,
but
I
want
it
yeah
like
so
you
that's
fine,
but
if
there
was
another
like
let's
say
you
were
gonna,
do
like
hash
low
dash
at
1.2.3.
C
A
It's
like
yeah
yeah,
so
just
provide
two
examples
in
chat.
The
current
one
is
how
we
are.
We
originally
have
this
documented.
So
just
like
a
css
attribute,
selector
selector
here
it's
the
key
and
then
the
value
and
in
the
case
of
what
we're
I
would
be
recommending
in
the
future,
would
be
utilizing
a
pseudo
class
like
at
like
the
attribute
pseudo
class.
A
That
would
then
take
that
exact,
same
attribute
selector,
as
as
its
value
and
match
to
that,
and
the
interesting
part
here
is
that
this
could
then
we
could
use
essentially
the
same
generic
pseudo-selector,
not
sorry,
not
a
generic
pseudo
selector,
but
the
generic
like
array
and
object
selection
inside
of
that
which
I'll
reference
here
for
folks.
C
It's
I
I
I
in
other
words,
I'm
I'm
fine
if
there's
special
selector
syntax,
that
happens
to
mean
a
field
name
without
mentioning
it.
But
if
a
field
name
is
actually
present
in
the
query,
then
I
think
all
field
names
should
be
done
the
same
way
so
like
name
if
you
type,
if
you
have
the
word
name
there
in
the
query,
meaning
the
attribute,
it
should
look
the
same
as
any
random
attribute
you
can
come
up
with.
A
Yeah-
and
I
would
say
that
I
see
right
now
and
what
we're
talking
about,
I
see
right
now,
a
problem
with,
like
essentially
name
space,
a
name
space
being
clobbered
in
the
generic,
like
the
way
that
I
propose
the
generic
attribute
and
object
sort
of
an
array,
selection
value
selection,
so
that
needs
to
be
solved
for
so
I
I
do
think
that
the
nesting
actually
helps
like
having
a
a
a
blessed
attribute.
A
Selector
query
selector
would
actually
solve
some
of
the
generics
problem
with
that
I
have
I'm
seeing
here,
but
then
we
could
still
have
top
level.
We
can
have
both
of
these
things.
I
guess
is
what
I'm
saying
they
both
would
could
work
and
live
alongside
each
other,
just
that
the
top
level
only
works
for
known
values,
potentially
like
the
known
what
the
keys
that
we've
essentially
described
here
today
and
in
the
future,
we
could
potentially
bless
future
keys
that
we
know
live
in
package.json.
That
also
could
be
utilize.
A
Yeah
there
it
seems
like
there's
an
edit
that
needs
to
be
done
here,
as
I
guess,
that's
what
I'm
saying
for
sure
awesome
did
anybody
else
have
any
other
feedback
they
want
to
give
to
this
proposal.
A
If
not,
we
can
move
on
then
so
I'll.
Take
the
action
item
to
update
this
based
on
some
of
that
feedback
to
try
to
solve
this.
This
one
one
issue
that
I
know
exists
and
also
to
outline
the
fact
that
the
introduction
of
npm
query
should
not
affect
essentially
our
our
decision
making
for
future
top
level
commands
and
and
explicitly.
You
know
with
that:
okay
moving
on
to
rrfc
559,
so
expanding
the
behavior
of
before
I'm
not
sure.
A
If
this
was
spoken
about
last
week,
I'm
not
sure
if
you
folks
took
some
time
to
talk
about
this
yeah.
C
I
think
my
thought
is
my
thought
was
that
currently
it
has
the
nice
symmetry
of
whatever
you
can
pass
to
new
date
in
javascript
is
what
before
supports
and
that's
it,
and
so
it
always
works
that
way
and
that
there's
a
new
date
object.
Temporal
new,
like
it's
like
seven
or
eight
new
objects
coming
to
javascript
at
stage
three.
C
C
Things
like
I
don't
know,
there's
there
are
standards
for
how
to
how
to
describe
those
things
and
temporal
uses
them,
and
I
don't
think,
like
I
don't
know
it
seems
worth
just
exploring
that
and
making
sure
that
like
it
would
be,
it
would
be
a
fine
symmetry
if,
before
it
takes
anything,
you
can
pass
a
new
date
or
anything
you
can
pass
to
this
temporal
method
right
like
and
if
it
allows
for
the
same
relativity.
C
But
I
don't
know
if
that
would
have
the
same
consistency
with
the
unix
date
command
either,
so
it's
just
kind
of
a
tricky
place
to
get
into
that.
So
that's
all
I
brought
up.
A
A
Right
so
whatever
from
essentially
could
support
is
sort
of
maybe
what
we
should
be
supporting
with
any
changes
here
or
any
kind
of
new
net
new
flag
that
would
kind
of
affect
before
right.
So
before
and
from
you
know,
I
don't
know,
that's
that's
how
I'm
seeing
it,
but
I'm
aligned
with
you
in
terms
of
like
we
should
probably
do
something.
That's
bespoke
and
try
to
align
with
what's
going
to
land
right
and.
C
Then
I
re-reading
it.
The
other
concern
I'd
had
was,
I
think
miles
came
up
with
this.
After
there
were
a
few.
There
was
a
one
user
request
in
particular
where
they
wanted
to
essentially
permanently
time
delay
all
their
installs.
So
everything
is
installed
as
if
it
were
a
week
ago,
at
all
times
and
the
in
the
hope
for
the
user,
which
you
can
do
with
before
you
just
have
to
there's.
C
You
have
to
dynamically
come
up
with
the
value
and
before
a
relative
here
would
let
you
permanently
enshrine
this
in
npmrc
and
their
reasoning
was
oh
well.
If
I
wait
a
week,
then
the
all
the
vulnerabilities
will
have
been
caught
by
then
right
and
that's
only
true
when
most
people
aren't
waiting
a
week,
meaning
if
we.
C
If,
if
we
add
this
feature,
somebody
will
write
a
blog
post
saying
do
this
in
your
npmrc
and
all
the
vulnerabilities
will
be
caught
before
you
do
it
and
then
at
some
point
enough,
people
will
do
it
and
it
will
now
take
seven
days
instead
of
one
hour.
You
know
one
day
to
catch
all
the
vulnerabilities,
so
you
know
all
being
in
air.
Quotes
so
that's
worth
thinking
about?
Is
that
like?
What's
the
is
the
use
case.
C
That
like
how
could
the
use
case
be
abused
right
and
certainly
I've
had
the
like.
It's
nice
to
be
able
to
say
like
one
day
ago
two
days
ago
and
I've
had
to
manually
edit
the
date
to
like
get
what
I
want
and
I
don't
even
know
how
to
use
the
unix
date
command.
So
that
would
have
probably
been
easier
but
like
so
I
see
the
benefit
there,
which
I'm
not
sure
if
the
risks
are
are
going
to
be
worth.
It.
A
Yeah
I
I
guess
the
risk,
though,
is
that
the
community
at
large
begins
to
have
a
pattern
of
behavior
to
which
they
could
do
today
as
well
through,
like
even
like,
because
you
can
do
this
not
not
easily,
but
you
could
still
be
doing
this
like
it
is
possible
utilizing
before
right
to
have
a
relative
time
stamp
generated
for
you.
It's
just
not
like
you
like.
I
guess
I'm
saying,
is
it's
just
not
that
easy.
So
what
is
the
risk
really
made
worse
by
making
it
a
little
bit
easier
to
add
this
in?
A
So
I
I
I
I
thought
actually
my
concern
with
this,
with
the
framing
that
this
is
installing,
specifically
the
framing
that
before
helps
you
install
packages
as
if
they
were
a
week
ago.
My
concern
with
this
feature
is
that
that
is
just
not
true,
because
there
are
mutable
packages,
potentially
within
your
graph,
that
references
to
tar
files
references
to
get
apps.
A
C
I
mean
it's
only
for
registry
depths,
but
I
think
that
the
occurrence
of
non-registry
depths
in
a
graph
is
pretty
rare
and
so
like.
I
agree
with
about
the
risk
of
like
propagating
that
misunderstanding,
but
I
also
think
it's
not
in
practice
that
big
a
difference
but
the
to
be
clear.
What
I'm
saying
is
with
before
right
now,
you
can't
put
anything
in
your
npm
rc
that
just
works
and
sticks
you
to
a
week
ago.
You
have
to
hard
code
a
date
and
the
because
you
can't
interpolate
the
date
value
in
the
npmrc.
C
A
I
mean
other
than
passing
it
always
in
the
command
line.
But
yes,
you
can't
do
it
today
with
the
npmrc
file
right
so
and
yeah,
I'm
totally
okay
with
this.
Otherwise,
though,
like
like,
I
don't.
Actually.
I
actually
think
that
you
know
sure
this
adds
some
value.
I
guess
my
again
my
concern
with
the
was
saying
I
I've
seen
many
references
to
not
registry
depths
in
graphs,
so,
like
my
like
that's
my
my
take.
A
Is
that
actually
that's
way
more
prevalent
than
folks
think
it
is,
and
that's
way
scarier
for
for
folks
and
and
should
be
much
more
on
the
radar
of
our
team,
at
least
to
be
helping,
try
to
to
to
make
the
community
aware
that
that
certain
tools
that
we
build
and
features
that
we
build
only
work
in
cert
like
for
certain
types
of
dependencies
and
certain
types
of
packages,
and
that
you
know
if
you're,
if
you
are
reliant
on
you,
know,
tar
or
like
tar
references
or
like
kit
depths
like
you're
you're
you're
in
trouble.
A
C
A
I
think
it
sounds
like
a
good
rfc.
A
Yeah,
so
part
of
this
does
go
back
to
the
npm
query
discussion
right.
So
if
you
could
easily
write,
npm
query
type
get
or
not
not
type
whatever.
We
have
like
six
known
types
that
we
define
with
npm
package
arc
and
you
could
essentially
enumerate
quite
quickly
with
empty
inquiry,
which
you
know
and
be
able
to
find
out
which
packages
do
or
don't
are,
are
aren't
you
know
githubs
or
director
references?
A
So
so
yes,
let's
take
the
action
item
to,
I
think,
do
that
separately
from
this
and
then
in
terms
of
action
items
for
this
proposal.
I
think,
because
it's
an
rfc
we
ask,
can
ask
either
miles
or
whoever
is
picking
up
this
woolwork
to
create
an
actual
rfc
with
the
proposal
for
the
flag,
ideally
trying
to
mimic
any
kind
of
temporal
implementation,
specifically
the
probably
the
from
syntax.
Whatever
is
supported.
A
There
would
make
sense
to
me
because
we
would
essentially
be
using
the
current
date
time
as
the
as
as
the
initial
new
date
and
then
using
from
to
essentially
well.
C
A
I
know
that
both
both
of
these
items-
even
the
next
one
as
well,
was
related
to
your
improvements
to
before
we've
kept
both
of
them
on
the
agenda,
but
they're
pretty
much
tied
together,
ideally
we'll
close
close
both
once
we
have
an
rfc
cool
moving
along.
We
have
about
15
minutes
left
to
rrfc
548.
A
A
And
I
don't
know
if
this
was
brought
up
last
week,
but
I
know
we
did
speak
about
it.
A
couple
weeks
back.
I
didn't
know
where
we
netted
out
in
terms
of
support
for
this,
I'm
not
sure
if
luke
you,
you
potentially,
I
think,
we're
speaking
up
at
that
point.
Maybe
not.
A
I
don't
think
I've
seen
this
one
yet
so
yeah.
So
this
is
a
idea
of
almost
like
there's
pipelines,
not
pipelines,
but
yeah
like
essentially
to
run
run
a
script
or
run
a
build.
You
might
have
a
sort
of
a
chain
of
dependencies
that
need
to
be
built
before
that.
You
can
actually
execute
that
script
within,
like
your
workspace,
for
example,
and
so
I
think
in
lerna
they
had
a
flag
called
include
dependencies
that
could
be
passed
when
you
were
running
that
script.
C
Yeah
the
so
I
guess
two
weeks
ago,
I
posted
this
comment
saying
that
it's
sort
of
like
include
dependencies,
but
then
the
other
thing
I
talked
about
was
like
the
npm
should
kind
of
just
make
file
like
be
able
to
figure
out
which
order
things
need
to
run
in
within
a
workspace.
A
Actually,
that
is
possible
today
right.
So
like
exactly
your
example,
if
you
do
run,
yeah
npm
run
whatever
as
long
as
there's
no
asynchronous
tasks
within
that
script
or,
and
then
that
would
be
the
case.
C
That's
what
I'm
saying
is
that
almost
invariably
in
a
monorepo,
you
have
one
package
doing
a
build
script
and
then
the
next
package
consuming
the
built
output
and
and
then
using
it
in
tests
and
if
I
want
to
run
tests
in
both
of
them
and
b,
depends
upon
a
is
build.
Output
and
a's
test
script
does
the
build.
Then
I
have
to
run
a
and
wait
until
it's
completed
before
I
try
to
run
b
and
that's
some.
C
That's
npm
absolutely
has
enough
information
to
know
that
that's
necessary
and
my
my
opinion
is
that
npm
should
just
always
have
done
that
by
default
and
there's
no
other
behavior.
That
makes
sense
that
if
I
want
to
run
them
in
parallel,
there's
a
ton
of
ways
on
the
shell
to
run
commands
in
parallel.
The
the
valuable
thing
is
to
run
them
in
dependency
order.
The
way
that
makefile
is
done
for
40
years.
C
By
default
conservatively
in
v9
absolutely-
and
that
would
be
great-
I
obviously
it
would
be
nice
to
ship
it
in
v8
by
a
flag
and
then
switch
the
flag
into
v9,
because
that
way
people
can
test
it
out,
but
yeah.
A
C
The
thing
that
is
hard
is
automatically
applying
the
dependency
graph
ordering
to
a
set
of
tasks,
and
that's
the
thing
I
that
I
so
so.
In
other
words
like,
I
think
that
if
we
have
to
inconvenience
someone,
we
should
be
inconveniencing
the
people
who
need
to
run
it
in
parallel,
because
that's
a
much
easier
problem
to
fix
like
by
many
orders
of
magnitude.
That
said,
we
could
easily
come
up
with
a
config
flag
that
you
know
like
like
by
doing
a
config
flag.
C
B
C
A
Right,
it's
just
it's
a
interesting
thing.
Let's
say
the
use
case,
which
I
think
was
brought
up
two
weeks
ago,
was
beyond
build.
Let's
say
test,
let's
say
so.
If
I
run
test,
is
it
going
to
run
all
all
of
my
dependencies.
A
C
I
I
would
say:
yes,
you
run
in
a
first
and
then
b
and
if
the
only
downside
to
doing
that
in
the
on
the
off
chance
that
they're
not
dependent
on
each
other
is
that
things
run
a
little
slower,
but
they
still
run
correctly.
They
all
still
work.
So
the
outcome's
the
same.
It's
just
a
little
slower,
that's
the
the
negative
of
doing
this
by
default,
and
then
somebody
can
either
choose
to
run
them
in
separate
commands
or
provide
a
little
flag
and
like
switch
to
the
the
parallel
behavior.
C
A
C
What
I'm
saying
like,
if
somebody,
if
somebody
happens
to
have
magic
knowledge,
that
a
and
b,
that
the
the
foo
script
of
a
and
b
can
be
run
in
parallel
awesome.
Let
them
opt
into
running
them
in
parallel,
but
without
that
magic
knowledge,
it's
not
safe
to
run
them
in
parallel,
they
should
be
run
in
order
based
on
that
dependency
relationship.
B
Yeah
yeah
right
yeah.
I
definitely
agree
for
the
example
of
like
pre-pair
right
right
that
will
run
and
build
script.
So
so,
if
a
depends
on
b
like
you
definitely
need
to
be
able
to
build
b,
first
right
before
building
a,
but
in
this
example
of
test,
I
I
don't
think
I
agree
like
I
think
would
want
to
run
the
test
for
a
even
though
I
didn't
run
tests
for
b,
like
it's
just
test
right,
like
so
b,
has
already
has
already
been
transpiled
like
I
should
be
able
to
just
run
test
for
a
like.
C
A
C
C
C
C
So
I
should
be
able
to
run
ac
and
d
in
parallel
and
then,
when
a
is
done,
it'll
run
b
and
then,
if
they
all
succeed,
the
command
succeeds
and
if
any
of
them
fail,
the
command
fails
like
that's
that's
how
it
should
work
by
default
is
what
I'm
arguing
now,
but
either
way.
If
I
just
run
the
test
something
on
b,
it
should
only
run
on
b,
because
that's
what
I
asked
it
to
do.
C
B
C
B
B
Then
we
should
maybe
run
prepare
for
b,
even
though
you're
only
targeting
a
right
if
you're
running
npm
run,
prepare
dash
w
a
so
we're
only
targeting
the
a
workspace,
but
because
it
depends
on
b
we
run
prepare
for
b2
like
and
that
yeah,
because
I
think
that
this
subset
of
of
lifecycle
scripts
that
are
ran
at
the
end
of
the
install
at
the
end
of
a
refi
those
specific
scripts.
Maybe
it
makes
sense
for
them
to
always
be
kind
of
like
following
this
chain
of
dependency.
A
I
just
want
to
be
mindful:
luke
you've
had
your
hand
up
for
a
while.
Do
you
want
to
quickly
jump
it.
E
Yeah
a
lot
of
overlap
with,
what's
already
been
said
from
when
I
raised
my
hand,
but
I
just
wanted
to
reiterate
that
we
should
be
mindful
of
yeah
the
implicit
verse
explicit
and
if
there
are
commands
that
we'd
want
to
be
run
implicitly
just
make
sure
those
are
are
defined.
I
know
we
already
have
the
docs
page
of
you
know
when
you
run
prepare
what
other
scripts
run,
but
I
feel
like
that,
as
we
add
complexity
here-
and
this
is
I
you
know,
I
agree-
this
is
necessary
complexity.
E
This
is
something
that
we
should
be
taking
on
so
application,
authors
and
module.
Authors
don't
need
to
think
about
this,
but,
as
we
add
this
complexity,
I
feel
like
there's
potential
foot
guns
and
the
one
I
would
like
to
avoid
is
too
much
implicit
stuff
happening.
A
Right,
I
think,
to
roy's
point
as
well.
It
sounds
like
we
could
scope
it
to
just
when
workspace
has
been
defined
when
a
workspace
has
been
defined.
That
we
are
going
to
like.
Essentially
kick
in
this
sort
of,
like
chained
execution
is
that
is
that
what
you
were
saying
roy
like
we
can
essentially
scope
this
down
instead
of
at
like
a
top
level
at
the
project
root.
If
I
run
npm
test,
it's
not,
we,
we
don't
even
know,
potentially
how
to
run
which,
which
dependency
to
run
first
to
start
with
versus.
A
If
you
run
npm
test
dash
wb,
then
you
know
that
you
know
potentially
b
has
a
dependency
on
a
right
and
then
figures
that
out
yeah,
but
what
I
was.
B
Saying
is
that
makes
sense
for
like
the
kind
of
prepare
post,
install
type
of
scripts,
but
maybe
not
for
tasks
right
like
test
is
the
example
of
not
wanting
to
do
that?
Maybe
I
just
want
to
run
the
tests
for
my
a
package.
Then
I'm
targeting
npm
test
dash
w
a
and-
and
maybe
I
don't
want
to
run
test
for
b
right.
A
So
so
it
feels
like
we
could
do
this
work
flag
it
right
at
exactly
what
has
being
proposed
here
include
dependencies
or
or
something
along
those
lines.
Whatever
the
flag
would
be
called
and
see.
If
this
is
the
behavior
that
people
are
opting
into
most
often
before,
we
would
make
it
the
default
yeah.
B
And
I
do
like
the
example:
jordan
cave,
I'm
writing
it
down
in
the
notes
here,
but
it
it
applies
in
case
you're,
targeting
your
whole
workspaces
right.
So
his
point
is
very
good.
If
you're
targeting
all
workspaces,
the
npmcli
should
be
smart
enough
to
figure
out
this
all
these
relationships
and
ground
things
in
in
order
that
not
just.
A
Okay,
I
I
think
I
totally
agree
with
that.
Apologies.
We
didn't
get
to
the
last
two
items
here,
but
I
know
a
few
of
the
folks
couldn't
join
today.
We
will
be
back
next
week
at
the
same
time,
same
place,
appreciate
y'all,
jumping
on
today
again
and
hopefully
you're
staying
healthy
and
safe
wherever
you
are
in
the
world
and
we'll
talk
to
you
soon,.