►
From YouTube: Open RFC Meeting - Wednesday, August 18th 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
Awesome
and
we're
live
thanks.
Everybody
for
coming
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
august
18th,
2021
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
435
in
the
mpm
rfc's
repo.
A
As
usual,
we
ask
folks
to
please
abide
by
the
code
of
conduct
in
these
calls.
Please
be
respectful
and
raise
your
hand
when
others
are
speaking
and
I'll.
Try
to
call
on
you
and
hopefully
have
a
good
discussion.
I
want
to
open
up
the
floor
for
folks,
if
there's
any
announcements
that
anybody
have.
A
Nothing
to
share
as
normal.
Our
team
is
constantly
shipping
weekly
releases,
so
if
you
haven't
feel
free
to
grab
the
latest
version
of
the
pmcli,
we'll
be
cutting
another
version
tomorrow.
Thursdays
are
our
weekly
release
day,
so
yeah,
that's
the
only
announcement
I
had
on
my
side,
as
I
noted
we'll
be
following
along
in
the
agenda
and
here's
a
link
to
the
meeting
notes.
A
The
first
item
we'll
jump
right
in
unless
there's
anything
else
that
folks
had
to
share.
The
first
item
is
pr
434.
This
is
an
rfc
essentially
denoting
having
v7.
You
know
have
some
sort
of
mechanism
for
defining
the
package
lock.
It
supports.
I
know
jordan,
I
saw
you
just
jumped
on.
You
were
one
of
the
few
people
that
I
think
looked
through
this
and
gave
some
feedback,
I'm
not
sure
if
you,
which
one
this
is
pr434.
A
This
is
the
supporting
package
like
json
v3
in
npm,
seven.
Essentially,
it's
the
idea
that
not
back
having
sort
of
a
backwards
compatible
implementation
for
for
package
logs
explicitly
defining
what
package
lock
the
cli
is
supporting.
A
B
The
the
issue
here
is
that
they
have.
They
know
that
they're
using
npm
7
and
above
so
they
are
never
going
to
be
reading
from
the
dependencies
sort
of
backwards
compatibility
block
in
the
package
log
file
and
would
prefer
to
have
a
file.
That's
half
the
size
and
you
know
make
it
so
that
changes
only
have
to
be
reviewed
once
this
is
pretty
straightforward
to
do.
B
I
think
the
suggestion
that
it
be
pivot,
based
on
the
engine's
data
npm
value,
is,
is
probably
going
to
be
trickier
than
it
seems
just
because
then
we're
we're
having
to
kind
of
detect
we're
inferring
a
config
value
based
on
the
overlap
of
us
potentially
two
summer
ranges
right.
If.
B
Yeah,
so
that
that
just
gets
kind
of
hairy
and
gets
it
out
of
the
like
either
it
should
be
based
on
the
engine's
npm
value,
or
it
should
be
based
on
a
config
value
and
not
inferring
a
config
value
based
on
engines
npm,
it's
my
my
take
but
yeah.
If
we
just
add
a
package,
lock
version
field,
lock
file
version
fields,
it
would
be
pretty
straightforward
to
do.
C
C
B
It's
it
seems
that
way,
but
here's
the
here's
the
rub
of
it.
It's
not
like,
like
the
engines.npm
field,
is
december
range,
and
so
then,
what
we're?
What
you're
suggesting
is
we
have
a
config
value
whose
default
is
based
on
whether
that
semver
range
intersects
with
anything
less
than
seven,
which
is
just
more
complicated
than
I
prefer
config
defaults
to
be.
D
B
B
Well,
there's
a
reason
for
the
preference
which
is
having
having
complicated
config
defaults
is
almost
always
a
pain
like
yes,
npm
doesn't
for
a
lot
of
things
and
it's
kind
of
a
problem
that
we
infer
so
many
things.
B
It
opens
the
door
for
a
lot
of
very
difficult
to
reason
about
code,
which
we
then
have
to
maintain,
and
just
just
having
it
be.
B
You
know,
based
on
an
explicit
config
with
a
hard-coded
default.
Is
super
super
simple.
You
know
it
just
means
that
there's
only
one
thing,
we
need
to
look
at
to
know
what
it
should
be
doing.
C
B
C
Free
install
that's
if
there's
an
existing,
lock
file
that
specifies
version
three.
I
get
that
I'm
saying:
there's
no
lock
file.
My
npm
rc
has
lock
file
version
three
in
it
and
then
I
type
npm
install
what
version
will
it
create
the
lock
file
in
in
npm,
six
versus
seven,
I'm
assuming
one
and
three
that's
correct.
Six
will
always
create
a
version
one
lock
file,
because
it's
the
only
thing
it
knows
how
to
do
right.
C
E
Yeah
cars
see
your
hands
up,
go
I
just
wanna
talk
to
the
inference.
One
of
the
hard
one
lessons
of
npm
is
guessing
user
intent
is
always
wrong.
E
There
needs
to
be
a
compelling
reason
versus
oh.
Why
not
it's
not!
Why
not
it's
compelling!
This
is
why
we
should
absolutely
guess
the
user
intent
here,
because
historically,
it
has
always
been
a
nightmare
because
there's
the
user
base
is
so
big
and
the
intent
never
covers
everything.
E
C
Well,
yeah,
and
so
I
hear
that
that
argument,
I'm
more
saying
that
if
someone
has
put
engines
npm
and
specified
a
level,
an
npm,
seven
high
enough
that
this
feature
is
supported
like
I
agree
that
it's
not
harmful
to
create
a
lock
file
version.
Two,
and
so
that's
a
reason.
Why
like?
Why
not
to
infer
it,
but
it
seems
like
it
matches
their
intents
to
create
a
lock
file
version
three,
since
they
already
want
to
force
compatibility
with
those
and
that
npm
range.
B
Right
so
I
I
think,
just
to
add
a
little
bit
of
color
to
what
car
is
saying
like
I
agree.
It
has
always
been
a
nightmare.
There
are
a
handful
of
cases
where
I
think
the
nightmare
was
worth
it.
I
think
inferring
inferring
color
and
not
showing
color
by
default,
if
you're
on
a
non-tty
output,
probably
a
good
thing,
a
lot
of
unix
tools
do
that
it's
also
a
huge
pain
that
has
been
a
real
hassle
to
deal
with
in
a
lot
of
situations.
B
So
you
know
it's
it's
it's
a
higher
cost
than
it
looks
like
I.
I
agree
with
you.
If
you
said
npm,
your
engines.npm
is
like
seven
or
greater.
That's
fine!
Yes,
like
that
is
a
statement
of
intent
that
you
know
you're
not
going
to
be
using
a
version
of
npm,
that's
lower
than
seven.
However,
that
doesn't
stop
somebody
from
installing
your
project
with
npm
six
and
if
we
then
installed
something
different
than
what
the
lock
file
is,
we're
now
violating
a
contract.
So.
C
C
B
Yeah
I
mean
that's,
that's
maybe
something
that
we
should
get
that
we
should
do.
We
don't
do
that
in
npm,
seven
either
you
can,
you
can
put
engines.npm
equals
99999
in
your
package.json
and
still
install
the
project
but
yeah.
I
I
think
just
if
we,
if
we
don't
have,
if
we
don't
have
basically
like
a
profound
reason
to
infer
something
like
you
know,
it
will
be
a
security
problem
or
you
know
it's
it's
just
it's.
B
What
every
other
unix
tool
does,
so
it's
very
unexpected
for
it
not
to
infer
in
this
particular
case
like
we
should
not
be
inferring
user
input.
If
we
use
our
intent,
if
we
can
get
away
with
that.
C
I
mean
yeah
as
a
general
policy
thing.
I
was
like
I
sort
of
agree
with
that
as
a
philosophy,
but
it's
more,
I
was
also
thinking
about
the
web's
form
ideology
of
priority
of
constituencies,
meaning
conflict
like
things
matter.
The
users
are
the
most
important
ones
and
like
spec
authors
are
the
least
important
and
implementers
are
somewhere
in
there
and
so
like
if
it's
valuable
to
users,
it
shouldn't
necessarily
matter
if
it's
complicated
for
npm
authors,
but
like
yeah,
I
mean
it's
like
a
different
argument
in
that
case,
but
yeah,
but
I.
B
I
think
there's
some
sense
in
that,
but
also
implementing
features
where
we're
inferring
user
intent-
and
this
is
this-
is
getting
somewhat
meta
like
this
is
bigger
than
just
what
kind
of
log
file
we
create,
but
implementing
features
where
we're
inferring
user
intent
opens
the
door
for
us
to
infer
that
intent
incorrectly,
which
does
actually
end
up
harming
users
like
this
is.
This
is
a
case
where
we
ought
to
be
looking
out
for
them
by
not
guessing
what
they
meant.
A
Okay,
so
just
to
circle
back:
what
are
the
actions
moving
forward?
Do
we
want
to
move
forward
with
introducing
a
package
lock
version
config.
B
A
Yeah,
okay,
let's
say
action
is:
I
have.
B
I
will
I'll
write
up
a
pointer
of
like
where
they
need
to
go
in
arborist
to
implement
this.
E
B
But
yeah,
if,
if
I
think
arborist
does
export
that
somewhere,
I'm
not
sure
but
at
the
very
least
yeah.
If,
if
if
it's
configurable,
then
we
just
need
to
say
like
there
are,
you
know
it
could
be
either
one
two
or
three:
we
just
need
to
find
the
config.
A
So
I
took
some
notes
there.
A
couple
actions
as
well
want
to
move
along
here,
and
I
see
jordan
would
love
to
get
to
some
terminology
on
workspaces.
I
know
we
can
circle
back
on
that.
There
was
an
item
that
I
removed
that
I
can
re-add
to
the
end
here.
So
hopefully,
if
we
get
some
time
so
yeah
moving
along
rfc
issue,
number
427,
npm
rs
rc
file
improvements-
this
is
by
evan
carroll,
who
I
don't
think
was
able
to
jump
on
today.
A
So
I
think
you
had
provided
some
feedback
here
isaac.
This
is
some
somewhat
related
to
luke's.
Next
then,
the
next
rfc.
B
B
B
We've
sort
of
talked
about
so
first
of
all,
our
config
layer
is,
is
a
little
bit
of
a
a
god-awful
mess.
I
think
is
the
technical
term
there's
there's
some
other
less
savory
technical
terms,
which
might
also
apply
to
it.
It's
the
kind
of
thing
that
evolves
organically
over
a
decade,
and
it
creates
a
lot
of
features
along
the
way.
So
we
need
to
make
some
big
breaking
changes
to
it.
B
While
we're
doing
that,
we
can
also,
I
mean
one
of
the
biggest
areas.
That
is
a
a
real
challenge
to
to
work
with,
and
just
very
confusing
is
the
way
that
we
kind
of
specify
certain
configs
per
registry,
and
we
also
allow
you
to
specify
a
registry
per
scope
and
it's
it's
done
in
a
a
way.
That's
both
too
flexible
and
too
limiting
at
the
same
time,
and
it
has
a
very
weird
syntax.
It's
just
it's
it's
a
little
bit
unfortunate.
B
So
if
we're
gonna
make
the
kind
of
change
that's
proposed
in
this
rrfc,
we're
gonna
have
to
also
make
some
very
significant
changes
to
the
way
that
we
handle
config
and
if
we're
gonna,
do
that.
Well,
hell.
Let's
go
all
the
way
and
really
do
that.
You
know:
let's
get
rid
of
save
dev,
save
optional,
save
peer,
let's
make
it
so
that
unknown
flags
will
actually
crash
or
invalid
values
will
actually
crash
instead
of
just
ignoring
them
and
using
the
defaults
and
honestly,
the
the
lowest.
B
Ini
is
weird:
git
uses
it
and
pm
uses
it
almost
no
other
dev
tool
out
there
today
uses
iron,
the
ioni
format,
but
it
can
do
everything
that
we're
talking
about
it
has
a
kind
of
nice
kind
of
nice
effect
that
everything
is
a
string
when
it's
parsed
out
of
I-
and
I,
which
makes
it
sort
of
very,
very
similar
to
the
values
that
we
get
out
of
the
cli
arguments
or
the
environment,
which
are
again
always
strings,
so
you
know
being
able
to
put
null
in
there
as
an
actual
null
value
is
not
that
much
of
a
value
because
we
have
to
handle
strings
no
matter
what
that
being
said
like
okay,
if
we
want
to
have
different
two
different
registries
for
a
given
scope.
B
Right
so
we
want
to
have
one
registry:
that's
used
for
publishing
a
scope
and
doing
any
rights
and
another
registry
that's
used
just
for
installing
from
that
scope.
That
seems
completely
reasonable
to
me.
Let's
fold,
that
into
our
bigger
config
plans
that
were
changed
that
we're
planning
like,
I
don't
think
it
needs
to
be,
I
think
doing
it
as
a
one-off
is
going
to
be
just
as
much
a
breaking
change
and
we
should
try
to
get
more
value
out
of
that
breaking
change.
A
So
I
forget,
if
we
said
last
week,
because
I
think
this
was
on
the
docket
as
well,
whether
or
not
we
were
just
going
to
as
you're
saying,
like
pull
this
into
larger,
a
larger
rfcu
for
updating
our
config
strategy.
Like
do
what's
the
action
item
here
is
just
close
this
and
keep
a
reference
to
this
thread
or
like
until
we
open
another
rc.
We
keep
this
open.
B
Certainly,
we
should
keep
it
on
the
agenda
or
sorry
take
off
the
agenda
label.
We
should
not
keep
it
on
the
agenda.
A
Are
you,
okay,
with
taking
the
action
to
circle
back
with
some
commentary
from
this
discussion
and
then
potentially
closing
it
yeah
sure
or
leaving
or
potentially
leaving
it
open
and
and
then
just
we
can
close
it
once
we
open
up
an
rfc
for,
like
essentially
config.
B
Yep
I
added
a
new
label
config
and
put
it
on
it,
so
we
can
easily
find
anything
that
we
tag
between
now
and
then
that's
sort
of
config
related.
A
Okay
mood
on
then,
unless
other
folks
had
comments,
let's
see
hands
to
issue
number
423.
This
is
the
formatting
of
package.json
based
on
config
values.
This
was
written
by
luke
karis
from
our
team
luke.
Did
you
want
to
give
a
quick
synopsis
of
what
this
has
all
been.
F
Yeah,
this
is
to
enforce
consistent
writing
of
package
json
and
package
lock
files
from
a
set
of
new
config
values,
so
the
config
values
do
any.
Do
you
know
indentation
and
align
also
sorting,
keys
placement
of
top
level
keys,
sorting
of
child
keys
and
things
like
that,
and
it
adds
a
new
top
level
command.
That
would
you
know
that's
responsible
for
formatting
those
manually
and
then
also
would
write
these
based
on
the
config
values.
F
If
you
ran
things
that
are
already
running
the
package,
json
like
install
or
init,
and
then
there's
what
else,
there's
kind
of
some
complexity
in
how
we
make
this
not
a
breaking
change.
So
currently
I
was
thinking
that
would
use
the
config
values
if
they
exist.
F
Would
use
editor
config
or
if
they
don't
exist,
it
would
use
whatever
is
in
package.
Json
then
fall
back
to
editor
config
and
then
fall
back
to
some
new
default
values,
which
are
what
they
are
currently
two
spaces
for
tabs
and
a
new
line
for
end
of
line.
B
A
Yeah,
so
that's
I
think,
that's
what's
being
introduced.
Yeah
go
ahead.
C
Yeah,
so
this
is
relevant
to
the
like,
immediately
proceeding
discussion
about
inference.
Obviously,
when
the
explicit
things
are
present
like
we're
good
right,
everything's
fine,
but
I
think
that
the
the
very
compelling
reason
here
is
that
a
lot
of
projects
do
specify
an
editor
config,
the
like,
especially
if
you're
using
tabs,
because
without
an
editor
config
git
will
display
your
tabs
on
the
web
as
eight
spaces.
But
if
you
have
an
editor,
config
github
will
respect
it
and
display
the
tabs
as
the
appropriate
non-obscene
long
spaces
or
indentation
levels.
C
So
it's
very
common,
especially
with
people
who
have
tabs
and
yeah.
So
I
think,
reading
from
that
is
the
appropriate
thing
and
exactly
as
garza
said,
editor
config
is
very
explicit
as
far
as
reading
from
current
package
json,
that's
what
it
already
does.
So
that's
not
new
inference.
That's
the
existing
one
it's,
but
I
think
that
it
makes
sense
to
prioritize
the
existing
format
over
editor
config,
because,
if
both
are
present,
the
users-
probably
very
intentionally
kept
them
different
like
both
are
present
and
differ.
C
Rather
the
users
probably
intentionally
kept
them
different.
So
I
really
like
the
sort
of
four
options
here
presented,
which
is
npn
config
rules
all
and
then
absent
that
look
at
package
json
and
maybe
there's
only
three.
I
don't
have
in
front
of
me
and
then
absent
like
if
there's
not
already
a
package.json
file,
look
at
editor
config
and
if
none
of
the
yeah,
the
fourth
one
is.
If
none
of
those
are
present,
you
just
use
the
current
defaults
that
that
seems
great
to
me.
B
Well,
I
was,
I
was
actually
suggesting
something
slightly
different,
which
is
when
we
are
when
we
run
npm,
install
and
we're
editing
package
json
as
a
result
right
if
the
current
file
b
and
also
same
goes
for
a
log
file.
If
the
current
file
being
edited
has
already
exists,
then
use
what's
already
in
it,
regardless
of
what
the
config
says
or
the
editor
can
fix
it,
like.
B
Don't
even
look
for
those
values,
if
we're
creating
it
from
scratch,
whether
that's
for
output,
dash,
json
or
npm
init,
or
you
know,
an
install
where
there
was
no
lock
file.
That
kind
of
thing
then
use
the
config
value,
and
if
the
config
value
is
not
set,
then
look
in
edit
or
config,
and
if
that's
not,
there
then
use
the
default.
So
essentially,
editor.editor
config
is
in
the
project
is
like
a
config
value,
a
config
file.
Just
for
this
one
value
that
sort
of
simplified
thing.
B
I
don't
think
that
we
should
format
packagelock.json
the
same
as
package.json
or
use
package.json
as
a
source
of
those
values,
because
then
we
do
get
into
kind
of
inferring
what
the
user
meant.
You
know
if
they
want
it
to
be
different,
they
could
set
it
different.
C
Well,
okay,
so
the
first
half
of
what
you
said,
you
were
saying
that
you
think
that
the
existing
format
should
should
win.
Is
that
right.
B
C
B
C
Already
actually
yeah,
that's
true.
This
is
what
it
used
to
do
before
it
respected
tabs
and
the
existing
stuff.
It
always
rewrote
the
entire
file
right
and
it
like
sorted
the
dependencies.
I
don't
know
if
it
still
does
that
or
not
so
like
npm
has
never
been
very
careful
about
avoiding
git
churn
on
npm
install
foo
like
diff
churn.
But
that's
that's
interesting
because
my
primary
use
case
is:
I
have
nothing
validating
the
current
indentation
of
my
package.
Jsons.
I
have
hundreds
of
projects.
C
I
probably
have
a
few
that
have
mixed
tabs
and
spaces
just
because
I
don't
have
I
have
them.
I
don't
have
them
set
to
display
in
my
editor
as
like
symbols,
so
like
what
I
would
want
is
to
be
able
to
set
in
my
user
level
in
pmrc
my
preferred
indentations
and
then
the
next
time,
I'm
interacting
with
that
project.
I
absolutely
would
want
to
see
that
larger
diff
and
if
I
saw
it,
what
I
would
do
is
I
would
reset
back
to
before
I
ran
my
command.
C
I
would
run
npm
package
format
or
whatever
the
equivalent
was,
or
I
just
typed
npm
install.
I
would
commit
that
and
then
I
would
rerun
npm
install
foo
and
like
see
the
small
diff
I
wanted
so
like.
I
actually
have
the
use
case
that
that
I
want
it
in
to
implicitly
and
greedily
reformat
to
sort
of
correct
what
is
likely
to
be
a
bunch
of
sloppiness
since
it
was
never
enforced
before.
B
The
the
good
news
is,
you
think
that
we
respect
tabs
and
spaces
and
package
json,
but
actually
npm
still
just
reads
the
file
parses.
It
makes
a
bunch
of
changes
to
the
data
object
and
then
re-encodes
it
and
writes
it
back.
The
the
difference
is
now
when
we
first
read
the
file,
we
just
look
at
what's
the
first
line
ending
and
what's
the
first
indentation
and
sure
so,
we're
always
making
it
consistent
like
self-consistent,
which,
as
of
yet
nobody's
complained
about
nobody,
is
like
prefers
mixed
tabs
and
spaces
or
anything
like
that.
B
A
C
C
Yeah,
I
don't
care
exactly
like
how
it's
reached
or
spelled
right,
but
like
just
some
invocation
that
that
forcibly
reformats
my
package.json,
but
personally
I
would
also
want
the
lock
file.
I
want
them
to
always
match
if
package.json
is
tabs,
I
want
lock
quality
tabs
and
same
with
spaces,
but
but
like
having
the
supposed
command
is
nice
having
config,
for
it
is
sort
of
necessary.
Otherwise
I
have
to
go
in
and
like
guess,
the
heuristic
and
edit
the
file
and
then
run
the
format
command
which
that
sucks.
C
So,
but
I
guess
the
I
appreciate
that
what
npm
is
already
doing
is
cleaning
up
the
inconsistency
but
like
I
would
still
want
yeah.
I
still
would
want
the
the
explicit
config
to
overwrite
inferring.
What's
already
there,
I
mean
maybe
not
on
the
explicit
format
command,
but
on
the
like
other
places,
where
package.json
is
in
fact
reformatted.
That's
where
I
would
want
the
config
settings
to
always
win
right.
You
want
them
to
be
respected.
A
Oh
guys,
just
taking
notes
card
did
you
have
a.
E
B
B
C
E
E
Add
you
know
a
library
and
use
it
for
a
new
feature.
My
settings
are
going
to
obliterate
his
package.json.
So
if
you
don't
want
to
have
global
settings
affecting
project
level,
then
you
should
find
the
project
level
config
right.
But
that
means
that
puts
the
onus
on
on
all
developers
to
lock
everything
down
in
the
project
level.
That's
onerous.
G
I
also
think
that,
if
you're,
if
you're,
setting
that
at
a
global
level
like
you're
making
the
choice
that
I,
if
I
go
and
clone
this
repo,
I'm
gonna
have
to
figure
that,
like
I'm
gonna,
have
to
address
that.
I
think
that,
like
by
off
going
to
that
state
of
opting
into
that
you're
also
taking
on
the
onus
of
I'm
gonna,
have
to.
B
B
C
C
Yet
perfect,
because
then
I
can
just
stick
that
in
ci
for
all
my
packages
and
then
at
least
I'll
be
reminded
to
manually
run
the
format
command
instead
of
you
know,
instead
of
trying
to
rely
on
it
happening
every
time
I
touch
a
repo.
H
Okay,
awesome,
yeah,
and
just
just
to
enable
more
workflows,
we
should
probably
have
a
dry
run,
like
format
that
actually
outputs
the
file
to
standard
out
as
well.
C
Well
and
real,
quick
for
for
dry
run,
I'm
not
sure
if
that's
actually,
what
I
want
because
dry
run
is
usually
like,
do
the
same
stuff,
but
don't
actually
destruct
do
anything
destructive
so
like
if
npm
package
format
would
succeed,
I
would
expect
dry
run
of
it
to
succeed
and
exit
zero.
This
is
a
like
check
like
this
is
basically
like
error.
If
you
were
gonna,
do
something
destructive
pass
if
you
weren't
gonna,
but
don't
do
the
destructive
thing
either
way,
so
it's
like
dry
run,
plus
change
the
exit
code.
C
Yeah
and
the
the
git
status
stuff
that
isaac
just
posted
in
chat,
that
is
the
hack
everyone
has
to
do
now,
and
that
really
sucks,
because
it's
relatively
trivial
for
the
first
command
to
exit,
non-zero
and
then
like,
because
eventually
you
have
to
put
a
cleanup
somewhere
in
there
and
it's
a
big
pain
in
the
butt
to
figure
out
a
way
to
do
that.
That's
actually
robust
and
it
won't
and
will
happen
even
when
the
commands
fail.
So
I
think
an
explicit
validate
thing
is
is
great,
but
npm
package
validate.
C
Would
I
expect
to
validate
many
more
things
besides,
just
the
indentation
format
like.
I
would
expect
that
to
validate
the
schema
and
that's
a
big,
a
much
broader
discussion.
B
C
Yeah,
I
mean
eslint:
does
this
sort
of
by
default,
but
anyone
who's
using
pretty
or
by
themselves,
has
had
to
deal
with
this
problem
many
times.
And
similarly
I
have
tools
that
auto-generate,
like
tables
of
contents
or
lists
of
things
in
documentation,
like
perhaps
npm's
auto-generated,
documentation,
sections,
and
you
have
to
manually
jump
through
a
bunch
of
hoops
to
make
sure
that
people
have
remembered
to
run
those
commands.
A
So
just
capture
action
items
and
I'm
putting
a
line
on
luke
here
to
hopefully
update
this
or
conceptualize.
These
two
added
features
flags.
I
think
it
there
is
value
in
the
dry
run
and
the
validate
potentially
as
flags
to
format.
So
if
we
can
potentially
just
even
scaffold
that
or
add
to
the
conversation
back,
luke
that'd
be
great
this
feedback
and
then
it
sounds
like
there
isn't
an
appetite
to
like
turn
this
into
rfc.
We
should
probably
just
go
ahead
and
and
backlog
work,
work
item
to
actually
like
do
the
work
here.
A
So
if
we
can,
let's
turn
this
into
actually
like
a
ticket
turn
this
into
a
backlog.
C
You
asked
about:
maybe
it
could
output
to
a
file
as
well
or
to
stand
it
out.
It
seems
really
nice
if
it
can,
if
this
command,
if
npm
package
format
could
detect
that
it's
in
a
pipe
and
when
it's
in
a
pipe
spew
the
output
to
standard
out
and
when
it's
not
it
writes
it
so
it
exists
because
then
it
sort
of
automatically
matches
the
user's
intent,
because
otherwise,
why
would
you
pipe
it
just
a
thought.
A
B
More
broadly
speaking,
you
mentioned,
like
dry
runners,
do
the
same
thing
and
output
the
same
output,
but
just
don't
make
the
destructive
changes.
We
actually
should
be
outputting
a
little
bit
more
useful
stuff
in
a
bunch
of
dry
run.
Cases
like
if
you
do
npm
install
dry
run
and
we
say
10
packages
were
installed.
It's
like
okay,
well,
thanks
a
lot,
but
that
it
sure
did
help
me
it'd
be
a
lot
nicer.
A
So
I
added
those
two
notes
anything
else
on
this,
or
can
we
move
forward.
A
I
think
we
can
leave
the
roc
open
for
now
and
then
luke
if
you're,
okay
with
it
essentially
turning
this
into
a
ticket
in
our
team's
backlog,
yep.
That
sounds
great
cool
thanks,
and
I
know
you're
excited
about
this,
because
you've
been
using
tooling
ecosystem
doing
tooling
for
this
for
a
while,
so
cool
moving
on
to
issue
number
371.
A
This
is
a
feature
essentially
that's
queued
up
in
our
backlog
that
was
spun
out
of
a
rfc
by
roy
aderno.
We
essentially
backlogged
the
work
for
creating
a
new
mechanism
for
either,
including
or
excluding
the
root
of
your
project
for
essentially
with
when
you're
using
workspaces
garad.
I
think
you've
been
working
on
this.
I'm
not
sure
if
there's
an
update
here
that
you
want
to
share
well.
E
But
I
I
can
describe
the
problem
space
here
as
we
developed
this.
We
realized
there
was
kind
of
them,
a
quirk
with
how
we
implemented
workspaces
and
that
is
by
default.
Workspaces
are
enabled
in
that
arborist
will
use
them
like.
If
you
install
package
a
and
have
a
workspace
package
name,
a
arbors
is
going
to
use
that
right.
So
in
that
sense,
workspaces
are
enabled,
but
when
we
went
to
implement
workspaces
as
a
flag,
enabling
workspaces
then
came
to
mean,
do
this
thing
in
all
my
workspaces.
E
That's
half
of
this,
the
other
half.
Is
we
also
now
that
we've
got
this
way
to
say,
hey
go!
E
Do
this
in
all
my
workspaces,
we
want
to
always
say
also
do
it
in
my
root,
so
that,
if
you
know
the
example
is
like
npm
repo
dash
dash
workspaces
dash
dash
include
root,
I
would
get
the
repo
of
my
route
and
all
my
workspaces,
so
that
kind
of
completes
the
loop
and
covers
the
gap
on
the
on
the
kind
of
holes
in
the
mental
model
of
what
it
means
to
enable
workspaces
totally
disable
them.
And
how
do
I
include
my
root
project
in
the
base
command?
A
Any
feedback,
or
essentially
you're,
doing
the
work
to
enable
this
you've
outlined
the
the
flags
which
should
be
net
new
to
folks,
since
we
kind
of
discussed
those
internally.
What
might
be
interesting
is
is
no
workspaces
are
essentially
the
trinary
of
that
concept
where
by
default,
workspaces
is
null,
I
think,
is
accurate.
Is
that
accurate?
The
config
workspace
is
null
there's
now.
E
That's
that's
how
we
functionally
solved
that
problem
of
by
default
workspaces
are
disabled
in
that
you're
not
going
to
run
the
command
in
all
the
workspaces,
but
there
was
no
way
to
also
explicitly
tell
arborists.
Don't
look
in
the
workspaces
when
you
reify
and
that's
what
explicitly
setting
workspace's
default
covers
that
last
gap
leaving
it
the
default
will
do
what
it
does
now,
which
is,
if
I
do
npm
install
arborist,
will
look
in
workspaces
for
reification.
E
Yeah
just
to
let
you
know,
this
is
where
we
landed,
and
this
is
unless
someone
sees
a
problem
with
this
there's
already
a
pr
and
the
cli
for
it.
But
I
have
to
go
land
at
an
arborist
before
that
see
how
I
can
land,
because
it
needs
to
be
able
to
pay
attention
to
these
flags
appropriately.
A
Your
silence
is
golden,
I
apologize,
I'm
just
taking
notes.
Do
you
know
the
pr,
or
can
you
reference
the
pr,
so
I
can
add
it
to
our
notes
as
well.
I'll
find
it.
E
In
jordan,
this
is
the
one
that
used
to
be
the
other
flag,
and
then
we
talked
through
it,
and
once
we
realized
that
the
root
problem
was
this
trinary.
This
is
where
we
landed
on.
So
thanks
for
helping
think
through
that.
B
Okay
and
the
interest
of
completeness
here,
we,
we
did
also
explore
this
like
in
this
kind
of
cute
way
of
saying.
Well
what
if
you
could
do
like
dash
dash
workspace
equals
dot
which
seemed
like
it
would
be
nicer
because
we're
like.
Oh
then
we
don't
need
the
trinary,
which
is
always
a
pain,
and
you
know
kind
of
hard
to
reason
about
and
and
then
it's
like.
Oh
the
root
is
just
like
it's
just
another
workspace,
so
it's
like
the
same
kind
of
thing.
B
It
turns
out
it's
not
the
same
kind
of
thing,
so
yeah
that
was
incredibly
hard
to
get
working
properly
and
super
complicated
to
the
point
where,
like
actually
now
just
there
needs
to
be
an
explicit
thing
that
says,
include
workspace,
roots,
verbose
and
gnarly,
but
it's
also
really
straightforward
and
hard
to
mess
up.
C
To
be
clear,
I
think
this
is
because
of
the
architectural
changes
npm
has
made
by
hoisting
everything
to
the
top
lerna
uses
dot.
It
works
perfectly
fine
in
my
experience
anyway,
but
every
time
I
said
something
works,
fine
and
learn
and
learn
as
maintainer
tells
me
it's
terrible
so
like,
but
but
at
least
in
my
experience
the
dot
has
worked.
Fine,
but
that's.
C
Fine,
but
like
each
each
sub
project
in
a
learner
model,
repo
has
its
own
node
modules
and
things
are
put
in
it
and
not
always
wasted
at
the
top.
So
I
think
that
that
those
those
architecture
changes,
sort
of
constrain
and
determine
a
lot
of
this
stuff.
So
it's
fine.
If
that's
not
what
this
flavor
of
workspaces
can
do,
I
think
it
would.
The
dot
would
work
just
fine
in
the
alternative,
perhaps
superior
form
of
workspaces.
We've
discussed
a
bunch
of
times
in
this
call
but
yeah.
B
It's
not
so
much
about
hoisting,
it's
about
not
having
very
well
or
any
defined
semantics
for
nested
workspaces.
So
a
thing
a
workspace
may
not
contain
other
workspaces,
but
if
dot
is
a
workspace
now
now
we
have
a
workspace
that
we're
sort
of
treating
semantically
can.
B
B
C
C
C
Like
well
real,
quick,
the
the
specific
thing
I
find
valuable
in
the
dot,
though,
is
the
ability
to
put
it
in
config,
meaning
I
can
actually
say
like
in
my
learn.
I
config
in
my
in
my
only
learn
a
mono
repo.
I
say
like
when
I'm
running
this
specific
learning
command
run
it
on
dot
also
so
that
I
could
say,
learn
a
build
and
it
runs
the
build
script
in
the
child
projects
and
also
in
the
root
project,
and
that
is
precisely
what
I
want
with
a
command
line
invocation.
B
Yeah
the
same
same
thing,
because-
and
in
fact
it's
even
more
explicit
because
you
don't
have
to
know
that
dot
is
like
the
pseudo
workspace,
that's
also
the
root,
and
it
has
mostly
the
same
semantics.
It's
just
a
boolean.
It's
like
do
you
want
to
do
it
in
the
root
or
not
the.
If
we
did
if
we
did
eventually
want
to
say
that
we
support
nested
workspaces,
so
you
can
have
a
workspace
which
has
child
workspaces
underneath
it
then
we'd
be
crossing
that
bridge
from
you
know.
B
The
zero
one
infinity
bridge
would
be
going
that
third
step
and
at
that
point
saying
dot,
is
a
workspace,
wouldn't
be
that
big,
a
bullet
to
buy
because
it
would
be
well
work.
Spaces
can
contain
workspaces,
that's
normal
right,
but
that's
just
that's
not
the
world.
We're
in
you
get
one
level
of
workspaces.
That's
it
not
infinity.
A
Okay,
I
know
that
we
had
an
action
item
that
we
should
probably
review
the
last
few
meetings.
Specifically,
I
remember
there
was
action
on
to
to
update
the
terminology
and
definitions
and
I
potentially
had
like
a
glossary
for
the
rfc,
the
workspaces
rfc,
the
original
one,
and
I
continued
to
reference
this
one
image
that
I
threw
together
to
try
to
help
ensure
that
we're
all
on
the
same
page
when
we're
talking
about
this
terminology.
A
But
I
want
to
get
to
the
last
item
here
before
I'm
going
to
ask
for
some
maybe
updates
around
the
audit.
Improvements
are
the
three
rfcs
that
we
have
open
around
that
space
alster.
This
is
your
pr
for
pure
dependencies
should
be
able
to
match
the
full
range
of
pre-release
versions.
I
remember
that
we
left
this
open
for
an
extra
week,
or
so
I'm
just
wanted
to
know
if
there
was
any
updates
or
that
you
want
to
share
around
this.
D
D
So
I
left
some
comments
on
the
rfc
for
that,
as
well
as
some
suggestions
based
on
the
previous
meeting
we
discussed
today,
one
of
them
was
one
of
them
happened
to
be
the
the
idea
that
if
a
user
provided
a
pre-release
version
as
a
peer
dependency-
and
they
also
had
a
oh
sorry-
they
provided
a
pre-release
version.
D
Well,
let
me
get
this
right.
They
provided
a
pre-release
version
of
a
pair
dependency
and
they
also
had
that
pre-release
version
in
the
tree.
Then
it
would
automatically
resolve,
but
it
comes
up.
You
know
I
couldn't.
I
couldn't
see
a
problem
with
with
that
necessarily
otherwise
it
you
know
it
would
fail
today
or
install
the
wrong
version
so,
but
it
comes
down
to
the
what
we
discussed
earlier
on
in
the
meeting
around
user
intent.
So
it's
like
okay.
We
can
automatically
assume
that
this
is.
D
This
is
a
good
thing,
but
we
we
never
know
if
it
is
or
not,
but
it
seems
like
it
would
be
preferable
for
you
know
if
you
have
a
a
400-0
in
your
pre-releases,
so
you've
got
any
a
plugin
and
it
depends
on
a
library
for
pre-release,
and
then
you
have
that
library
installed
at
400-0,
then
it
would
be
like
okay,
I
got
that
pair
dependency
and
I
don't
try
and
install
a
different
one
as
a
peer.
You
know
or
fail.
D
It's
like
okay,
you've
got
that
you've
got
that
dependency,
install
it's
a
different
version.
I
won't
install
it.
That's
the
current
behavior.
I
think
the
alternative
is
for
that
package
and
I
I'm
specifically
saying
the
plugin
here
so
the
the
thing
that
the
thing
that
has
the
peer
dependency
that
would
define
some
sort
of
peer
dependency.
Better.
That
says,
I
match
these.
D
You
know
when
you
install
me,
allow
the
peer
dependency
to
resolve
pre-releases
if
you've
installed
a
pre-release
version
of
that
dependency
and
yeah
the
reason
for
those
specific
suggestions.
So
so,
in
the
previous
discussion,
it
came
up
that
maybe
the
the
plug-in
developers
I'll
be
it
should
be
foster
publisher
version,
which
has
that
pre-release
as
a
peer
dependency,
but
if
you've
got
an
ecosystem
where
you've
got
hundreds
of
dependencies,
it's
not
really
like
something
you'd
really
want.
D
Like
you
know,
if
you
refer
to
my
personas
in
the
ticket
you're
a
developer
of
the
the
main
library
that
has
these
plugins,
you
want
to
test
a
prerelease
version
using
an
existing
set
of
plugins
and
suddenly
you've
got
to
publish
every
single
version,
you're
testing
with-
and
let's
say
that,
a
user
of
the
library
they
want
to
test
that
you
know,
there's
a
new
change
and
it
would
work
before
absorbing
that
version.
D
Finally,
all
the
versions
that
they're
all
the
plugins
that
they're
using
whether
it's
a
version
from
the
library
maintainer
their
own
plugin
or
someone
else's
plugin
they
can.
They
can't
test
that
pre-release
version
of
the
main
library
without
somehow
hacking
together.
Those
plugins.
A
It
sounds
like
in
that
specific
use
case
it
potentially
overrides
would
allow
for
this
that
use
case
or
no.
B
Another
yeah
overrides
would,
but
if
overrides
is
such
a
powerful
tool
that
it
will
probably
satisfy
an
awful
lot
of
use
cases
that
we
maybe
just
don't
want
to
pin
on
overrides
as
the
solution
for
it
would
be
handy
to
have
an
include
pre-releases
flag
that
you
could
pass
to
npm
and
then
every
semver.satisfies
invocation
would
just
throw
that
onto
it.
So
you
could
install
your.
B
You
know,
install
your
zero
version
of
the
of
the
library
with
that
flag
set
and
while
building
the
tree
in
that
particular
case
in
that
particular
instance
of
npm,
while
building
that
tree,
it
would
be
allowing
pre-releases
so
treating
pre-releases
is
just
a
you
know.
Nothing
special
in
december
satisfies
call.
D
No
so
yeah,
that's
in
the
main
problem
there:
okay,
maybe
on
the
maybe
when
you're,
installing,
like
foo,
for
example,
here
like
it,
I
think
the
problem
there
is
is
a
little
bit
too
too
vague.
Maybe,
like
you,
don't
want
everything
to
just
suddenly
be
treated
as
a
preview
or
allow
pre-releases
when
installing
you'd
want
these
specific
dependencies
that
you've
got
in
your
tree.
That
you've
got
in
your
in
your
package.
Json
there
are
pre-releases
to
match.
If
there's
a,
if
there's
a
peer,
which
also.
B
D
B
E
E
D
D
Version
of
appearance
yeah
I
want
to.
I
want
to
define
something
in
my
package.json,
which
will
be,
I
say,
reproducible
and
it's
not
reproducible,
because
the
package
locks
there.
But
I
think
you
get
the
idea
something
I
can
define
and
install
and
get
what
I
want,
rather
than
something
that
only
lasts
intermittently
via
a
single
command
like
I
want
to
create
a
an
app.
D
And
similarly,
if
I
want
multiple
dependencies
which
have
this
this
issue-
and
you
know
but
happen
to
have
two
dependencies
which
pre-release,
then
it
becomes
impossible
to
to
build
that
tree
correctly,
because
you've
either
got
one
or
the
other
fail
on
one.
B
So
I
just
checked-
and
I
I
realized
that
I
misspoke
whatever's
in
packagelock.json,
if
you
do
npm
install
with
no
arguments
whatever's
in
the
package.json
will
be
the
the
the
ideal
tree
unless
the
root
project
has
a
or
one
of
your
workspaces
has
an
invalid
dependency.
B
So
if
you
do
npm
install
foo
at
you
know,
one
two
three
dash
four
dash
dash
include
pre-releases.
Anything
that
peer
depends
on
it
will
be
treated
as
just
fine
anything
that
depends
on
you
know
who
one.x
will
be
just
fine,
then
it
will
be
in
the
lock
file.
It'll
also
be
saved
with
the
version
range
in
your
package.json.
B
If
later
you
just
do
npm
install
with
no
arguments,
you'll
get
what's
in
the
log
file,
you'll
get
the
dashboard
version
and
it
will
be
fine.
If
you
ran
npm
ls-a,
it
would
report
some
problems,
but
like
okay,
that's
fine!
You
just
you
got
an
ls
with
include
pre-releases
also,
but
I
think
this
might
actually
be
the
solution
and
that
a
solution
to
this
use
case
that
sidesteps
the
sidesteps.
The
the
sort
of
a
very
surprising
hazard
of
like
sembers
are
treated
differently
depending
on
the
kind
of
dependency
that
it
is.
A
So
we
have
to
wrap,
unfortunately,
we're
a
couple
minutes
over
already.
I
want
to
keep
this
open
for
now
and
allow
folks
to
give
some
feedback
just
based
on
the
fact
that
I
feel
like
we're
going
back
and
forth
here
and
I
apologize
there
wasn't
a
lot
of
time
at
the
end
alistair
in
terms
of
the
audit
improvements
if
we
can
get
just
async
updates
added
in
those
threads
themselves.
A
For
for
folks,
I
know,
zb
had
been
adding
some
prs
to
arborists
then
to
the
client
itself
for
some
action
items
that
he
needed
for
the
npm
audit
resolver
package.
Unfortunately
he's
not
in
this
call
today
and
tierney.
If
you
can
provide
some
some
updates,
maybe
async.
I
know
you're
keeping
up
to
date
with
those
two
rfcs
so
and
I've
also
taken
an
action
item
here
to
circle.
A
Back
on
on
the
previous
discussions,
I
know
we
had
items
associated
with
further,
defining
and
and
declaring
essentially
our
definitions,
our
npm's
definitions,
our
workspace
terminology,
so
we've
taken
that
away.
I
appreciate
everybody
jumping
on
today.
I
apologize.
We
didn't
have
more
time,
and
hopefully
we'll
see
you
next
week-
it'll
be
at
the
same
time
same
place
and
yeah.
Thank
you.
Cheers.