►
From YouTube: Open RFC Meeting - Wednesday, June 22nd 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
fpm,
open
rfc
call.
Today's
date
is
wednesday
june
22nd
we'll
be
following
along
in
the
agenda
issue
that
was
created
in
the
fbi.
Mrc's.
B
A
That
item
issue
was
number
603
and
for
folks
that
have
just
joined,
feel
free
to
add
yourselves
to
the
meanness
talk.
A
If
you
haven't
already
that
we
copy
and
paste
here
in
chat
and
just
quickly,
these
calls
and
all
meanings
and
all
communications
on
the
ifc's
repo
are
covered
under
a
code
of
conduct
which
is
like
there
in
the
repo
and
synopsis
is,
please
be
kind
and
thoughtful
when
others
are
speaking
on
these
calls,
and
please
raise
your
hand
if
someone
else
is
talking
and
we'll
try
to
call
upon
you
to
speak
and
yeah
just
try
to
be
kind
and
quickly.
A
If
there's
none,
I
know
two
a
couple
weeks
back,
we
a
few
of
us
were
at
austin
for
open.js
world.
I
think
there's
a
number
of
videos,
hopefully
reporters
from
the
club
summit
that
happened
just
after
that
conference
and
I
know,
there's
been
a
number
of
talks
since
then
about
work.
A
That's
going
to
happen
in
the
various
you
know,
project
working
groups,
but
just
want
to
shout
that
out
that
our
team
was
there
and
it
was
a
great
time
it
was
great
to
see
a
bunch
of
y'all
in
person
and
yeah,
just
wanna
jump
right
into
it.
Gar.
I
think
the
first
item
on
here
is
yours.
This
is
pr91
feature,
forget,
add
some
for
support
for
commentish.
B
So
yesterday
I
was
writing
some
documentation
around
what
a
package
spec
is
because
I
wasn't
very
consistent
across
the
cli
and
ended
up
looking
in
this
repo,
which
parses
that
argument
and
saw
this
pull
request
from
two
years
ago,
that
solves
a
big
problem
that
everyone
has
and
realized
they
got
dropped
on
the
floor.
So
I
spent
about
an
hour
implementing
the
spec
in
the
comments.
It
was
very
easy
to
do,
and
here
it
is,
I
wasn't
here
then,
so
I
don't
know
what
was
discussed.
B
This
allows
you
to
do
colon
colon
to
separate
multiples
of
those
so
and
then
it
also
adds
the
path
as
something
it's
a
path
as
a
new
thing,
which
will
add
a
get
subdir
attribute
to
the
response
which
which
coach
I
can
then
use
to
say.
Oh,
I
need
to
go
into
the
subdirectory
of
the
get
thing
I've
checked
out,
so
we
can
now
install
from
a
get
reference
in
subdirectory.
A
That
was
so
so
I
understand
that
and
sorry
join
from
something
on
there.
So
the
idea
would
be
that
you
could
potentially
install
a
like
monorevo
like
like
a
workspace
project.
Let's
say
using
the
get
ref
using
this
syntax
and
not
having
to
have
to
publish,
I
guess
the
package
itself,
but
you
could
be
using
this
pathing
yeah.
Okay,.
B
I
know
it
would
be
helpful
for
the
cli
specifically
because
one
of
the
things
we
want
to
be
able
to
do
is
say:
npm,
publish,
npm,
cli,
hashtag,
v8,
12,
3
or
whatever,
and
that
will
pull
that
tag
from
get
and
publish
what's
there,
which
means
that,
even
if,
even
if
we've
the
get
rate
reference
has
moved
since
then,
you're
still
publishing
exactly
what's
tagged
and
get
as
the
thing
you're
publishing,
which
is
a
nice
safe
thing,
a
safety
thing.
We
can't
do
that
for
our
workspaces,
though.
C
B
C
To
me
to
find
a
way
to
add
a
subdir
path,
because
anyone
who
has
any
form
of
monorepo
is
screwed
otherwise
and
despite
my
lack
of
empathy
for
monorepos
right
like
that,
that's
a
that's
a
a
reasonable
thing.
To
expect
to
be
able
to
do
so,
it
should
be
doable.
But
maybe
I'm
just
confused.
But
your
pr
seems
like
it's
much
more
complex
and
generic
than
that,
like
it's,
not
just
tacking
a
subdirectory
path
on
and
I'm
trying
to
understand
how
I'm
misreading
it
or
if
I
am.
B
Because
that
metadata
has
to
live
somewhere
right
and
so
because
the
if
you
go
look
in
46
of
the
comments,
the
there's
things
we
know
can't
exist
in
the
committee
that
we
can
kind
of
the
colon
can't
exist
in
the
committee.
C
B
We're
already
using
the
stem
bear,
so
this
is
basically
they
had
to
put
that
somewhere,
and
so
it's
it
goes
in
the
the
everything
after
the
the
url
would
consider
the
hash.
So
it's
basically
so
we're
already
allowing
you
to
do
a
sem
bear.
Syntax.
B
You
can
see
in
the
comment
from
so
what's
the
double
colon
for
like
that
separates
them,
so
you
could
do
a
commit
issue
and
a
path
which.
C
Okay
and
that's
in
the
spec.
B
A
C
I
mean
I'm
sure
it
doesn't
do
the
correct
thing.
Obviously,
or
this
feature
would
need
to
be
added,
but,
like
my
I
guess
my
hope
is
that
it
fails
as
opposed
to
doing
the
wrong
thing,
and
I
think
that's
useful
to
figure
out,
and
I'm
also
wondering
if
this
is
something
that
we
want
to
add
before.
We
have
an
easy
way
to
ban
git
depths
from
from
dependency
graphs,
because
this
makes
sense
in
your
application
to
use
it.
A
Well,
yeah,
so
one
one
case
I'll
make
there
like.
I
don't
think
that
we're
we
should
make
that
association
quite
yet
like
with
been
in
githubs.
This
is
also
still
important
that
we,
I
think,
support
this,
especially
because
we've
still
installed
it
steps
forever,
probably,
but
usually
like
through
opt-in
mechanisms
right
like
either
through
overrides
or
like
in
the
future.
A
You
know,
like
you,
explicitly
have
to
say
that
you're
willing
to
install
those
types
of
dependencies-
and
I
don't
think
we
would
ever
like
publicize
this
too
much
to
be
like
okay,
like
this-
is
the
recommended
path
forward
for
you,
especially
because
we
don't
want
to
promote
kit
dependencies
necessarily
but
yeah.
This
does
seem
like
a
nice
like
very
nice.
A
Feature
for
for
folks
that
are
installing
and
doing
development
work
right
with
moderate
those,
so
yeah
and
guy,
were
you
able
to
figure
out
what
happens
today
with
yeah.
A
B
C
Right,
it's
it's
there's
a
big
difference
between
a
feature
and
something
that
can
get
published
to
the
ecosystem
and
used
transitively
without
the
person
getting
affected.
Knowing
about
it
and
things
that
can
go
in
the
dependency
lists
are
thus
very
different
than
things
that
could
go
in
like
scripts
or
something.
B
A
People
do
this
today,
like
there's
get
dependencies
in
the
top
10
100
top
thousand
dependencies
right
now.
So,
like
that's,
why
we're
saying
eventually
we'll
stop
by
preventing
you
maybe
from
publishing
that
new
packages
or
we'll
we
won't
install
them?
Maybe
we
won't
prevent
you,
because
that's
a
policy
thing
by
the
registry,
but
the
cli
could
prevent
installation
of
git
depths
when
we
see
them
warn
that
they
exist
or
whatever
in
the
future,
but.
C
Use
this,
I
will
add,
as
the
few
projects
I
have,
that
are
monorepos.
The
inability
to
do
this
actually
protects
me
from
people
trying
to
install
pull
requests
of
one
of
the
sub
projects
before
it's
ready
and
thus
unleashing
a
torrent
of
bug.
Reports
on
me
that
are
confusing
and
hard
to
debug,
so
unlocking
this
ability
will
actually
create
some
maintainer
burden.
A
C
C
And
so
on,
a
small,
simple
one,
repo
project,
you're
right
people
could
always
have
done
this,
but
no
one
bothers
because
those
things
don't
have
long
running
full
requests
with
confusing
dependency,
graphs
and
hard
things
to
debug,
but
monorepo
based
projects
usually
are
that
because
they're
so
complex,
and
so
this
will
create
that
scenario.
Let's.
A
A
I
appreciate
god
you're
picking
this
up
and
bringing
this
back
up.
So,
oh
and
I
see
your
hands
up,
do
you
wanna
also
jump
in.
D
Yeah,
so
just
a
quick
point
of
clarification,
I
guess
it's
for
gar
he's
looking
at
the
the
tests.
What
would
throw.
D
So
this
would
only
work
on
like
I
guess,
maybe
that
otherwise
can
you
do
this
if
you
are
just
doing
the
semba
range
so
like
oda,
1.1.
D
D
A
I
think
this
is
all
part
of
you
having
cleaned
up
the
package
or
that
might
have
been.
I
could.
I
could
be
speculating
here,
but
cleaning
up
our
docks
around
the
package
spec,
I
think
credit
card
like
this
has
potentially
fallen
out
of
that.
So,
oh
and
to
your
point,
we
haven't
really
popularized
or
marketed
the
fact
that
there's
actually
a
lot
of
really
interesting,
unique
ways
to
install
like
pull
requests.
A
You
know
you
can
install
a
pull
request
using
like
just
the
git
ref
to
the
pr
through
this
commit,
like
syntax
already
so
like
there's
a
lot
of
interesting
use
cases
that
I
think
it's
just
today
that
folks
don't
know
about
that,
you
might
want
to
check
out.
You
know
the
somebody's
pr
and
and
see
the
working
life
package
type
thing
go
ahead.
B
B
This
started
because
publish
started
using
it
in
like
700
whatever,
and
the
old
behavior,
where
like.
If
you
had
a
directory
that
matched
the
single
bare
word,
you
put,
it
would
go
into
that
directory
and
publish
what
was
in
there,
which
was
all
kinds
of
inconsistent.
B
It's
important
remember
all
our
commands
now
go
through
this
npm
package,
arg,
which
is,
is
kind
of
this
package
spec,
which
I
wrote
the
docs
for,
so
it's
not
just
publish
it's
it's
or
it's
not
just.
A
B
Not
gonna
which
allows
you
that's
how
omar
that's,
how
like
dot
works,
right,
npm,
owner
dot,
oh
I'll,
just
pull
up
the
package
in
my
current
directory.
That's
the
name
I'll
tell
the
registry
to
be
interacting
with
that
package,
the
name
in.
What's
in
my
current
directory
right,
you
see
how
that
package.
Spec
works,
is
kind
of
a
holistic
thing.
It's
not
just
a
package
name,
it's
referring
to
a
package
in
some
way
it
could
be
a
tarball,
a
remote
tarball.
B
A
Any
other
comments
on
this.
I
think
it's
a
great
thing
to
have
brought
up
guys
appreciate
that
to
work
on
it
too.
I
think
I'm
plus
one
any
other
comments
or
feedback
you're
hoping
to
get.
A
Yeah
under
under
a
new
miner,
I
think
that's
I'm
not
plus
one
for
that.
A
Cool
is
it
oh.
This
is
a
separate
pr
that
had
tests
failing.
I
guess
that's
what
we
were
looking
at:
okay,
cool,
I
think,
moving
on
then
to
issue
number
519,
braking
change
engines,
support
for
changing
engine
support
for
npn,
v9
luke.
This
was
your
issue.
Did
you
wanna
speak
to
this.
E
Yeah,
I'm
trying
to
remember
what
we
covered
last
week.
There
wasn't
anything
new
from
then,
but
if
anyone
else
has
other,
I
haven't
followed
up
on
the
action
items
which
were
one
was
to
read
the
package
maintenance
spec
for
like
package
support
and
just
see.
If
there's
parts
of
that
that
we
could
adhere
to
and
then
the
other
part
was
just
continuing
feedback
around
this
in
general.
E
The
only
large
change,
besides
just
gathering
information
about
what
we
want
to
support
is
potentially
dropping
support
for
odd
numbered
versions
outside
of
a
major
breaking
outside
of
major
versions
in
the
npm
cli,
and
that's
mostly
because
it
makes
it
difficult
to
do
things
like
greater
than
or
equal
to
16
or
greater
than
or
equal
to
18,
and
then
change
that
to
greater
than
or
equal
to
20,
which
inherently
drops
support
for
one
odd
numbered
version,
and
we
don't
want
to
have
that
be
a
breaking
change
while
continuing
to
support
you
know
future
versions,
future
major
versions
without.
C
So
so
I
definitely
think
you
should
use
the
package.js
support
stuff
and
I
put
the
command
in
the
zoom
chat.
That's
how
you
can
quickly
add
it
to
a
package,
but
support
is
different.
Support
has
no
effect
on
what
is
a
breaking
change
or
not.
If
yeah,
I
see
gar's
hand
is
up.
I'm
sorry,
I
didn't
get
my
hand
up.
If
you
you
want
to
say
that
you
can
cover.
B
This
last
weekend,
I
was
going
to
reiterate
the
fundamental
problem
here
is
we
are
not
differentiating
between
what
engines
means
and
what
support
means,
and
so,
when
he
says,
support,
remember
we're
talking
about
what
our
team
will
will
will
say.
Yes,
we,
this
should
right
versus
using
pr
engine,
says
it's
gonna
run
in
these
node
versions
right
and
that's
to
keep
it
from
exploding.
B
Not
you
know,
node
21.,
you
know
yeah.
Okay,
that
week
they
ship
the
bug.
Sorry
about
that
kind
of
a
thing
right.
So
that's
the
fundamental
thing
that
came
out
of
this
is:
we
need
to
differentiate
between
engines,
saying
what
we
know
it'll
run
in
versus
this
new
idea
of
what
support
is
that
we
need
to
define
so
that
our
engines
doesn't
have
to
be
our
support,
matrix.
C
I
mean
that
that's
sort
of
that's
what
I
mean
those.
I
don't
think
that
that's
actually
differentiable
to
be
and
still
be
complying
with
semver.
I
know
that,
like
there's
specific
maintainers,
who
used
to
be
on
your
team,
who,
like
really
had
wanted
after
a
decade
of
doing
this,
to
be
able
to
drop
support
for
a
node
version
without
having
it
be
a
breaking
change,
but
that's
just
in
practice
not
viable
so
like
it
is.
C
I
think
it
is
useful
still
to
separate
to
have
a
explicit,
separate
support,
matrix
defined,
but
support
is
irrelevant
when
you're
talking
about
it
must
still
always
work
on
whatever
the
the
x.0.0
engines
was.
It
always
has
to
work
on
those,
at
least
until
you
upgrade
until
you,
you
know,
bump
the
x
and
there's
no
way
around
that
short
of
willfully
deciding
to
violate
semver.
You
could
do
that
packages
do
that
typescript
and
react
have
defined
for
themselves
the
ways
in
which
they
willfully
violate
sember,
and
they
consistently
stick
to
that.
C
Eslint
does
as
well
right.
The
airbnb
javascript
style
guide
has
to
do
that.
Also
because
you
know
otherwise,
like
everything
is
a
breaking
change,
because
it
causes
a
lint
warning
right.
So
like
it,
it's
not
out
of
the
question
to
define
your
own
form
of
semver,
but
like
be
aware
that
that's
what
you're
doing
right
there,
there
isn't
another
way
to
to
make
engine
changes.
Non-Breaking,
they're.
A
So,
based
on
the
the
length
that
you
showed
jordan-
and
I
know
going
back
two
and
a
half
three
years
when
the
support
a
whole
spec
kind
of
came
out
of
the
package
jason
or
the
package
maintenance
working
group,
that
there
was
definitions
for
lts
defined
for
versions
like
like
the
new
sort
of
spec
that
you
could
essentially
say
apply
for
like
if
we
removed
engines
entirely
right
and
only
opted
to
use,
essentially
the
support
schema
that
has
been
kind
of
drafted
by
that
that
working
group
like
then,
we
kind
of
alleviate
ourselves
from
that
contract
that
summer
contract.
A
C
A
B
A
Exactly
in
terms
of
flushing
out
all
the
options
that
we
have
available
to
us
and
and
one
of
those
being,
how
do
we
stay
evergreen
with
the
node
versions?
There
was
that
kind
of-
or
you
know,
option
made
available
based
on
this
problem
of
the
note
versions,
shifting
underneath
a
package
that
doesn't
want
to
do
a
ship
or
breaking
change.
I
think
I'm
totally,
okay
with
us
continuing
to
ship
breaking
changes
to
update
our
versions,
I'm
different
than
other
maintainers,
that's
my
personal
opinion,
but
go
ahead
girl.
You
guys
see
your
hands
up.
B
If
you
look
in
our
npm,
js
or
clijs
you'll
see
that
we've
got
two
checks.
We've
got
a
hard-coded
check
for
a
floor
of
node
that
we
know
we
don't
work
under,
but
then
we
also
use
our
engines
to
talk
about
what
we
support.
So
we're
already
conflating
these
things
in
npm,
and
this
is
an
attempt.
This
discussion
is
an
attempt
to
untangle
that
and
make
engines
be
engines.
C
On
main,
the
problem
is
that
software
that
works
should
work
forever.
If
I
don't
like-
and
the
point
of
december
is
to
say
that
I
like,
like,
like
time-based
decisions
or
corporate
whims
of
what
to
support
or
whatever,
like
those
are
not
supposed
to
break
software,
they
may
mean
that
you
can't
fix
a
bug
that
is
discovered
at
the
time
it's
no
longer
supported,
but
like
it,
it's
just
the
those
those
two.
Those
two
desires
are
just
incompatible
like
it's.
C
Just
not
it's
just
not
reasonable
to
be
able
to
get
the
benefits
of
semver
and
also
have
the
the
date
on
the
calendar
decide
when
your
software's
allowed
to
break.
C
I
I
mean
I'm
not
saying
that
one
of
them
is
objectively
better
than
the
other.
I'm
just
saying
that,
like
the
ecosystem,
we
have
is
the
former,
and
it's
just
not
practical
to
inject
the
latter
into
it,
because
then
you
disrupt,
then
you
have
an
ecosystem
that
doesn't
consistently
have
the
benefits
of
both
or
of
either
one.
A
Yeah,
so
I
think
to
try
to
wrangle
both
like
your
understanding,
you're
going
and
join.
What
you're
saying
like
I'm
referenced
to
your
support
policy
like
we
are
known
not
to
support
more
than
one
version
and
that
that
is
latest
the
reason
why
v6
is
still
getting
some
backboard
security
patches
is,
you
know,
sort
of
an
out-of-band.
A
Situation
that
we
are
living
with
right
now
that
we
hope
will
never
be
the
case
once
note,
14
goes
end
of
life,
so
that
is
a
situation
where
we
don't
and
we
don't.
We
consider
that
to
be
on
life
support
upgrade
to
v8
as
soon
as
possible.
Please
if
you're
listening
to
this
and
you're,
not
on
this
meeting
right
now,
but
our
support
policy
is
like.
We
only
support
the
latest
version
of
npm
and
so
and
and
by
that
we
mean
truly
like
the
latest.
C
That's
typically
the
way
everyone
works
right
like
there's
some
some
company,
like
some
some
some
of
my
projects,
even
I
will
support
every
minor
line
and
back
port
patches
back
but
like
that's,
only
the
like
most
massive,
the
ones
that
are
the
most
sensitive
like
the
almost
every
project
of
mine,
I'm
the
same
as
npm
there,
which
is
that
I
only
support
the
very
latest
version,
but
I
will
always
fix
bugs
in
that.
But,
like
yeah
I
mean
the
the
npm.
Just
is
an
unfortunate
situation
because
it
has
to
it
even
in
the
future.
C
A
Yeah,
so
we're
not
going
to
support
v8
when
b9
drops.
That
is
like
that's.
What's
going
to
happen
so
going
through
like
exactly
what
luke
has
written,
I'm
like
I
have
to
read
through
the
details
and
wording
exactly
how
we
put
it
here.
But
yes,
there
is
definitely
we.
We
will
not
support
v8,
once
b9
drops,
as
just
they
will
be
backported
we're
already
having
discussions
with
I'm
going
to
have
discussions
with
the
you
know,
releasers
working
group
about
ensuring
that
we
get
v9
backported
to
node
16.,
which.
A
A
we're
doing
our
best
to
help
maintain
that
release
line,
even
though
it's
not
technically
really
supported.
It
is
we're
doing
our
best
to
not
disrupt
the
ecosystem
there,
but
it's
up
to
the
node
project
to
update
their
dependencies,
and
it
should
not
necessarily
be
a
breaking
change
for
them
to
update
npm
in
older
versions
of
node,
so
go
ahead.
Luke.
E
E
and
and
during
all
major
versions.
We
want
to
you,
know,
reevaluate
our
engine
support
and
look
at,
and
I
keep
using.
You
know
this
is
outside
the
discussion
of
how
we're
conflating,
support
and
compatibility,
so
I'm
using
the
wrong
terms,
but
when
we
switch
to
greater
than
or
equal
to
18,
because
we
want
to
make
sure
that's
like
the
widest
range
possible
and
then
switch
16
to
some
specific
patch
minor
version
of
16.
E
That
is
always
going
to
be
a
breaking
change,
and
so
we
want
to
the
only
thing
that
I
was
iterating
around,
like
our
december
contract
was
if
we
want
to
have
dropping
support
for
odd
versions,
be,
like
you
know,
as
jordan
said,
a
special
non-semver
thing
that
we
do
and
the
discussion
around
that
I
feel
like
is
maybe
a
different
rfc
or
you
know
like
a
more
scope
discussion
just
on
that,
and
if
we
don't
want
to
do
that,
then
how
can
we
increase
our
engine
support
without
without
drop?
E
You
know,
without
dropping
an
odd
version
and
having
bug
reports
around
that.
E
Yeah,
so
my
the
you
know
the
proposal
in
wrapped
up
in
this
whole
engine
support
for
what
engines
should
be
in
mpm9
is
that
we
do
have
a
special
semver.
You
know
thing
carved
out
where
we
say
like
odd
versions,
you're,
basically
on
your
own
as
far
as
support
like
as
far
as
whether
you
are
going
to
get
you
know,
engines,
warnings
or
stuff
like
that,
and
you
shouldn't
be
using
odd
versions
in
production.
E
C
Npm
is
almost
never
used
in
production;
it's
primarily
used
in
development
and
ci.
So
like
it's,
the
the
reality
is
that
it's
you
know
it's
that
xkcd
spacebar
thing
you're
going
to
break
a
lot
of
people's
workflows
when
you
drop
something-
and
I
think
it's
totally
reasonable
to
do
it
in
december,
major
for
end-of-life
nodes-
and
you
know,
which
includes
the
odd
ones
after
the
next
even's
released
and
so
on.
C
C
It
is
reasonable
for
npm
not
to
try
to
work
around
that,
even
if
it
still
supports
node
17,
like
with
its
engines
field,
but
if,
like
some
dependency,
just
added
some
syntax
that
just
hard
breaks
in
node
17
and
that
syntax
isn't
necessary,
then,
like
it
seems
kind
of
silly
to
me
to
say.
Well,
we
don't
support
it
when
it's
such
a
trivial
fix
so
like,
but
that's
like
a
judgment
call
that
can
and
should
be
made
on
case-by-case
basis.
C
B
No,
the
concern
is,
is
when
no
there's
a
new
node
odd
or
there's
a
new
node,
even
in
order
to
add
support
for
that.
Currently,
we
have
to
do
a
breaking
change,
because
the
way
engines
works.
E
Because
we're
yeah
the
other
problem,
we're
trying
to
solve
is
always
keeping
our
last
major
version
at
a
greater
than
or
equals
two
which
solves
the
problem
of.
We
don't
have
to
change
our
engines
like
for
when
new
stuff
gets
dropped
and
we
can
kind
of
work
on
our
own
timeline
there,
which
I
think
so
I'm
trying
to
weigh
that
against
dropping
support
for
odd
versions,
and
I
feel
like
keeping
that
at
a
greater
than
or
equals
to
16
or
18.
E
A
So
does
this
get
fixed
if
we're
using
the
carrot
for
the
known
versions
like
like
imagine
for
whatever
reason
cross
our
fingers
like
people,
stop
writing
software
and
node
stops
being
maintained,
and
there
isn't
enough.
Next,
major
version
of
node
gets
released
next
year,
right
so
like
if
we
were
to
just
simply
be
adding
to
the
engines
doing
an
additive.
Essentially
carrots,
let's
say
20
whatever
the
next
major
is
carrot
20
once
it
does
land
that
is
essentially
to
me.
That's
a
minor
release.
C
But
but
in
pract
I
agree
that
it's
more
precise
to
have
add
the
carrot
and
that's
a
better
thing,
because
then,
when
you
add
the
carrot,
you're
also
adding
it
to
your
testing
matrix
and
you
know
for
sure
it
works
from
that
point
forward.
But
when
node
19
comes
out,
you're
not
going
to
want
to
skip
node
19,
while
it's
still
the
latest
so
you're
going
to
have
a
version
of
npm
that
supports
node
19
and
that
cannot
drop
19
without
december
major
and
a
and
no
and
so
so,
and
you
have
to
wait.
C
Node
version
you'll
get
that
warning.
Everyone
will
be
seeing
the
warning
and
also
npm
itself
unless
it
hard
codes
around
its
engine
heuristics.
When
you
do
npm
install
gnpm,
it
will
probably
install
like
it
will
probably
look
for.
Actually
it
might
not
because
it
there
won't
be
anything
that
matches
but
yeah,
so
that
would
work.
It's
just
it'll,
just
flood
people
with
warnings
whenever
they're
using
an
odd
version
of
node.
C
A
I
think
there's
a
way
forward
with
us
doing
this
and
and
without
doing
the
greater
than
equals,
because
that
seems
like
that's
what's
biting
us,
and
that
seems
like
it's
also
a
greedy
like
a
greedy
range
that
doesn't
necessarily-
and
I
see
that
even
in
here,
like
we've,
said
that
as
much
but
go
ahead.
Luke.
E
I
don't
have
it
in
front
of
me
and
we
discussed
it
internally
and
it
didn't
get
added
to
the
rfc
or
to
the
issue
but
miles
he
had
some
historical
context
around
greater
than
or
equals
to
being
helpful
in
some
cases,
and
I
can
find
that
in
our
you
know,
internal
thread
and
either
paste
that
into
the
issue,
just
as
a
viewpoint
around
around
why
that
can
be
harmful
in
some
cases.
A
Versioning
here
like
if
we
want
to
maintain
our
versions
or
our
cadence
here
and
get
closer
and
closer
to
the
node
release
cadence,
if
we
want
to
be
more
aggressive
with
version
bumps,
that's
totally
fine,
like
the
the
thing
we
all
agree
with
is:
let's,
let's
versions
are
cheap,
like
I'm,
I'm
not
hesitant
to
have
us
have
more
breaking
changes.
If
it's
these
kinds
of
changes
that
are
let's
say
minimal,
keeping
up
with
like
the
engines
fields
might
help
us
move
quickly,
especially
with
experimental
versions
of
node.
So.
C
So
you're
correct
versions
are
cheap,
but
you
know
what
else
is
cheap,
maintaining
things
on
old
versions.
It's
actually
not
hard,
unless
you
depend
on
things
that
are
doing
frequent,
major
updates.
So
if
your
dependency
graph
isn't
doing
that,
then
it's
actually
incredibly
easy
to
support
old
node
versions.
I
would
say
I'm
the
expert
on
it
and
it's
not
hard.
It's
just
without
a
build
process.
You
there's
some
syntax,
you
can't
use
or
whatever
and.
C
Yeah
yeah
yeah
I
get
that
and
when
there
is
a
time
when
you
actually
need
to
use
something
when
there's
a
real
reason.
Besides,
it's
shiny-
and
I
want
to
use
that
syntax
do
a
major
version
because
versions
are
also
cheap,
but
like
it's
the
it's
the
there's
this
this,
I
think
fud
based
desire
of
individuals
scattered
throughout
the
ecosystem,
a
lot
of
them
who
just
are
like
well,
people
shouldn't
be
using
old
stuff.
So
I'm
doing
a
good
thing
by
pushing
everyone
forward
and
the
ecosystem.
Just
isn't.
A
Yeah
there's
a
couple
couple
things
there,
but
I
feel
like
we're
we're
getting
into
sort
of
strategy
of
what
why
why
we
want
this
in
general
and
luke,
I
see
you're
saying
still
up.
Did
you
want
to
comment
to
them.
A
But
yeah
it
sounds
like
do
we
want
to
keep
this
on
or
we
can
just
talk
about.
This
async
guide
can
remove
the
agenda
label
and
we
can
just
talk
about
this
async.
It
seems
like
we've
got
enough
to
to
probably
muddle
on
this
a
bit
ourselves
and
then
come
back
with
a
strategy.
A
Is
there
anything
kind
of
okay
cool?
Let's
quickly,
then
move
on
to
the
next
item
that
was
in
here.
So
this
is
the
pr
500
5000.
Of
course,
it's
5000,
somehow
roy
got
that
pr
for
the
future.
Npm
query
somehow
opened
it
last
week
or
two
weeks
ago,
when
we
were
at
the
conference,
I
believe
gary
had
picked
up,
are,
are
going
to
pick
up
the
work
now
and
and
continue
to
clean
up
this
pr
and
get
it
ready
to
ship.
I
believe,
jordan.
A
C
No,
I'm
just
fixing
bugs
and
refactoring
a
little
bit
of
code,
most.
A
Cool
so
yeah
we'll
we'll
keep
this.
I
guess
on
our
radar
but
yeah
car.
I
appreciate
you
picking
up
the
work
and
helping
you
get
this
across
the
finish
line
here
and
we'll
hopefully
make
a
bigger,
bigger
announcement
about
when
it
does
land.
So
do
you
see.
B
C
C
C
A
Great
quickly,
moving
on
then
to
pr
595
propose
the
backwards
compatible
improvements
to
compression.
I
believe
we
talked
about
this
like
a
month
ago.
Evan
hamm
brought
this
up.
I
don't
think
we've
done
anything
here,
I'm
not
sure
if
this
was
discussed
last
week
at
all
any
updates
from
folks
other
than
we
have
to
go
investigate
this.
F
A
Moving
on
to
oh
and
your
only
registry
target
balls
pr
number
or
rfc
number
593,
I'm
not
sure
if
you
have
an
update
from
the
last
time
we
talked
or
from.
D
I
do
so
thank
you
for
everybody.
Who's
contributed
feedback
so
far,
so
I've
I'll
actually
paste
it
in
a
little
summary
comment
there,
which
I'll
summarize
here
but
yeah.
D
So
I
applied
some
of
the
the
feedback
from
the
first
round
and
from
our
meeting
where
I
was
just
clarifying
some
points
last
week,
so
I
think
it's
all
good
so
that
the
main
kind
of
touch
points
there
were
moving
this
to
npm
audit
instead
of
install
so
it'll
just
bubble
up
that
way,
set
the
default
flag,
value
or
default
option
set
to
warn
that
took
some
inspiration
from
like
the
npm
y
style
output,
to
kind
of
give
examples
of
what
the
output
could
look
like,
and
I
did
capture
some
of
those
kind
of
future
facing
discussions
around
like
eslint
style
filters,
query
kind
of
stuff.
D
I
just
I
put
that
in
the
the
byte
shedding
section
the
only
I
guess
this
is
just
personally
to
me,
though
I
think
wes
chimed
in
as
well.
I
mean
we
can
chat
about
that
here.
Now
is,
I
know
we
had,
I
know.
Originally
it
was
like
only
registry
tarballs,
and
then
we
had
the
meeting
and
it's
like
well
technically,
it's
you
know
it's
not
just
that.
D
It
could
also
allow
other
things,
so
we
changed
the
name
to,
but
I
have
it
set
to
only
non-remote
depths
but
the
more
of
like
I
still
have
a
little
trouble
kind
of
like
trying
to
walk
that
back,
because
it's
like
asserting
on
a
negative,
and
so
I
just
thought
that
maybe
we
could
take
another
pass
at
the
name
unless
anybody
strongly
objects
to
another
version
of
the
name.
D
I
like
what
wes
came
up
with,
because
I
think
so
two
things
yes
technically
so
wes's
suggestion,
which
I
I
like
that
I
think
more
or
less
hits
the
nail
on
the
head
is
only
registry
depths,
and
I
know
that
yes,
technically,
a
local
depth
like
local
hosts
is
was
one
of
the
exceptions.
D
But
I
guess
I
thought
that
perhaps
that
swayed
the
naming
to
be
so
abstract
that
at
the
risk
of
like
how
do
I
search
for
something
or
how
do
I
think
about
it
or
look
it
up
that?
Maybe
you
know
yes
technically
99
of
the
time
we're
basically
just
trying
to
make
sure
it
comes
from
the
registry
and
that
local
host
is
an
exception.
But
is
it
big
enough
of
an
exception
that
it
should
sway
the
the
name?
I
guess
it
could
not.
C
Depth
anyway,
that's
the
current
state
when
we're
talking
about
a
local
depth.
If
I
do
something,
that's
like
slash
etsy
something
I
can
do
that
right,
because
now
it
can
be
an
absolute
path.
Is
that
cool?
Because
I
would
think
that
I
actually
only
want
registry
depths
or
file
paths
that
are
inside
my
project.
C
Right,
I
think
we
didn't
discuss
restricting
the
scope
of
local
paths,
but
if
the
reason
I'm
asking
is
because
if,
in
fact,
we
want
things
if
the
goal
is
to
have
things
that
the
lock
file
can
lock,
then
that
only
includes
portable
things,
which
is
registry
depths
or
things
within
the
project,
and
maybe
only
portable
depths
or
only
lockable
depths
or
something
would
be
an
alternative
name
and
also
a
more
useful
form
of
the
feature.
D
Yeah
I
mean,
I
guess,
is
that
how
people
think
of
them
already,
I
guess
the
part
of
it
is
how
predominant
or
I
guess,
what
percentage
of
the
registry
or
local
file
like.
D
What's
the
percentage
like
of
of
allowance
right
like
do,
we
think
that
a
local
file
is
going
to
make
up
50
of
the
use
case
unless
it
makes
sense
to
try
and
bend
the
flag
to
it
or,
if,
like
registry
depths
are
like
90,
you
know,
is
it
just
easier
to
say
only
registry
depths
and
in
the
dock
say,
but
also
an
exception
would
be.
If
you
use
this,
you
know
so
just
try
to,
I
guess
thread
a
needle.
D
It's
I'm
totally
fine
with
an
escape
patch,
like
you
know,
just
like
chrome
allows
you
to
hit
localhost
over
https
right.
You
know
like
it's
a
little
thing
like
that,
if
you're
a
developer,
you
know
sure
so
in
that
case,
but
I
think
just
purely
from
naming
it
just
only
registered
death
seems
to
just
nail
the
hit
the
nail
on
the
head
and
I
think
it'd
be
okay.
To
just
add
an
exception
in
the
earth.
A
Subject
so
what
might
help
here
is
this
is
a
set
right
like
the
the
types
are
set.
It's
like
a
group,
another
type
of
grouping
again
as
soon
as
we're
trying
to
lean
into
in
the
grouping
terminology
here,
but
this
is
a
set
that
of
or
type
of
for
different
packages,
so
just
like,
we
have
with
omit
and
include.
A
Potentially
it
makes
most
the
most
sense
for
you
to
explicitly
have
a
comma
separated
list
of
the
or
not
comma
separately.
Sorry,
multiple
essentially
includes
or
onlys
for
this
set,
so
you
can
define
essentially
that
you
only
want
a
registry,
and
that
is
like
a
singular
like
that.
A
The
registry
is
the
key
or
is
the
value
the
key
is
like,
whatever
we
want
to
call
it
like
install
only
or
something
like
that,
and
that's
all
this
set
you
would
set
whatever
whatever
you
want
to
allow
like
your
allow
list
becomes
like
each
one
of
individually
or
them
all
by
default,
which
is
what
the
default
is
right
now,
so
you
support
them
all.
So
then
that
becomes
like
the
allow
list.
So
then
you
get
exactly
what
jordan's
asking
for,
which
is.
A
Maybe
I
want
to
allow
a
few
of
these
other
types
right
and
you
can
do
that.
We
don't
have
to
create
a
flag
for
each
one
of
those.
We
create
a
single
euler
flag
that
can
be
defined
multiple
times
with
a
different
either
a
different
allowed,
or
we
can
do
it
in
a
comma
separated
list
or
something
I
forget
how
we
handle,
omit
and
include
for
prod
and
dev
and
those
types
of
dependencies
when
we
do
that.
A
But
this
is
the
same
type
of
thing
I
feel
like
this
is
a
similar
type
of
set
that
we're
allowing
you
to
omit
or
include,
and
I
think
that
that's
we
should
take
the
same,
similar
strategies
that
you
can
navigate
whatever
you,
whatever
kind
of
matrix
of
of
support
you
want
and
and
what
we
would
really
push
people
towards
is
saying.
Well,
really,
you
should
be
doing
include
only
like
the
registry.
C
A
We
can
have
a
nice
top
like
flag
that
maps
back
down
to
that
that
set
right
so
that
we
get
best
of
both
worlds,
but
the
only
you
know
top
level
flag
that
we
create
is
the
one
for
omitting
like
the
registry
event,
so
that
people
don't
have
to,
but
I
I
feel
like
you
can
get
there
easily.
If
you
I
don't
know
like
I
don't
know,
I
I
feel
like
you
can
navigate
this
pretty
easily
in
terms
of
like
the
design
of
whatever
that
flag
is.
D
So
like
would
query
give
you
that,
like
platform,
so
that
this
can
just
be
amended
to
just
say
you
know,
dot
dash
dash
whatever
whatever,
so
we
just
don't
have
an
install
pure
depth.
It's
just
like
is
it
does
it
does
with
query?
Does
it
because
yeah,
I'm
not
sure.
A
Yeah,
it
becomes
so
much
easier.
Definitely
with
query
like
to
just
leverage
that,
because
you
can
do
essentially
like
not
I'll,
actually
write
it
for
you.
If
so,
if
we
had
a
flag
for
query
added
that
to
audit
or
what
we've
also
considered
is
like
a
standard
standard
in.
D
So
are
you
saying
that
there'd
still
be
like
so
would
you
would
it
only
be
available
through
query?
Would
there
still
be
like
a
vanity
flag
that
maps
down
like
we
would
support
like
three
or
four
like
concrete
rules
that
would
just
be
translated
would
be
down
like
translated
to
npm
query?
But
if
you
want
anything
more
complex,
then
you
have
to
use
npm
query
directly.
A
Yeah,
because
that's
that's
kind
of
like
where
I
think
most
of
our
flags
are
eventually
going
to
map
to
is
a
query
right,
even
omit
include,
etc.
They
map
exactly
to
the
like
selective
syntax
like
like.
We
don't
need
to
like
going
forward.
We
don't
need
that.
That's
why
we're
kind
of
like
in
this
transitional
period,
where
we're
rolling
out
the
first
version
of
the
the
query,
syntax
and
the
the
command
to
actually
run
and
and
and
like
make
the
queries
happen,
but
we
haven't
applied
that
to
any
of
our
like
legacy
commands
right.
A
So
you
know
it
feels
like
we're
trying
to
solve
this
problem
as
well,
even
though,
like
I
feel
like
query,
is
going
to
help
with
every
single
one
of
these
use
cases
that
are
coming
up
right
and
introducing
new
flags.
It's
like.
Should
we
just
hold
off?
I
don't
know
like
how
long
is
it
going
to
take
for
us
to
do
that?
Add
the
new
flag
versus
wait
for
a
query
to
lend
and
then
just
apply
it
really.
Then
the
work
becomes.
A
Hey
owen.
Can
you
go
add
query
support
to
npm
audit.
You
know
that.
Would
be
the
ask
then
for
us,
you
know,
there's
a
blueprint
for
how
to
like
support
query
and
the
the
gray
syntax
inside
of
the
npm
query
command.
Can
you
go
apply
that
to
your
audit?
That
would
be
like
the
ask.
Maybe
then-
and
that's
I
think,
a
lot
more.
Oh
yeah.
A
They're
already
exposed
by
the
way
it's
like.
If
you
run
this
query,
this
actually
works
right
now.
This
works
today,
yeah.
So
if
you
actually
pull
that
down
roy's
pr
and
the
one
that
gar
is
helping
to
to
fix.
A
Wait
a
minute,
of
course
yeah
yeah
yeah,
so
this
actually
works
right
now,
like
you
can
actually
do
get
a
query.
The
thing
that
doesn't
work
is
the
audit
support
right
like,
but
you
can
query
for
the
type
get
like
depth
type.
So
I
apologize
car
you've
got
your
hand
up,
and
then
I
think
we
should
probably
rap
because
I
know
we're
getting.
B
I'm
glad
you
said
the
exact
same
thing
you
did
because
I'm
I'm
saying
dot
should
be
a
dependency
type
which
you
just
said:
depth
type
and
then
the
pseudo
class
selector
is
just
a
pseudo
selector.
So
that's
how
I'm
updating
the
docs
dot
is
dependency
type
selector
and
then
I'm
actually
adding
that
to
this
markdown
file
explain
what
they
are
and
then
colon
is
a
pseudo
selector.
We
don't
need
to
say
it's
just
a
pseudo
selector.
A
Cool,
thank
you.
So
this
doesn't
really
give
you
a
lot
of
clarity.
Oh
and
I
apologize
to
to
move
forward
with,
but
maybe
what
would
be
interesting
is
if
you
can
get
some
time
play
with
that
pr,
you
can
actually
check
it
out
if
you're
using
gh,
you
can
just
check
out
the
pr
locally.
You
do
jh
pr
checkout
and
then
the
name
of
the
number
5000.
A
A
The
hope
is
that
we're
gonna
ship
it
should
be
either
in
minor
or
we're
gonna
hold
off
and
potentially
for
v9.
It
depends
on
how
much
work
there's
left
to
do
it.
I
think
we're
in
this
we're
in
a
bit
of
a
gray
zone
here,
where
we're
gonna
start
work,
that
we'll
have
a
bunch
of
breaking
changes
for
v9,
so
we
might
go
dark
for
a
little
bit
in
terms
of
v8.
D
Okay,
cool
yeah
I'll
definitely
play
around
with
it.
So
yeah
sounds
good.