►
From YouTube: Open RFC Meeting - Wednesday, June 29th 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.
Welcome
everybody
to
another
mpm,
open
rfc
call.
Today's
date
is
june.
29Th
2022..
I
will
be
following
along
in
the
issue
that
was
posted
very
much
last
minute.
I
apologize
issue
608.
A
I
apologize
if
there's
a
few
items
in
here
that
I
have
already
discussed,
or
you
can
close
out
at
some
point,
just
quick
reminder.
This
call
and
all
calls
and
comms
on
the
rc's
repo
are
covered
under
a
code
of
conduct.
We
ask
you,
please
be
kind
as
folks
are
talking.
A
Please
raise
your
hand
if
you
have
something
to
say
and
we'll
call
on
you
and
yeah
essentially
synopsis
is
there
is,
please
be,
please
be
mindful
and
thoughtful
while
on
these
calls
they
are
recorded
and
streamed
publicly
on
youtube
quickly.
I
wanted
to
give
the
forfeiting
folks
that
had
announcements
they
wouldn't
share
if
they
did
and
now's
the
time.
A
A
I
will,
for
visibility,
probably
create
a
an
issue,
as
I
have
before
on
the
repo
to
pin
it,
and
just
let
folks
know
that
we'll
be
out
next
week.
This
is
a
bit
of
a
team-wide
vacation,
so
folks
won't
be
online
next
week
either.
A
So,
ideally,
if
you
need
a
response
to
something
try
to
try
to
focus
this
week
before
folks
go
offline
and
yeah,
just
that
is
top
of
mind
for
for
our
team,
so
digging
into
the
first
item
in
the
agenda
that
we
had.
I
know
we
spoke
about
this
last
week
and
we
may
not
need
to.
A
We
could
probably
remove
the
label
for
this.
Gar
had
spoken
to
this
new
feature.
To
essentially
add
the
colon
colon
committed
style
path
pathing
for
commish.
This
is
pr
91
in
the
npm
package
arc,
and
I
think
this
is
now
landed.
So
I
think
we
can
probably
remove
it
from
the
agenda.
I'm
not
sure
if
folks
had
any
comments
on
this,
if
not,
we
can
just
move
on.
I
know
we
spoke
about
it
last
week.
Moving
on
to
luke,
you
had
the
engines
support.
I
know
this
was
something
we
talked
about.
A
I
think
internally,
as
well
as
a
little
bit
late
last
week.
I'm
not
sure
if
there's
any
update
here
that
we
wanted
to
give
or
if
we
want
to
just
remove
this
from
the
agenda
for
now.
B
Yeah
this
can
be
removed
for
the
agenda
label
can
be
removed.
I
thought
it
was.
I
didn't
have
anything
slated
for
this
week
for
this
we
had
talked
about
doing
some
more
async
discussion
once
we
had
concrete
details,
but
I
think
we
did
all
the
discussion
last
week.
A
Yeah
moving
on
we're
still
keeping
track
of
this
one
pr,
I
believe
internally,
guy
who's
now
on.
This
call
has
picked
up
this
pr
by
its
pr
5000
and
gets
the
mpmcli
repo.
A
A
I
know
I
had
given
some
internal
feedback
last
week
or
the
week
before,
just
about
some
things
that
we
were
saying
about
some
performance
issues
and
and
just
some
bugginess,
so
we
want
to
make
sure
this
is
a
good
good
feature
once
they
actually
does
land
and
also
want
to
be
mindful
about
the
language
we
actually
do,
support
so
potentially
versioning
the
doc.
A
The
query
doc
that
we
have
in
our
our
in
our
personal
docs
is
a
good
idea.
This
would
be
similar
to
how
we
version
log
files
versioning.
The
actual
spec
that
is
supported
by
the
npm
query,
like
the
language,
allows
us
to
sort
of
incrementally
add
features
and
do
breaking
changes.
I
guess
in
the
future.
C
I
have
a
question
about
that,
actually
sure
would
it
maybe
be
helpful
to
make
a
separate
package
that
parses
a
string
and
produces
a
structured
thing
and
then
have
npm
use
that
and
then,
instead
of
having
to
put
it
in
pros
in
the
docs,
you
can
just
say
this
is
the
version
of
this
package
that
we
would
support,
and
you
know
obvious,
like
the
how
to
interpret
the
structured
data,
obviously
that
still
lives
in
npm
but
like
I
know
that
it's
probably
not
the
only
way
to
do
it,
but
it
feels
like
a
clean
way
to
kind
of
wall
off
like
this.
A
Yeah,
so
I
believe
there
are
two
separate
packages
that
roy
had
created.
One
is
the
npm
supply,
slash
query
package
and
then
there's
an
internally.
I
think
there
was
a
separate
one
specifically
for
just
the
wrapping
the
parsley,
because
we
do
a
bit
of
pre-parsing
before
we
pass
it
to
essentially
like
the
post,
css
parser,
to
get
the
asd
generated.
So
if
we
ever
change
something
there,
we
would
want
to
yeah
yeah
so
but
you're
right,
essentially
it
it
should.
The
supported
selectors
should
be
living
in
actually
those
downstream
depths.
A
Awesome
quickly,
moving
on
to
the
next
item
that
we
had
here,
the
595
pr
595,
proposing
backwards,
compatible
improvements
to
compression,
I
believe,
evan
joined
on
one
of
the
calls
I
wasn't
able
to
make
recently
and
just
shared
that
they
were
going
to
look
into
this
more.
I'm
not
sure.
If
we
just
keep
this,
I
don't
think
I've
seen
any
updates
since
then.
A
Evan
said
he
wouldn't
be
able
to
make
this.
I
just
saw
him
comment
on
the
the
issue
thread,
so
maybe
just
keep
this
on
the
radar
and
try
to
give
him
a
bit
more
notice
of
the
next
call.
So
in
two
weeks
from
now
and
see,
if
there's
any.
A
D
So
I
think
the
takeaway
from
last
week
was
that
this,
given
the
trajectory
of
npm
query
that
this
would
be
better
executed
through
that,
instead
of
layered
on
its
own
thing
and
your
suggestion,
your
action
item
to
me
was
to
play
around
with
them
pm
queer.
Unfortunately,
I
did
not
get
a
chance
to,
but
you
know
if
it's
worth
just
adding
closure
to
this,
and
you
know-
or
maybe
it's
a
new
issue-
a
new
rfc
that
well
yeah-
I
guess
it's.
The
question
is:
is
for
something
like
this?
D
Because
I
think
jordan
raised
this
a
while
ago,
I
was
like
if
it
could
just
be
done
through
mpm
queries.
There
any
reason
for
the
cli
to
like
add
any
rappers
or
like
aliases,
and
is
this
one
of
those
cases
where
it'd
be
easier
to
provide
like
an
explicit
api
that
delegates
to
npm
query
or
just
give
people
like
a
man
page
of
npm
query
and
be
like
go
nuts.
You
know
like
ingredients
instead
of
recipes.
C
A
Yeah
so
I
felt
like
when
we
were
talking
last
time
also.
We
were
trending
towards
the
so
we've
introduced
npm
audit
signatures
and
improvements
like
that,
like
other
sub
commands
to
to
audit
it
feels
like
this
should
transform
into
you
know:
npm
audit
check
depths
or
whatever
the
name
is
depth:
depth,
checks,
typed
checks
or
something
like
that:
typed
up
depth,
type
checks,
depth,
type
check
or
something
like
that.
Like
a
technology.
D
Like
yeah,
only
registry
debts
was
alternative
that
came
out.
Sorry,
okay,.
A
Yeah,
it's
just
so
specific
right
versus
like
being
like.
This
is
the
thing
that
we're
about
to
do
we're
going
to
check
those
types
of
depths
and
then
like
configuring.
That
specifically,
like
I
don't
know
like,
but
yeah
only
registry
type
depths
because
yeah
like
we
don't
want
to
create
one
for
each
each
type
right
and
there's
variants,
and
I
think
this
is
where
I
got
to
last
week
where
I
was
like
well
eventually
you're
just
going
to
want
to
do
a
query
for
this.
But
yeah.
I
don't
know.
D
So
is
there
is
the
mpm
query,
rfc
already
account,
or
I
guess
no
jordan
you're
suggesting
does
a
command?
Does
the
mtm
query
call
out
being
able
to
pass
a
query
to
existing?
I
don't
think
so.
C
C
C
C
D
D
It
sounds
like
my
homework
assignment
is
to
figure
out
how
to
take
this
specific
feature
and
translate
it
into
npm
query
and
then
update
the
rfc
to
be
like
this
assumes
that
npm
query
lands,
and
then
we
can
expose
this
this
particular
feature,
and
it
should
just
call
or
forward
whatever
to
query
under
the
hood,
because
this
seems
like
one
of
those
clear
cases
where
we
want
to
nudge
in
the
right
direction
and
potentially
it
can
be
augmented
by
a
separate
query
argument
that
is
like
global
that
could,
like
you,
said,
just
build
off
any
it's
like
almost
like
a
builder
pattern.
D
It's
like
or,
like
a
you
know
like
spreading
an
object
into
a
new
object
and
the
defaults
just
override
yeah.
The
new
object
overrides
whatever
was
already
there
and
then
the
rest
kind
of
fall
through,
and
then
you
get
a
final
default
plus
user
override
config
in
one
elsewhere,
okay,
yeah.
That
makes
sense.
I
can
do
that.
I
can
update
the
comments
so
I'll
do
the
homework
on
query,
to
figure
out
how
to
reverse
engineer
this
feature
through
that
and
then
update
the
rfc.
D
To
presume
that
npm
query
will
exist
and
take
it
from
that
point
of
view.
Okay,
cool.
A
Yeah,
I
think
that's
great
to
own.
Also.
I
just
give
you
a
one.
I
think
it's
a
one
liner
and
I
haven't
tried
myself
so
double
check
my
homework,
but
to
quickly
grab
and
then
link
that
pr,
so
you
can
start
playing
with
query
today.
It's
just
like
literally,
you
can
use
gh.
If
you
don't
have
gh,
you
can
use
brew,
gh
to
reinstall
gh,
but
go
grab
clone
the
repo
and
then
check
out
the
pr
which
is
great.
A
A
Thanks
cool
moving
on
to
the
registry,
scoped
key
file-
john,
I
know
you're
here
jensen.
This
is
your
yeah.
This
is
yours,
the
rfc
591,
I'm
not
sure.
If
there's
any
update
that
you
want
to
share
about
this.
E
Yeah,
nothing
at
the
moment.
I
I
missed
the
meeting
last
week,
but
two
weeks
ago
we
said
we'd
probably
go
ahead
and
just
start
with
the
implementation.
There
were
no,
you
know
real
concerns
on
the
rc,
so
I'm
hoping
to
get
to
that
in
the
next
week
or
so
so
I
guess,
when
we
regroup
in
two
weeks,
I
should
have
some
updates
there.
A
I
think
if
there's
no
push
back
potentially
we
can
also
ratify.
If
this
looks
good,
I
have
to
I've
give
this
a
once-over
again
myself.
I
know
others
on
our
team,
though,
had
already
looked
at
it.
So
that's
that's
great.
If
you're
going
ahead
with
the
implementation,
I
appreciate
that
john
cool
anyway.
I
also
have
any
comments
on
that.
A
A
We
also
have
v9
here
and
then
b10
so
looking
out
even
a
year
ahead
in
terms
of
like
the
things
that
we
might
want
to
consider
breaking
changes
in
the
future,
things
that
can
become
discussion
topics
for
the
next
year,
but
just
want
to
highlight
these
again.
We
can
go
through
at
least
the
things
left
for
v8
v9.
I
think
v10
is
a
bit
skeptical.
A
You
know
there's
a
lot
of
skepticism
on
what
would
even
make
sense
for
me
time
at
this
point,
but
just
want
to
you
know
bubble
these
up,
see
if
folks
had
any
comments
want
to
look
through
those
issues
themselves
see
what's
being
worked
on
and
and
just
want
to
keep
this
on
everybody's
radar
week
over
week,
as
we,
you
know,
get
closer
to
cutting
a
v9
at
some
point
here.
So
anybody
have
any
comments
on
those
three
issues.
A
Any
comments
on
how
we're
tracking
them,
they're,
essentially
like
these
sort
of
epics,
with
corresponding
sort
of
minors
and
patches
associated.
C
Kind
of
sounds
like
you
should
you
should
try
and
find
someone
you
know
at
github
to
allow
milestones
to
work
across
issues.
That's
like
how
they
already
work
within
the
same
repo
or
a
cross
replacement.
A
C
Overall,
it
would
be
nice
to
look
over
the
nine,
the
v9
list
and
anything
in
that
list.
That's
a
breaking
change
that
isn't
well,
so
anything
in
there
that
isn't
a
breaking
change
should
be
ideally
moved
to
v8
anything
in
there.
That
is
a
breaking
change
that
isn't
simply
changing
the
default
to
an
option.
C
It
would
be
worth
evaluating
whether
that
can
go
in
v8
as
an
option
under
an
option
because
in
general,
breaking
changes
are
much
easier
to
deal
with
for
custom
for
users
when
they're
just
changing
the
default
of
the
flag,
because
then
it
becomes
really
easy
to
insulate
yourself
from
the
breaking
changes
by
hard
coding,
the
config
and
just
moving
forward,
and
you
can
also
like
anticipate
the
breaking
changes
so
that
you
just
remove
the
config
later
when
you
update.
So
what
I'll
say
is.
A
This
this
is
not
a
v9.0
right,
so
that's
why
the
the
the
braking
changes
will
have
to
land
in
the
v9.0
and
that's
maybe
the
right
like,
and
so
that's
maybe
the
confusion
there.
The
features
that
are
sort
of
queued
up
for
this
release
line
are
things
that
we're
looking
out
into
the
next
year,
saying
we'll
probably
they
will
likely
be
landing
in
this
next
major,
not
that
they
will
land
for
v9.
C
C
And,
like
I
mean
you
all,
set
your
own
calendars
and
timing,
but
like
it
would
be
really
nice
to
try
and
prioritize
getting
the
features
that
don't
require.
The
braking
changes
in
before
the
braking
change
happens,
because
that,
like
drastically
increases
the
number
of
users
that
can
use
the
new
features,
and
it
also
gives
extra
testing
time
and
all
like
there's
a
ton
of
benefits.
C
C
Or
let
me
put
a
different
way
is
that
the
people
who
can't
who
upgrade
slowly
aren't
going
to
be
pushed
by
this
they're
just
going
to
be
inconvenienced
and
that's
true
with
every
every
type
of
software,
not
just
npm.
C
A
Get
like
it
confirmed
that
we
will
be
backboarding
and-
and
it's
like
highly
likely,
that
we
will
be
backward
b9
to
note
16,
then
it's
kind
of
like
v8
is
not
a
support,
will
not
be
supported
like
the
minute
that
v9
lands
right
so.
C
Yes,
that's
that
is
sort
of
a
a
cheat
code
that
npm
in
particular
can
use
to
work
around
the
problem
I
described,
but
the
I
mean
it's
a
mentors
project.
C
Mean
yeah
it's
a
little
different
because
npm
shipped
with
node
so
like
it's
like,
but
we
don't
have
to
get
all
derailed
on
that.
I
guess
what
I
mean
is
that
that
is
a
stronger
argument
that
the
breaking
changes
should
be
as
restricted
as
possible
to
just
changing
the
defaults
of
config
flags
because,
like
that
makes
it
easier
for
the
people
and
more
likely
for
you
to
be
able
to
get
b9
into
node
16.
A
For
sure
the
last
two
one,
the
dependency
selector
syntax,
this
is
rc
564..
I
think
there's
a
couple
last
changes
I
want
to
make
before
we
actually
ratify
that
just
like
in
terms
of
language.
I
want
to
double
check,
spelling
on
things
and
just
want
to
give
it
one
more
fast
before
we
land
it.
Also,
because
not
everything
all
of
the
syntax
is
going
to
be
supported
day,
one
with
npm
query.
A
I
just
want
to
highlight
maybe
that
iterative
approach
again,
we
did
that
with
workspaces,
and
I
thought
it
was
good
where
we
itemized
sort
of
like
what
could
land
when
and
what
was
going
to
be
initially
added.
So
I
might
even
pull
things
out
of
that
initial
rc
and
then
put
them
into
a
separate
rfc
depending
on
how
I
feel
about
that.
A
But
yeah,
we
could
just
say
that
we
are
implementing
a
first
set
of
the
language
and
then
have
like
a
separate
set
that
can
come
later
individually
as
we
sort
of
ship
minors
to
to
query.
A
So
that's
the
update
there
and
then
the
last
item
here
by
christian
is
the
rc
165
for
adding
a
parent
package.json.
I
know
this
is
something
that
wes
has
previously
championed,
but
never
had
an
rfc
for
and
yeah.
This
has
come
back
around.
I
think
because
of
the
because
of
openjs
collab
summit.
We
were
talking
about
extension
package,
json
extension,
so
I'm
not
sure
where
we're
at
with
this.
C
I
remain
concerned
about
using
this
in
anything,
that's
published,
so
if
we,
I
believe
all
the
use
cases
are
for
non-published
things,
so
if
we
or
most
of
them
anyway,
if
it's
restricted
to
things
that
are
private,
true
and
like
the
feature
just
doesn't
work
otherwise,
then
my
concerns
are
probably
addressed.
C
A
C
The
private
true
that
would
be
a
great
way
to
do
it,
but
on
top
of
that
I
would
say,
npm
publish,
should
refuse
to
publish
anything
that
extends
anything
else.
C
So
I'm
assuming
we
don't
have
to
worry
about
that.
That
use
case
differently,
but
like
yeah,
just
the
both
of
those
things,
the
private,
true
and
refusing
to
publish,
would
like,
because
the
refusing
to
publish
is
the
real
important
one.
The
private
true
will
catch
that
problem
much
sooner
before
people
to
depend
on
it.
I
think
based.
A
On
this
rc
and
con
historical
conversations-
and
my
my
I
have
still
put
their
brain
fog
here,
but
I
thought
the
idea
with
publish
would
be
that
it
would
unwind
and
essentially
pull
in
with
that
packet
of
json
and
becomes
like
a
mapping
so
on
publish
be
similar
to
like
actually
doing
like
in
npm
live
npm
pack.
We
would
actually
be.
C
That's
an
alternative
in
a
way
it
could
work,
but
that
that
means
that
the
thing
you're
publishing
doesn't
match.
C
What's
sitting
in
your
source
tree
for
the
package,
json
and
that's,
I
know
that's
already
the
case
for
code
when
you
have
a
build
process
and
stuff,
but
like
right,
I
I
think
that
there
is
probably
a
lot
of
unappreciated
unintended
consequences
of
that
for
package.json
in
particular,
especially
depending
on
what
you
allow
to
be
extended
like
if
you
put
resolution
rules
in
there
like
main
or
exports
or
browser
or
types
or
any
of
those
other,
you
know
module
js
next
may
and
all
those
things
like
those
are
relative
paths
and
having
them
like
the
confusion
and
there's
no
right
answer.
C
But
also
like
I've
heard
the
use
cases
I've
heard
are
basically
like
you
know,
I
know
they're,
I
guess
they're
they're
really
only
they're,
primarily,
I
guess
they're.
C
So
I
I
think
it's
that's
it's
not
saying
it
can't
be
done
either
for
non-published
or
for
both
it's
just.
It
is
not
a
simple
matter
of
just
put
extends
and
point
to
another
package.
Json
like
it's
very
complex.
C
C
A
C
That's
a
decision
that
can
we
that
can
be
made
and
but
half
the
people
are
going
to
expect
the
opposite.
Behavior
it's
going
to
be
very
confusing
and
when
you
try
to
debug
and
you
find
a
relative
path
and
it's
it's
relative
to
some
random
spooky
folder
at
a
distance
and
not
the
place
where
you
typed
the
dot.
That's
going
to
be
really
confusing
and
there's
a
lot
of
places
in
package.json
that
can
take
file
paths,
yeah.
A
Yeah,
the
the
other
sort
of
I
guess
workaround
here,
is
just
being
able
to
apply
like
running
npm
in
it
as
almost
like
a
npm
audit
or
a
checker
right
like
so.
You
can
have
an
in
it
script
today
and
if
we
were
able
to
essentially
apply
some
like
a
validation
step
to
package.json
based
on
this-
and
I
know,
wes
has
even
created
some
tooling
around
this.
A
C
And
that,
I
think,
is
a
different
feature
because
that's
not
runtime
extension,
that's
build
time
extension
and
the
end
result
would
be
a
complete
package
json
in
the
right
place
in
the
source
tree
like
that's.
That,
I
think,
is
avoids
a
lot
of
the
concerns
and
complexities.
I
have,
and
we'd
it'd
be
great
to
hear
from
wes
about
if
that
would
solve
their
use
cases
as
well.
A
Yeah
yeah,
I
think
he's
got
some
that
tooling.
Even
so,
when
we
were,
we
were
conceptualizing
the
create
project.
We
were
talking
about
validation
of
package.json
and
how
we
could
essentially
improve
like
npm
in
it,
even
right
and
because
we
have
the
ability
to
run
against
all
the
workspaces
like
there's.
There
might
be
something
here
that
we
could
add
into
npm
itself
to
update
and.
C
C
A
And,
and
in
it
and
audit
like
immediately
become
like
where
we
would
use
yeah,
okay,
interesting
anybody
else
have
any
comments
on
that.
A
If
not,
I
may
just
keep
it
on
the
our
radar
for
for
next
week,
just
in
case
what
are
for
two
weeks
from
now,
just
in
case
wes
or
christian
circle
back,
and
I
also
wanted
to
open
the
floor
because
we
have
roughly
20
minutes
left
for
any
other
items
that
folks
want
to
bring
up.
I
know,
there's
a
few
that
haven't
been
pulled
in
lately,
owen:
go
ahead.
D
Sorry
I
just
remembered
for
that
last
issue
about
the
package
json.
Some
of
you
are
probably
familiar-
maybe
jordan,
but
there
is
a
package
called
cosmic
config
that
I
know
a
lot
of
projects
like
projects
that
tend
to
allow
like
nested
configs.
So
like
the
nested
one
overrides
the
parent
one
and
then
the
nested
one
overrides
that
so
you
can
have
like
configs
at
all
layers
and
anyway,
in
terms
of
like
prior
art.
You
know,
I
know
a
lot
of
projects
depend
on
it.
D
C
C
Is
coming
out
with
a
brand
new
config
system
and
I
don't
know
if
it
uses
cosmic
config,
but
I
have
no
idea
how
that
works.
Yet
I.
A
Think,
post
css
uses
it
too.
I
yeah
yeah.
It's
got
40
million
weekly
downloads,
so
it's
used
quite
heavily
right.
Okay,
that'd,
be
it
yeah.
A
Okay,
thanks
any
other
rfcs
issues
or
items
folks
want
to
bring
up
discussion
topics.
A
If
not,
I
can
give
you
a
total
of
roughly
20
minutes
of
your
day
back,
we'll
see
you
in
a
week
and
a
half
for
two
weeks.
Actually
sorry
and
yeah.
Thanks
for
joining
us
today
and
talk
to
you
soon
cheers.