►
From YouTube: Open RFC Meeting - Wednesday, June 23rd 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
roc
call.
Today's
date
is
june.
23Rd
wednesday
june
23,
2021
we'll
be
following
along
in
the
agenda
with
the
agenda
that
was
posted
in
the
mpm
rfcs
repo
issue
401
for
folks
who
are
on
the
call
feel
free
to
add
yourselves
as
attendees
to
the
hakim
d-doc,
I've
shared
and
spammed
there
in
chat
apologize
for
the
spam
and
yeah
just
quickly.
A
I
want
to
remind
folks
that
these
calls
and
all
communications
on
the
npm
rc's
repo
are
covered
under
a
code
of
conduct.
That's
linked
there.
We
just
ask
that
people
plea
be
kind,
as
others
are
talking.
Please
raise
your
hand
and
we'll
call
on
you
if
someone
else
is
talking
and
yeah
just
in
general,
please
please
be
mindful
of
of
others.
I
want
to
give
some
time
for
folks
if
they
have
any
announcements
or
any
news
that
they
want
to
share.
A
If
not,
I
just
want
to
be
mindful
or
remind
everybody
that
we
are
constantly
cutting
new
releases
of
the
cli.
So
if
you
haven't
got
the
latest
version,
we
got
a
release,
7.18
and
then
18.1
went
out
on
thursday
of
last
week
so
feel
free
to
get
it.
A
We
are
now,
I
think,
fully
workspace
aware
that
was
the
biggest
thing
that's
launched
recently
for
our
team
and
are
continuing
to
to
make
improvements
there
on
the
cli.
So
if
you
want
to
get
it,
you
can
get
in
the
usual
ways,
but
yeah
other
than
that.
Let's
dive
in
the
first
item
we
had
here
were
actually
a
couple
prs
that
I
know
gar
had
identified
that
we
wanted
to
speak
to
a
little
bit.
A
B
No,
this
is
on
the
agenda
just
because
of
my
newness.
I
haven't
had
this
discussion,
I'm
making
assumptions,
and
I
wanted
to
talk
them
out
here,
because
we
don't
have
a
json
output
of
this
command.
I
assumed
the
regular
output
was
our
machine
contract
and
that
we
can't
change
it
and
that's
what
I
wanted
to
confirm
here
and
I
assume
the
answer
is
correct,
but
I
I
have
to
hear
that
conversation
before
I
can
close
things
like
this
in
the
future.
So
that's
it.
This
should
be
quick.
B
I,
if
we
can't
accept
this,
because
it
would
be
a
breaking
change,
because
the
output
of
that
command
is,
is
the
thing
people
are
consuming
machine
wise
like
for
things.
Obviously,
things
that
have
done
json
json
are
just
parsable.
I
think
we
have
a
lot
more
leeway
in
changing
the
output,
because
this
we
don't
this
yeah
machine
parsing,
it
wow.
C
Good,
I'm
just
going
to
say
even
with
the
dash
jason,
I'm
I'm
sure
that
there's
a
fair
amount
of
the
ecosystem,
relying
on
the
non-json,
not
that
that
is
desirable,
but
unfortunately
the
way
it
is,
and
I
think
that's
what
jordan's
comment
was
pointing
at
I'm.
I'm
pretty
confident
that
this
would
break
nvm,
and
I
am
not
entirely
sure
how
nvm
would
resolve
this,
because
it
would
have
to
know.
C
Well,
I
guess
it
wouldn't
have
to
know
just
have
to
handle
both,
but
either
way
would
you
know,
add
a
bit
of
complexity
there
and
that
one
thing
alone
is
is
pretty
breaking.
I
would
say,
because
nobody
updates
their
nvm,
so
we
would
have
to
like
roll
it
out
in
such
a
way
that
it
didn't
break
everybody's
nvm,
or
only
I
I
anyway.
I
don't
know
how
to
make
that
even
work
with
a
major
breaking
change
without
going
out
and
getting
nvm
and
probably
and
like
a
bunch
of
the
other
version
managers,
updated
cool.
B
Thanks
yeah,
it
didn't
sound
like
anyone
was
gonna
say
that
this
needed
to
land.
So
that's
good
enough
for
me.
I
could
close
this
pr.
I
just
wanted
to
make
sure
it
happened
here,
because
this
was
the
appropriate
place
to
have
the
conversation.
Thank
you.
That's
all
the
time
we
really
need
to
spend
on
this.
In
my
opinion,.
A
I'll
remove
the
label
from
the
pr
if
you're,
gonna
close
so
following
up
with
that,
there
was
the
pr
3437,
and
this
is
to
fix
the
error,
or
essentially,
I
say
fix.
This
is
to
essentially
add
json
to
alice
in
search
when
they
error
out.
Is
that
correct?
Is
that
a
correct
synopsis
of
this
car
yeah
and
again?
In
this
case,
we
what's
the
recommendation
actually
know
if
you
were
the
last
one
to
comment
well.
B
This
is
a
little
more
than
just
a
recommendation
on
its
face.
We
can't
accept
this
pr
simply
because
this
would
require
a
an
architecture
decision
npm
to
say
when
I
have
dash
dash
json
errors
now
are
also
going
to
show
up
on
standard
out
and
they'll
be
formatted
in
json,
which
is
not
a
thing
we
currently
do.
People
aren't
expecting
it.
Nelf
has
his
hand
up.
D
It
could
be
that,
rather
than
merging
the
objects
together,
they
go
to
different
streams
that
are
both
json,
but
we
definitely
should
not
be
outputting
anything.
That's
not
json.
When
the
user
asks
for
json.
B
C
So
this
one's
interesting
to
me,
because
you
know
obviously
errors
that
you're
handling
are
great
and
well,
but
if
you're
a
consumer-
and
you
were
trying
to
rely
on
those
you
know
always
being
handled,
I
think
you're
not
really
doing
I
mean
you
can't
right
like
sometime.
Npm
is
going
to
have
a
non-handled
error
and
it's
going
to
fall
back
and
print
a
stack
trace
and
that's
sort
of
like
I
don't
know,
I
don't
want
to
say
expected,
but
at
least
just
the
reality
of
it.
B
Well,
that's
an
assumption.
We
don't
have
to
make,
though,
because
we
have
a
unified
exit
handler
right.
That
cannot
unhandle
exceptions.
We
could
just
look
at
that
flag
and
say:
oh,
they
want
a
json
now
when
we
dump
to
the
output,
we
somehow
converge
today.
So
it's
not
an
unsolvable
problem.
I
would
say
well.
E
It's
a
smaller
it's
a
smaller
problem
than
what
west
is
suggesting,
but
it
is.
There
is
an
unsolvable
problem
there.
If
we
there
are
cert,
there
are
classes
of
errors
that
are
going
to
cause
a
like
c,
plus
plus
stack
trace
in
node.
You
know,
if
you
seg
fault,
or
something
like
or
there's
an
out
of
memory
error
like
that's
gonna,
dump
a
bunch
of
garbage
to
standard
error
and
there's
nothing.
E
We
can
do
about
that
because
at
that
point
our
our
exit
handler
has
been
thrown
out
the
window
as
well,
but
we
can
definitely
catch
any
just
like
thrown
errors
from
javascript
and
ensure
that
those
are
always
json,
and
I
think,
if
you
do
json,
then
we
should
do
everything
we
can
to
make
sure
that
standard
error
and
standard
out
are
outputting.
A
conformant
json
object.
C
A
Yeah,
I
think
your
connection
might
be
a
little
bit
a
little
crunchy.
E
A
I
think
you're
breaking
up
jordan,
so
you
can
jump
to
a
different
wi-fi
or
a
different
connection.
F
Yes,
so
you've,
no
one
has
ever
been
able
to
rely
on
standard
error
being
json
like
that's
just
not
a
contract.
Anyone
can
expect
for
many
reasons,
one
of
which
is
what
wes
mentioned,
which
is
that
node
puts
all
its
deprecation
errors
there.
The
only
thing
I.
F
With
json
is
that
standard
out
is
always
json
in
the
same
way
as
if
I
make
a
web
request
to
a
web
server
and
tell
it
that
I'm
accepting
application,
slash
json,
I
would
only
expect
a
successful
request
to
give
me
json
all
bets
are.
B
F
G
Yeah
something
like
that,
just
something
that
I
can
set
in
my
mpmrc
or
as
a
config
like
a
you,
know,
npm
config,
whatever
that
I
guess
that
sets
in
the
rc,
but
that
sets
json
output
as
or
standard
error,
as
json
output.
A
Yeah,
I
guess
you
could
set
json
true
and
then
the
expectation
would
be
that
all
output
would
be
that.
But
if
you
want
to
separate
output
from
errors,
then
that
would
be
a
net
new
config
right.
So.
E
There
are
some
there
are
some
cases
where
we
print
something
that
could
conceivably
be
considered
an
error
right
like
like.
If,
if
we
do
ls
and
there's
ls
errors,
we
we
kind
of
embed
the
like
those
aren't
errors
with
the
operation.
Those
are
hey
like
there's.
A
problem
with
your
package
tree
and
the
output
of
this
ls
command
is
to
tell
you
what
those
problems
are.
E
You
know
similarly
well
warnings
for
engines
actually
print
a
standard
error
right
like
there's,
there's
a
bunch
of
things
that
we
print
to
standard
error,
and
we
should
just
keep
printing
to
standard
error
as
just
regular
old
strings
and
the
standard
out,
if
you
do
json
standard
out,
is
a
single
json
object.
That's
our
contract.
E
A
Across
the
cli,
I
think
that's
like
rc
worthy
if,
for
this
specific
pr,
which
is
introducing
it
to
alice
in
search
like
what?
How
do
we
want
to
move
forward
here?.
A
Yeah,
okay,
car,
would
you
be
okay
with
owning
giving
that
feedback
to
the
to
ramas
from
us,
or
we
can
also
own?
If
we
think
this
is
something
we
actually
want
to
do,
then
we
can
own
that
action,
but
I
don't
think
I
don't
think.
A
Excited
about
this
yep
so,
unless
folks
have
any
other
comments,
feel
free
to
pile
on
in
the
pr
if
you
want-
and
hopefully
if
this
person
is
interested
in
this-
that
we'll
see
an
rfc
come
along
moving
on
then
to
our
rfc
roy.
This
is
the
top
level
command
to
manage
package.json,
I'm
not
sure
if
you
got
a
chance
to
actually
action,
creating
an
actual
rfc.
H
Yeah
yeah,
I
open
a
metro
rcpr
that
we
can
continue
the
conversation
on
it's
an
early
draft,
still
kind
of,
but
can
continue
the
conversation
there
and
I'll
keep
updating
it.
So
yeah,
I
think
important
update
is
that
we
landed
part
of
the
refactor
that
was
needed
to
kind
of
enable
working
on
this
or
at
least
make
it
easier
to
manage.
So
that
part
is
probably
landing
tomorrow
using
tomorrow's
release,
which
is
which
is
basically,
we
cut
a
nice
little
package.json
module
that
that
will
basically
save
things.
H
The
way
that
npm
collider
does
so
yeah.
So
there's
that
in
terms
of
update
and
if
we
can
continue
the
conversation,
I
think
yeah
we'll
probably
still
want
to
flesh
out
the
syntax
on
the
how
to
deal
with
npm
pkg,
less.
C
E
Post,
I
I
very
much
do
not
want
to
add
a
new,
very
sort
of
ambiguously
named
config
value
of
key
and
value
like
that's
that
that
sort
of
raises
some
alarms
for
me,
but
like
they
should
just
be
positional
arcs.
I
think
same
same
same
with
config
and
config
set.
C
H
C
You
know
like
eslint:
configs
is
one
but,
like
also
you
know,
standard
has
some
of
this.
A
ton
of
different
cli
tools
have
data
structures
that
need
deep
nesting
and
having
key.
I
just
think
this
keeps
the
door
open
for
that
for
their.
You
know
docs,
to
use
this
in
the
future
and
and
tell
people.
Oh
just
run
this
one
command
and
it
will
do
the
proper
thing.
C
Or
yeah
anything
else
right,
actually
one
other
nice
addition
would
be
as
if
the
value
that
you're
setting
could
be
just
a
json
formatted
object
as
well,
so
you
could
set
it
like
scripts
dot.
Well,
maybe
not
scripts.
What
would
be
something
yeah
in
here
tap,
so
you
could
say
like
tap
equals.
C
You
know
jason
with
timeout
in
it.
H
That
is
trickier,
though,
and
implementation-wise
like
will
it
start
reading
merging
objects.
F
E
Matter
what
right?
But
if
you
set
the
key
as
a
let's
say,
an
object
right,
so
npm
pkg
set
tap
dot,
timeout
equals
60
means
take
the
it's
not
just
right,
you've,
just
typed
exactly
what
does
it?
Let's
say:
okay,
it
means
take
the
tap
object
and
if
there
is
no
tap
object,
create
an
object
and
then
set
the
timeout
value
on
that
object
to
60.
npm
pkg
set
tap,
equals
open,
curly,
brace,
quote
timeout
colon
60,
close
curly
brace
means
clobber
that
object
with
this
one.
E
The
the
thing
to
figure
out,
I
think-
and
it's
not
it's
not
going
to
be
a
particularly
contentious
bike
shed.
I
don't
think,
but
the
thing
to
kind
of
specify
and
just
be
very
clear
about
in
the
rfc
is:
what
do
we
do
about
keys
that
are
not
valid
json
like
or
keys
that
include
dots
like?
E
What's
our
what's
our
approach
for
that,
and
especially
keeping
in
mind
that
json
is
not
like
the
best
thing
to
be
writing
on
the
command
line
like
you
got
to
get
the
quotes
right
and
everything
it's
kind
of
a
pain
so.
F
A
E
Views
implementation
is
bad,
it
it
doesn't
it
doesn't.
It
doesn't
support
any
keys
that
have
dots
in
them
at
all.
It
just
doesn't
work
and
you
use
dots
to
separate
keys
that
have
hyphens
or
spaces.
It's
literally
just
split
on
the
dot
and
then
walk
the
object
with
those
with
those
values.
The
other
thing.
E
E
E
A
E
F
So
it
sounds
like
whatever
we
come
up
with
here
for
package
that
is
going
to
not
be
something
that
we
can
make
config
do
in
a
non-breaking
way.
Is
that
accurate.
F
Like
like
whether
it
configure
as
a
nested
object
or
not,
is
something
that
we
could
add
at
any
future
time,
but
I
mean
in
order
to
add
that
we
would
have
to
first
make
the
flat
form
of
config
match
what
package
does.
So
that
was
all
the
same,
and
if
package
takes
a
key
of
like
a
dot
b
and
assumes
that's
nested,
then
that
means
that
config
would
have
to
not
assume
it's
flat
for
them
to
be
compatible.
Yeah.
E
So
I
mean
there's
going
to
be
there's
going
to
be
some
work
to
get
to
a
place
where
we
can
have
nested
configs
ray
even
only
only
allows
certain
top
level
fields
to
be
nested
or
or
whatever,
or
we
may
want
to
use
dots
in
a
different
way.
Just
because
it's
ini
format,
it's
not
right,
json
format.
E
F
F
E
F
B
E
Well,
let's,
let's
write
up
the
let's
write
up
the
json
rfc
with
what
makes
the
most
sense
for
setting-
and
you
know
conveniently
setting
and
getting
package
json
objects
and
then
and
and
then
kind
of,
specify
like
or
write
out
or
explore
a
little
bit
like
where
we
want
config
to
go
and
sort
of
plot
a
course
there.
E
I
think
you're
right,
like
deprecating
anything
with
dots
in
it
is
probably
a
good
first
step,
but
I
just
want
to
like
sort
of
sketch
out
the
sketch
out
the
plan
and
sketch
out
the
destination,
and
then
we
can
see
okay
does
that
actually
get
us
closer
or
not,
and
what?
What
is
the?
What
are
the
subsequent
steps?
After
that.
E
E
Actually
I'm
further
kind
of
thinking
about
this,
because
what
that
means
is
you
can't
set
it
to
a
string
of
json
or
we
have
to
be
detecting
it
or
we
have
to
require
that
the
right
hand
side
of
that
equal
sign
is
always
valid
json,
which
means
you
can't
do.
Npm
pkg
set
foo
equal
bar
right.
It
has
to
be
fu,
equal
double
quote,
bar
close
double
quote,
and
that
is
a
nightmare
to
type
on
a
client
like.
If
I
have.
E
No
because
json
is
output
strictly,
so
I
think
what
we
should
do
is
just
say
if
you
want
to
replace
the
object
with
a
new
object.
That
includes
just
this
one
key.
You
know
it's
two
commands
you
you
delete
it
and
then
you
set
tab.timeout
equals.
H
Yeah
sad,
like
would
basically
add
that
key,
if
that
key
is
missing
or
changing
it.
If
it's
already
there
right
in
the
example
of
tap
timeout,
if
it's
already
there,
it's
just
going
to
be
replacing
the
value
that
is
there,
we
can
also
have
a
gap
to
get
tap.
Timeout
will
just
retrieve
that
value,
and
I
remove
so
that
you
can
just
delete
the
key
and
the
value
completely
from
there.
What.
E
G
A
Array:
okay:
let's
move
on,
I
know
that
this
just
got
created
today.
So
folks,
if
you
have
more
comments,
feel
free
to
add
to
the
rfc
there,
which
is,
I
think
it
is,
are
there
any
command.
E
The
json
object
like
get
gets
are
fine.
We,
you
know
we
can
use
square
braces
for
keys
that
are
not
that,
have
dots
or
spaces
we
can,
you
know
or
just
escape
spaces.
We
cannot
separate
it.
Otherwise,
like
that's,
not
a
hard
parsing
problem,
the
the
tricky
thing
is
making
modifications.
So
if
I
want
to
get,
if
I
want
to
like
remove
a
particular
entry
from
an
array
or
if
I
want
to
add
an
entry
to
an
array
like,
I
can
imagine
some
ways
to
do
it,
but
maybe
we
don't
have
to
invent
that.
F
E
E
A
Yeah
I've
also
seen
the
user
lands.
I
was
trying
to
find
them
right
there,
too,
jordan
there's
a
couple
tools
that
I've
I've
seen
as
well.
I
forget
what
they
are
okay,
so
let's
look
for
some
prior
art
as
well
roy,
I'm
not
sure
if
you
added
a
section
there
for
prior.
H
B
B
It's
kind
of
not
that
helpful
because
it
doesn't
tell
me
maybe
what
could
be
updated
versus
what
can't
be
updated
and
ultimately
that's
the
the
thing
I
need
to
know,
and
even
when
you
do
mbm
outdated
you'll
see,
maybe
something
is
represented
four
times
and
twice
it's
red
and
twice
it's
yellow,
because
you
know
these
two
things
could
have
updated,
but
because
these
two
required
a
more
limited
one,
it
deduped
down
to
the
lower
one
things
like
that
are
not
easy
to
track
down
and
see,
and
I
know
what
isaac
suggested
is.
B
B
I
don't
know
that
I'm
much
more
than
that
other
than
we
would
like
to
solve
the
problem
of.
How
do
I
easier?
How
do
I
better
see
what
could
be
updated
either
this
flag?
Maybe
we
look
at
this
and
everyone
says
no
isaac
you're
wrong
or
we
say
yeah.
Let's
do
it
this
other
way.
So
that's
it's!
That's
what
the
discussion
is.
B
F
F
That's
a
happy
safe
command
like
show
me,
the
the
you
know,
let's
just
update
all
the
dependencies
yay
but
like
the
other
use
case,
is
one
that
it's
not
very
effective,
for,
which
is
show
me
all
the
stuff
that
I
have
to
go
out
of
my
way
to
upgrade
to
because
it's
probably
gonna
break
and
like
usually
what
I
do
is
I
manually
like.
I
update
all
my
dependencies
within
the
range
and
then
I
run
a
different
command
like
an
npm
package.
F
You
know
I
think
npm
update
dry
run
is
a
great
idea,
and
I
think
that
it
would
probably
cover
that
first
use
case
completely
in
a
very
intuitive
way,
but
like
when
people
run
out
npm
outdated.
I
think
they're
conflating
both
of
those
things
in
their
head
right,
so
like
by
the
eslint
six
and
esl
7
is
out.
I
don't
want
to
know
that
the
next
minor
is
out.
I
want
to
know
that
seven's
out,
because
I'm
outdated
right,
like
anyway
yeah.
E
If
we
printed
the
diffs
on,
if
we
printed
the
diff,
when
you
do
a
dry
run
reify,
then
I
I
think
that
would
that
would
probably
just
be
a
good
first
step
anyway,
right
like
because
right
now,
install
with
dry
run
is
profoundly
useless.
E
F
Yeah,
so
I
I
don't
use
npm
update
because
over
the
years
in
npm
versions,
it's
done
different
things
and
often
not
what
I
expected.
So
I
actually
really
like
the
idea
of
dry
run.
Just
for
the
sake
of
it
would
allow
me
to
see
what
it's
about
to
do
and
figure
out.
If
maybe
this
is
actually
a
command
I
can
use
now
because
it
matches
my
expectations.
B
F
That's
it.
I
think,
it's
that
what
I
was
describing
about
the
two
mental
models,
like,
I
think
the
like.
I
want
to
upgrade
dangerous
things.
That's
what
I
would
want
to
flag
on
outdated
for,
like
I
want
the
default
view
of
outdated
to
kind
of
be
like
show
me
in
range
things,
I'm
missing
and
the
flag
to
be
like
show
me
out
of
range
things,
I'm
missing,
but
I
don't
know
if
that's
exactly
what's
being
requested.
B
Even
if
it's
not
that
could
be
what
this
pull
request
is
now,
if
you
could
give
it
a
once
over,
make
sure
the
language
makes
sense
with
what
your
mental
model
is.
That
can
solve
that
problem,
then
the
dry
run
about
npm
update
could
be
a
separate
one.
I
would
really
appreciate
that
review
jordan.
Then
I
could
go
forward
with
this
pull
request,
knowing
better
defining
the
problem,
we're
solving
right.
Okay,
thank
you.
A
A
I
I
mean
yeah
because
well
reporting
on
out
of
range
updates
for
transit,
which
means
isn't
useful
because
you
have
no
way
of
actually
updating
them
yourself,
so
this
would
be
for
your
direct
dependencies,
which
is
yeah.
I
think
that
there
are
those
two
modes
there's
like
my
tree,
something
deep
in
my
tree
might
be
out
of
date
and
I'd
like
to
update
it
and
then
there's.
I
want
to
actually
make
a
change
to
my
dependencies
and
those
are
different.
Mental
models.
B
A
Okay,
if
folks
want
want
to-
or
I
guess
jordan
specifically
if
you
want
to
take
a
look
at
that
type
here-
that
would
be
great
yeah.
A
Out
a
comment
now
cool
moving
on
then
we
have
about
15
minutes,
left,
rfc,
sorry,
rfc,
392
group,
outdated
packages
by
dependency
type.
This
was
opened
a
couple
weeks
back.
I
forget.
If
we've
discussed
this
yet.
A
Nobody,
it
looks
like
nobody
has
confident
commented
yet
on
this
seems
interesting
again.
It's
in
the
similar
vein
to
improving
the
outdated
output.
C
I,
the
tooling
we
have
at
work.
I
initially
had
a
similar
output
where
things
were
mixed
and
I
got
this
exact
same
feedback
from
like
multiple
different
user
groups.
Totally
unrelated,
they
said
hey.
Could
you
group
by
type
so
I
feel
like
that
is
a
bit
of
user
research.
That
says
this
might
be
a
good
user
experience,
improvement,
100,
yeah,
sorting.
A
B
A
B
B
E
We
could
we
could
actually
kind
of
split
the
difference
here
pretty
nicely,
so
the
the
way
that
I
might
approach
this
is
effectively
we
we
sort
by
sort
by
the
the
dev
type
and
then
my
name,
but
then,
if
something
is
a
name,
that's
already
been
mentioned.
It
basically
gets
mentioned
under
that
name
like
so
we're
sort
of
sorting
by
the
first
dev
type
that
that
a
given
name
was
found
under
and
then
by
name.
If
that
makes
sense,.
E
B
I
This
other
book-
well,
it's
I
mean
the
current
docs
anyway,
and
my
memory
of
how
it
was
how
it
worked
at
one
point
at
any
rate,
was
that
yeah
that
it
should
only
be
doing
top
level
dependencies.
E
I
Even
though,
even
though
it
was
at
a
deeper
level,
got
it.
E
Right,
so
we're
well
only
because
that
node
was
a
top
level
depth,
but
if
something
else
depended
on
it,
then
that
dependency
will
also
be
shown.
It
was.
E
B
I,
like
your
suggestion,
isaac.
We
just
have
to
make
sure
that
we're
being
consistent
with
what
order
of
priority
we
give
things
like
production
comes
first
dead
consecutive
we've
kind
of
started
that
at
arborist,
with
one
of
the
last
three
factors
trying
to
consistently
go
through
the
military
order.
This
would
need
to
make
sure
it
follows
that,
but
other
than
that,
that's
I
think,
that's
perfectly
acceptable.
How
that
outputs?
I
don't
know.
A
So
maybe
if
we
can
get
some
feedback
actually
on
this
rfc,
that
would
be
great
and
it
still
sounds
like
useful,
very
useful
and
in
line
with
what
we
just
did
with
the
in
range
flag.
So
I
would
love
more
filtering
of
outdated
update,
so
yeah
cool.
If
we
can,
let's
move
on
to
and
and
thanks
for
adding
notes
there
isaac
to
the
what,
where
are
we
at
number
seven,
our
rfc
390.?
A
So
this
is
npm
publish,
should
fail
when
files
are
misconfigured
in
package
json
or
they
don't
exist,
and
I
believe
we
had
a
good
conversation
about
this
with
the
was
this
the
globbing
discussion
last
week.
E
E
It's
a
simple
thing
to
ask
for
in
a
deceptively
complicated
thing
to
deliver,
because
because
those
things
are
globs
because
they
can
have
you
know,
negated
globs
included
in
them
and
like
we
could.
We
could
do
something
like
this
and
say:
yeah
we're
going
to
not
you
know.
If
if
a
glove
doesn't
match
anything,
then
then
we
could
print
a
warning
or
something.
E
E
You
know
in
the
simple
case
where
you're,
including
just
a
folder
or
a
file
yeah
we
can.
We
can
certainly
do
that
relatively
easily,
but.
A
Okay,
so
I
I
don't
know
if
we
had
any
action
items
from
last
week,
then
dude.
Nobody
commented
on
this
in
the
last
week
or
two,
so
I'm
just
wondering.
If
there's
do
we
want
just
essentially
close
up
the
discussion
and
say
like
either.
F
Go
ahead,
jordan.
I
see
you
keep
yeah,
I
guess
I'm
just
from
what
we
talked
about
last
week
I
mean
I.
I
continue
to
believe
that
with
a
glob,
you
can't
know
the
intention
about
whether
they
expect
a
file
to
be
there
or
not.
But
the
semantics
it
almost
always
has
is.
F
Nothing
is
fine,
but
without
a
glob,
even
if
it's
just
brace
expansion,
the
semantics
is
that
you're
pointing
explicitly
to
a
thing,
and
so
I
think
it
would
be
really
useful
to
warn
and
eventually
error
on
those
whether
we
you
know
you
could
maybe
warn
on
a
glob,
but
I
feel
like
that
would
be
like
just
particularly
noisy
well.
E
From
the
like,
well,
when
dealing
with
ignore
files,
it
is
it's
it's
treated
as
just
another.
It
is.
It
is
a
glob
because
it's
not
shell
globs.
It's
ignore
file,
gloves
they're
slightly
different
semantics,
okay,
so
what
we
would?
What
we
would
just
need
to
be
clear
on
is,
if
you
do,
you
know,
open,
brace,
a
comma
b
in
your
files
list
and
we
have
a
and
we
don't
have
b.
That's
that's
a
pass
that
works.
There's
no
warning
there.
E
If
you
have
files
a
and
another
files
entry
b,
even
if
those
two,
even
if
a
and
b
are
globs,
they
both
have
to
match
something.
E
So
you
know
the
other.
The
other
kind
of
potential
area,
for
just
being
very
clear,
is
does
it
have
to
match
something
new,
because
right
now
what
we
do
when
we,
when
we
create
the
package
list,
the
pat
the
pack
list
of
files,
we're
just
sort
of
like
squashing,
all
those
arrays
together,
and
so,
if
you
have
two
entries
and
files
that
match
you
know
like
there's
a
slash
star
and
then
there's
a
or
b
star
and
the
second
one
only
matches
things
that
are
in
the
first
one.
E
Do
we
call
that
a
warning
or
an
error,
and
I
would
I
would
suggest
no,
we
don't
it's.
Just
each
glob
in
files
has
to
match
something.
If
it's
not
a
negated,
glob
and
if.
F
F
Right,
I
would
be
very
surprised
if
we
found
an
existence
of
a
files
list
in
the
wild,
where
the
author's
intention
with
that
had
braces
like
a
comma
b
and
where
the
author's
intention
was
not.
I
always
want
those
both
of
those
two
files
like
I
I
would
be.
I
would
be
very
surprised
to
learn
that
somebody
didn't
expect
shell
semantics
there.
F
I
mean
I
get
that
that's
how
it
plays
out.
I'm
just
saying
that
like
that
that,
because
that's
how
it
works
on
the
shell
and
that's
where
most
people
are
likely
to
use
that
that
syntax,
my
suspicion
is
that
their
expectation
will
be
informed
by
that
and
thus
like
now
that
we
can
still
like
it's
still
fine
to
say
we're
not
going
to
do
it
because
that's
the
way.
Git
ignore
semantics
works.
A
F
Yeah,
I
mean
we'd
start
with
a
warning
anyway
right.
We
obviously
we'd
like
evolve
towards
an
error
on
anything,
but
I
think
the
big
question
is
when
we
believe
it's
missing
versus
when
we
believe
it's
just
not
there
and
that's.
Okay,
like
that's
what
I
think
we're
discussing
now
and
what
isaac,
what
I'm
hearing
isaac
say
is
that
the
git
ignore
semantics
are
such
that
everything
that
has
that
isn't
a
literal
entry,
it's
possible,
it's
okay,
to
be
missing!.
E
E
E
So
we
match
the
folder
and
we
continue
our
exploration.
We
say
okay,
this
is
this
is
a
place
I'm
supposed
to
go,
look
for
more
files,
and
then
I
don't
find
any.
If
that
has
to
be
a
warning,
that's
going
to
be
really
tricky.
Okay,
right.
B
After
two
weeks
of
discussion
here,
I'm
wondering
if
this
is
the
right
choice.
We
are
trying
as
an
org
here,
to
bend
away
from
guessing
user
intent
and
to
bake
guest
user
intent
to
something
this
core,
I
think,
is
a
mistake.
This
is
a
problem
solvable
with
hooks
or
not
hooks
scripts
like
a
pre-publish.
B
If
you
want
to
pull
out
your
npm,
you
know,
do
a
json
of
mpm
pack
or
something
and
compare
it
to
your
glove
and
see.
If
you
know
something
didn't
match,
is
this
a
problem
we
could
solve
in
a
way
that
people
could
do
if
they
wanted,
but
we
don't
bake
into
npm
publish
because
this
feels
I
don't
know
after
two
days,
I'm
like,
let's
not
we're
guessing
user
intent
and
that's
when
I
raise
my
hand
and
be
like
let's
stop.
E
Yeah
so,
and
that's
also
why
I'm
saying
like
we
have
to
be
able
to
summarize
exactly
what
gets
warned
on
in
in
a
very
precise
way,
very
clearly
right
like
if
and
just
say,
look
if
you,
if
you
have
something
if
you
have
files
lib
and
that
lib
folder
is
there
we're
not
gonna
warn
because
you
specified
a
thing
that
exists
if
the
file
was
if
the
folder
is
empty
and
it
doesn't
actually
include
any
files
like
okay.
Well,
don't
you
know
do
like
lib
star.js?
E
If
that's
what
you
cared
about,
you
know,
but
yeah
it
does.
E
When
we
get
into
things
like
treating
brace
expansion
or
empty
folders
as
something
other
than
like,
was
there
a
match
or
not,
then
that's
very
much.
You
know
guessing
user
intent
problem
because
and
it's
just
technically
very
tricky.
A
Okay,
we
only
have
a
few
minutes
left
and
I
did
want
to
get
to
a
couple
updates
and
just
also
get
to
the
last
few
at
least
noted
agenda
items
here.
If
folks
can
please
add
some
of
this
context
back
to
the
rfc
like
zb
is
the
only
person
who's
actually
commented
on
this,
and
it
was
two
and
a
half
weeks
ago.
A
So
if
we
can
pull
out
some
of
the
insights
that
you
have
isaac
and
give
some
feedback
that'd
be
great
just
so
that
we
have
it
documented,
not
just
in
these
meeting
notes,
but
also
in
the
thread
itself
so
quickly.
Moving
on
roy
did
you
want
to
speak
to
the
workspaces,
auto,
switching
rfc,
I'm
not
sure
if
we
had
action
items
on
this.
H
Yeah,
I
don't
think,
there's
anything
to
comment
on
the
on
these
two
items
that
have
my
name
attached
here.
Basically,
this
this
one,
I
know
the
next
action
night
and
it's
just
to
clean
up
the
rfc
and
note
the
empmrc
option
we
discussed
last
time
and
just
continue
the
conversation
but
steering
towards
that
direction
later
on,
but
I
think
we
discussed
it
past
meeting.
We
can
probably
move
on
to
the
next
item.
A
So
I'm
just
putting
no
updates
for
now
and
guard.
I
think
the
next
one
is
yours:
it's
319,
multiple
disk
tags
proposal,
yeah.
B
A
I'll
just
say:
there's
no
update
for
now
and
I
think
the
last
one
is
tierney.
Did
you
want
to
give
a
quick
update
on
this
rc
yep.
G
G
Running
licensing
with
the
flag
is
planned
that
we
will
or
that
I
I
slash.
We
will
update
it
to
to
run
licenses
lesson
checking
on
by
default
if
and
return
nothing.
If
there's
no
license
configuration
like
it
won't
do
anything
if
there's
none
yeah
and
have
kind
of
flags
and
basically
have
good
dx
around
it.
I
would
love
to
get
ideas
and
thoughts
in
there
and
review
if
people
have
it,
but
it's
very
much
not
done
yet
so
we'll
be
continuing
to
work
on
that.
F
A
I
put
the
link
to
the
pr
just
in
the
notes
and
also
here
in
chat
if
folks
want
to
go
check
that
out,
it's
a
draft
right
now
so
still
being
worked
on
and
appreciate
roy.
I
think
compared
with
you
on
that
attorney,
so
I'm
great
to
get
that
started.