►
From YouTube: Open RFC Meeting - Wednesday, August 11th 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.
B
A
A
The
link
has
not
updated
for
some
reason:
there
we
go
there,
we
go
okay,
so
we
are
live.
Apologies
about
that!
Just
got
locked
out!
Welcome
everybody
to
another
npm,
open
rfc
call.
Today's
date
is
wednesday
august.
The
11th
2021.
A
we're
gonna,
be
following
along
in
the
agenda
that
was
posted
in
issue
number
just
open
this
up
issue
number
431
and
for
folks
that
joined
late
feel
free
to
add
yourselves
to
the
hack
md
meeting,
notes,
doc
that
I
just
shared
in
chat
and
just
a
quick
reminder.
These
calls
and
all
of
the
communications
on
the
npm
rc's
repo
covered
by
code
of
conduct.
A
We
just
asked
that
folks,
please
be
mindful
and
thoughtful
of
others
as
they're
speaking,
and
you
know
please
review
that
if
you
have
any
other
questions,
feel
free
to
reach
out
to
myself
as
folks
are
talking,
please
raise
your
hand
and
I'll
call
on
you
to
participate,
and
just
just
try
to
be
nice
and
civil
on
these
calls
as
well.
I
just
want
to
provide
some
space
and
time
for
folks
if
anybody
had
any
announcements
that
they
wanted
to
share,
feel
free
to
speak
up
now.
A
If
not,
then
we
can
dive
into
the
agenda.
As
noted,
we've
moved
around
the
order.
A
bit
wanted
to
pull
up
essentially
items
from
last
week.
We
did
a
deep
dive
on
essentially
npm
audit
improvements.
This
was
spun
out
of
toony's
rfc
for
essentially
npm
audit
assertions,
I'm
not
sure
tuna.
If
you
wanted
to
give
a
quick
update
there
on
the
action
items
from
your
side
just
to
capture
again
what
you
were
referencing
before
the
call
went,
live.
C
Yeah,
I
I
have
pr
or
updated
the
pr
with
in
the
time
that
I
was
giving
my
thing
I
I
finished
what
I
was
saying.
I'd
also
add
I
I've
updated
the
pr
with
the
kind
of
additional
scoping
and
the
additional
kind
of
external
references
to
similar
or
related
prs
and
tools
and
standards
or
whatever,
but
whatever
the
correct
term
to
encompass
everything
is
so
that's
kind
of
in
there.
That
was
the
only
takeaway
that
I
had
from
it.
I
believe,
there's
mkm
team
takeaway
too.
A
Yeah,
so
I
can
give
an
update
there.
We
have
not
followed
up
from
last
week
on
any
investigation,
yet
I
will
will
provide
an
update
by
next
week,
essentially
we'll
we'll
queue
up
a
card
or
some
work
to
be
done
to
to
investigate
just
essentially
how
we
can
clean
up
the
existing
auditing
experience.
If,
if
at
all-
and
that
was
one
of
the
the
key
takes
aways-
is
what
what's
something
small-
that
we
can
do.
That's
actionable
that
can
also
help
in
this
space.
A
Is
there
something
we
can
do
to
the
existing
audit
experience
so
I'll
just
provide
that
we'll
provide.
A
Did
anybody
else
have
any
comments
they
want
to
share
about
or
any
updates.
Since
last
week's
deep
dive,
you
know
isaac,
you
were
unfortunately
not
able
to
join
yep.
D
A
I
imagine
that
won't
be
the
last
time
we're
gonna
talk
about
this
at
length,
so
I
think
there
will
be
opportunity
in
the
future
to
have
more
calls
with
with
folks
on
this.
A
Yeah
and
in
terms
of
the
open
prs
I
just
wanted
to
also
give
time
for
I'm
not
sure
if
tv's
on
call
it
doesn't
look
like
it,
so
I'm
just
gonna
essentially
say
not
available
to
provide
updates.
I
know
he
had
a
set
of
action
items
also.
A
He
was
providing
some
updates
to
arborist,
I
believe,
and
to
the
client
itself,
to
help
resolve
some
some
issues
and
to
pull
out
some
extra
metadata
that
was
lost
between
v6
v7.
To
fix
up.
I
think
npm
audit
resolver
his
tool,
I'm
not
sure,
isaac.
If
you
know
if
any
of
that
landed
or
if
he
actually.
B
Last
I
saw
there
was
some
some
changes
that
were
required
to
make
it
work
and
I'm
haven't
gone
back
and
reviewed
it
since
then,.
B
B
B
B
Now,
however,
what
that
means
is
when
we
save
the
hidden
lock
file
by
npm
7.
We
don't
have
that
license
metadata,
because
it's
not
included
in
the
manifest
that
we
use
to
build
the
tree,
so
we're
gonna
probably
have
to
address
that.
Otherwise,
that's
gonna
become
an
issue.
If
we
start
making
that
kind
of
load-bearing
for
feature
work.
A
Is
this
something
that
you're
going
to
be
able
to
work
with
the
registry
team
by
chance
isaac,
or
can
we
queue
this
up.
B
Yeah,
it's
a
it's,
a
small
change
to
get
it
into
those
corgi
docks,
but
it's
definitely
it
definitely
is
a
change.
It's
it's
not
zero
work.
It's
just
adding
one
one
field
to
that:
minify
package,
metadata
service
and
then
re-running
it
on
all
the
existing
packages
which
that.
E
E
B
A
Moving
on
then,
unless
folks
had
any
other
comments
from.
F
I'm
not
too
familiar
with
the
audit
licenses
of
what's
going
to
be
added,
but
it's
funny
in
my
company
we've
got
something
that
we've
rolled
ourselves
similar
for
auditing.
F
Would
this
result
in
being
able
to
generate
a
list
of
all
the
packages
and
licenses
and
fraud
is
like
an
output
from
the
audit,
because
this
is
used
to
send
make
available
to
customers
and
just
so
they
can
check
themselves
as
well,
although
they'd
be
able
to
obviously
run
this
themselves
as
well,
but
we
do
provide
a
file,
and
I
was
wondering
if
we
could
replace
our
own
tooling
with
this
entirely.
F
B
To
today
you
can
run
an
chem
ls
dash
dash
long
and
it
will
output
the
license
along
with
a
bunch
of
other
junk
about
each
package,
and
it's
not
too
terribly
hard
to,
or
it
wouldn't
be
too
terribly
hard
to.
You
know,
have
a
command
that
just
searches
for
licenses
or
does
other
things
with
them.
B
B
It
saves
that
that
tree
that
it
built
to
a
file
at
node
modules,
dot
packagelock.json,
which
is
the
same
essentially
the
same
format
as
a
lock
file,
just
in
a
different
place
in
order
to
kind
of
represent
and
doing
a
slightly
different
job,
because
it's
just
representing
what
is
there
on
disk.
B
If
that
file
is
there
and
it's
the
newest
thing
in
the
node
modules
folder,
we
use
that,
rather
than
actually
reading
the
folder,
the
hazard
is
on
a
fresh
install.
It
will
not
include
license
information
because
that's
not
in
the
minified
manifest,
so
there's
this
kind
of
chain
of
dominoes
that
leads
to
not
having
license
info
available.
If
you
just
delete
that
file,
you'll
it'll
have
to
read
the
node
modules,
folder
and
then
it'll
get
the
proper
license
metadata
yeah.
So
that's
just
a
thing.
B
A
Yeah,
I
think
toony
specifically,
you
might
also
be
able
to
like
top
up
there
in
terms
of
the
rfc
ethic,
explicitly
adding
license
auditing
yeah
like.
C
What
you
have
in
mind
yeah,
so
the
the
rfc
specifically
is
built
around
reporting
licenses
and
having
the
loud
list
in
a
block
list.
This
is
largely
built
on
top
of
prior
work
done
by
kyle
mitchell.
I
hope
I
got
his
name
right.
C
I'm
pretty
sure
I
did
yep
yeah
largely
built
on
top
of
a
prior
work
by
directly
consuming
a
module
called
licensee
and
basically
masking
that
as
an
npm
api,
and
it
allows
for
allowance
block
lists
a
bunch
of
nice
to
have
things
and
yeah
just
basically
kind
of
setting
up
license
tooling
in
npm
directly.
C
So
you
know
your
team
can
provide
an
allow
list
and
say
I
don't
do
or
more
useful
a
block
list
and
say,
like
don't,
allow
you
know
gpl
and
you
won't
get
gpl
modules
theoretically.
Well,
that
you
know
depends
on
exactly
how
what
the
implementation
is
like
you,
you
might
download
it
and
then
you
might
get
an
error
or
you
may.
We
might
not
download
it.
I
don't
know
yet,
but
yeah
does
that
make
sense?
Does
that
answer
your
question.
F
Yes,
there's
a
mixture
of
this
and
possibly
passing
the
the
you
know
the
log
file
if
it
contains
the
licenses
and
stuff
not
saying
well,
it's
good
to
know.
Thank
you.
A
Yeah
one
good
thing
to
note
here:
if
you're
interested
in
getting
involved,
there
is
a
work
in
progress,
a
drafted
pr
right
now
that
tierney
started
with
roy
aderno
from
our
team.
Who's
had
to
go
on
leave,
and
I
know
tierney
is
also
pretty
limited
in
time.
So,
if
you're
interested
in
getting
like
the
poc
or
the
initial
like
work
done,
alster
feel
free
to
jump
into
that
pr.
A
I
just
linked
number
three,
four
or
five,
two
and
yeah
feel
free
to
to
contribute,
or
even
potentially
sync
up
with
us
async
to
help
get
that
over
the
finish
line.
A
Yeah,
especially
if
you
already
have
written
tooling
in
the
space,
it's
you'll
obviously
have
a
leg
up
on
folks
that
are
coming
in
fresh.
So
any
other
questions
or
feedback
updates
say
regards
to.
I
guess
the
deep
dive
from
last
week.
A
Tierney,
I
I
moved
your
quick
note,
slash
update
into
underneath
the
item
for
the
actual
audit
assertions.
Rfc
we'll
keep
those
open.
All
of
those
rfcs,
I
think,
are
important
right
now,
since
there's
a
lot
of
folks
giving
feedback
in
them,
but
yeah.
I
want
to
move
on
to
a
number
of
net
new
issues
that
were
opened
in
the
last
week
or
so
in
fact,
that
we
were
able
to
get
to
them.
Last
week
the
issue
430
improving
workspace
terminology
by
jason
williams,.
A
Do
not
believe
other
than
jordan.
Who
is
not
here
right
now.
I
don't
know
if
many
folks
have
gotten
a
chance
to
look
at
this
yet,
but
this
essentially
was
stemming
from
a
discussion
that
was
made
in
our
feedback
forum.
I
think
isaac.
You
gave
some
feedback
yesterday,
I'm
not
sure
if
you
want
to.
B
Top
up
sure
I
I
mean
there's
a
there's
a
it
would
be
nice
to
sort
of
definitively
put
this
to
bed.
I
think
I
I
don't
know
if
that's
possible
or
not
just
given,
given
how
language
works,
but
essentially
there's
a
there's.
Some
ambiguity
in
the
javascript
community
about
whether
the
word
workspace
refers
to
the
project
that
defines
workspaces
in
its
package
json
or
the
sort
of
sub
projects
in
subfolders
that
are
referenced
by
that
workspaces
definition.
B
The
way
that
we
have
gone
in
npm
is
to
follow
yarn's
terminology,
which
differs
from
learners.
We're
not
a
hundred
percent
consistent.
I
don't
think
learner
or
yarn
are
either
again
like
language
is
hard
and
it's
just
easy
to
be
kind
of
sloppy
with
it,
but
the
what
I,
what
I
wrote
is
kind
of
my
understanding
of
how
we're
using
these
terms,
which
is
sort
of
project
or
project
root,
refers
to
the
place
where
you're
running
npm
commands,
which
has
a
package
json.
B
It
might
it's
typically
the
root
of
a
git
repository,
and
it
may
include
workspaces
definitions
and
then
a
workspace
is
the
thing
that
is
referenced
by
that
workspaces
definition.
So
packages
foo
is
a
workspace
within
the
project
that
you're
that's
your
current
working
directory
when
you're
running
npm
commands.
B
So
I
just
tried
to
like
write
up
a
quick
kind
of
rough
draft
of
a
glossary
of
some
of
these
things
and
again
like
with
the
acknowledgement
that,
like
yes
like
there's,
no,
in
my
opinion,
there's
no
like
objectively,
better
definition
of
anything
but
and
we
had
these
sort
of
two
to
choose
from
which
are
in
conflict
with
each
other
and
both
predate
us,
as
it
happens,
like
we've
kind
of
settled,
on
yarn's
definitions
rather
than
learners,
and
I
I
think
changing
it
is
probably
not
very
valuable.
A
I'm
just
trying
to
capture
a
few
notes
here,
so
I'd
like
to
a
few
references
for
folks
if
you're
trying
to
follow
along,
I
also
shared
essentially
an
image
of
a
visual
I
put
together
a
while
back
of
how
I
felt
like
we
were
defining
these
things.
A
I
know
there
was
a
to
do
to
actually,
I
think,
submit
that
into
and
amend,
essentially
our
original
rfc
for
workspaces.
A
With
that
visual,
I
can
take
that
as
as
an
action
I
am
on
my
plate
to
make
that
pr
happen,
and
then
we
can
dispute
whether
or
not
that
that's
the
the
actual
reality
of
or
picture
of
reality.
B
Well,
I
mean
I,
I
think,
also
it'd,
be
a
good
idea.
What's
got
me
thinking
this
morning
is
like
maybe
we
need
to
have
a
like
an
explicit
glossary
within
our
documentation
of
some
of
these,
some
of
the
terms
that
npm
uses
and
even
have
like
our
our
dock
building
scripts
automatically
link
any
word
that
it
finds
in
the
glossary
to
its
glossary
definition.
B
Just
so
that
if
somebody
is
reading
the
npm
docs
and
they
see
the
word
workspace,
they
can
like
link
to
it
and
see
what
actually
we
mean
by
that,
and
then
we
don't
have
to
keep
redefining
it
in
multiple
places
which
can
kind
of
go
out
of
sync
with
one
another
for
sure.
That's
you
know,
that's
a
that's
a
big
nice
to
have
the
the
simple.
B
A
Did
anybody
else
have
any
feedback
on
that?
Is
it
reading
through
probably
the.
B
I
know
I
know
this
is
always
going
to
be
a
controversial
thing
and
like
it's
a
controversy
that
predates
our
implementation
of
workspaces.
So
there's
not
much.
We
can
do
like
we're
going
to.
We
are
definitely
going
to
upset
half
of
the
workspace
users
with
whichever
direction
we
choose,
but
we
just
kind
of
have
to
pick
something
and
go
with
it.
Yeah.
A
Yeah,
I
I
just
put
down
the
first
comment.
At
least
note
I
took
was
paraphrasing
language
is
hard.
D
I
I
think
it's
fine
so
long
as
as
we
define
it
consistently
and
and
reference
that
that
definition,
so
the
glossary
yeah.
I
think.
B
That's
the
best
solution,
yeah,
the
only
the
action
item
here
is
close.
This
rrfc
we're
not
going
to
do
it,
we're
not
going
to
change
it,
add
a
glossary
to
our
docs
and
probably
do
a
you
know
an
editorial
pass
through
our
docs
to
make
sure
that
we're
using
them.
These
words
consistently.
A
So
I
took
down
an
action
item
to
add
or
amend
the
meeting
notes,
as
so
I
capture
focus
sentiment
properly
but
yeah.
Let's
move
on
then
to
and-
and
I
guess
the
action
item
here
is
also
close.
This
rfc,
I
don't
believe,
like
we
need
to
necessarily
keep
this
open.
A
Moving
on
then,
to
the
issue,
428
npm
publish,
should
tell
you
the
endpoint
that
it's
about
to
publish
too.
I
believe
that
this
this
essentially
follows
up
on
another
issue.
I
I
can't
find
it
in
the
short
time
that
I
was
looking
that
other
folks
have
had
for.
A
I
believe
we
made
a
change
to
npm,
login
or
npm
ad
user
to
essentially
output,
which
registry
you
were
configured
to
in
which
you
were
about
to
send
your
password,
and
you
know
auth
token,
essentially
to
I
think
this
is
a
similar
kind
of
ux
improvement.
That
seems
like
a
no-brainer
from
my
perspective,
I'm
not
sure
if
other
folks
have
any
any
thoughts
or
feelings
on
this
I'll
share.
The
reference
here.
A
A
A
I
think
it
makes
a
lot
of
sense
everybody's
a
thumbs
up
pretty
thumbs
up.
A
B
G
A
E
Speaking
of
printing,
that
would
be
nice
in
case
where
I
have
my
two-factor
setup-
would
be
nice
to
print
the
target
registry
before
the
prompt
for
the
second
factor.
B
E
A
E
Now,
to
be
more
specific,
I
would
suggest
doing
the
same
changes
to
npm,
regardless
of
the
dry
run
flag,
because
the
dry
iron
is
there
to
emulate
everything
except
modifying
the
outside
world.
So
it
would
be
nice
to
have
the
exact
same
behavior
from
both
just
let
the
dry
run
stop
before
it
actually
pushes
anything.
B
That's
good,
though
yeah
I
I
think
I
mean
we're
getting
down
to
like
ordering
of
lines
of
code
at
this
point
I
think
yeah
it
should
just
print
it
as
the
first
thing
whether
it's
dry
run
or
not,
say
we're
about
to
push
to
this
target
location.
B
The
two
factor
off
request
happens
if
we
make
the
push
and
then
get
a
response
from
the
server
saying,
you
need
a
two
factor,
so
that's
that's
always
just
going
to
be
only
when
we're
actually
doing
the
publish.
F
B
A
Okay,
anything
else
any
other
feedback
on
this
other
than
it's
good.
Let's
do
it
one
thing
I
might
want
to
just
taking
a
step
back.
Is
there
any
similar
commands
folks
can
think
of
that
require
this
or
you'd
like
to
see
essentially
the
target
printed
out
in
the
output,
so
we
have
login
now
and
we
would
have
published
to
essentially
do
this.
Is
there
other
commands
you'd
like.
B
Yeah,
I
would
imagine
it's
just
where
it's
going
to
be
necessary
is
stuff
where
we're
doing
a
write
to
the
registry,
so
public
team
or
publish
and
publish
team
org
dis
tags
that
kind
of
stuff.
B
I
think
it's
a
little
bit
less
less
so,
but
and
a
lot
of
times
in
most
reads
the
the
output
will
tell
you
that
anyway,
if
you
do
really
want
to
see
where
we're
where
we're
making
http
requests,
you
can
always
just
turn
on
the
http
log
level
and
you'll
see
every
http
request
but
like
if
we,
if
we
printed,
for
example,
if
we
did
this
in
install
it'd,
be
pretty
noisy
right,
because
a
lot
of
times
when
we're
doing
reads
we're
doing
like
thousands
of
them.
C
Would
having
a
like
registry,
colon,
whatever
the
registry
url
at
the
beginning
of
an
install,
is
like
an
optional
thing
like
dash
registry
or
something
b
or
show
registry,
be
a
potential
option
because,
like
I,
I
have
absolutely
run
into
that
when
using
like
verdaccio
or
something
where
I
think
I'm
reading
from
verdaccio
and
I'm
not
and
like
because
it
my
brain
just
thinks
I'm
already
doing
that.
C
D
C
I
think
I'd
be
happy
to
just
have
a
registry,
although
that's
fair,
I
perhaps
batch
it
so
like
group,
the
ones
that
are
from
I
don't
know
how
the
resolution
works.
So
I
don't
know
if
it
goes
it
like
iterates
through
an
entire
registry
first
and
it
goes
and
iterates
it
with
the
other
one.
But
now.
E
C
B
I
mean
because
imagine
like
a
clean,
install,
no
node
modules,
no
package
lock
right,
you,
you
depend
on
five
different
packages
from
five
different
registries
and
some
of
them
then
point
back
at
other
registries
or
have
you
know,
name,
space
scopes
that
are
namespace
to
a
particular
registry
like
it's,
it
gets.
The
read
case
gets
pretty
complicated,
yeah.
What
we
could
do
is
we
could
tell
you
like
well
and
also
we
don't
know
that
it's
like
a
registry
in
a
lot
of
cases,
it's
just
there's
a
url
at
this
host
name
right.
A
A
And
then
the
safety
safe,
safeguard
there
so
just
be
using
that
or
like
having
that
and
dry
run,
essentially
like
if
you're
concerned
that
you're
gonna
be
publishing
to
the
wrong
registry,
you
can
like
you,
can
use
dry
run
so
yeah
cool
any
other
feedback
before
we
move
on,
took
action
night
on
there
moving
on
to
item
and
issue
427
the
npm
rc
file,
improvements,
also
by
evan
carroll,
who
I
don't
think
is,
has
joined
us
pasting.
A
reference
here.
B
My
my
objection
to
this
rrfc
is
that
it
goes
just
far
enough
to
be
a
breaking
change,
but
not
nearly
as
far
as
I
would
like
to
go
with
refactoring
our
configuration
layer.
We
have
we've
been
kind
of
discussing
internally
in
the
clay
team
on
like
ways
that
we
can
improve.
Config,
there's,
there's
just
a
number
of
gotchas
that
are
all
kind
of
you
know
a
series
of
small,
reasonable
steps
that
got
us
to
a
very
unreasonable
place
in
a
lot
of
cases.
B
So
you
know
one
one
example
that
I
always
bring
up
is
we
have
like
save,
save
dev,
save
optional,
save
peer,
save
prod,
and
then
we
have
to
figure
out
okay.
What
is
the
actual
save
type
that
we're
going
to
pass
to
arborist
when
it's
writing
stuff?
We
have
other
things
like
you
know:
global
versus
local
versus
location
equals
global
versus
location
equals
this
other
thing
and
then
also
there's
you
know,
do
we
do
we
switch
to
json
instead
of
ini.
B
All
of
these
are
really
good
things
for
us
to
try
to
tackle
in
a
breaking
change
in
assembler
major
change.
We've
also
discussed,
like
you
know,
having
separate
configs
for
install
versus
publish,
which
is
kind
of
close
to
what
evcarol
is
getting
getting
to
here,
maybe
different
configs
that
are
scoped
to
particular
registry
host
names
like,
for
example,
I
think
it's
come
up
recently
that
we
want
to
have
a
different
ca
file.
If
you're
talking
to
a
different
registry,
there
may
be
other
ones
right.
B
We
probably
want
to
have
a
different
timeout
for
different
ones,
like
anything
related
to
http,
could
kind
of
be
bundled
under
a
particular
host,
because
it's
all
specific
to
that
host
and
then
also,
most
recently,
as
we've
been
talking
about
workspaces
and
workspace
routes
and
like
if
you
cd
into
the
workspace
folder.
How
do
we
implicitly
decide
like?
Oh,
you
are
actually
in
a
workspace
you're,
not
in
just
a
random
root
project.
B
What
that
surface
there
that
jordan
brought
up
was
like
well.
Actually,
I
do
want
to
have
multiple.
You
know,
configs
that
are
scoped
to
a
particular
workspace
right.
I
might
want
to
have
one
workspace
that
has
prefer
online
and
another
workspace
that
has
prefer
offline
or
has
a
different
default
registry,
or
what
have
you,
even
though,
that
me
or
even
different
scope
mappings.
So
in
one
case
you
know,
scope
foo
goes
to
this
registry
within
this
other
workspace
scope.
B
Foo
goes
to
a
different
registry,
so
they're
different
things
and
they
cannot
be
deduped
against
each
other.
All
of
this
kind
of
speaks
to
like
we
need
to
take
a
step
back.
We
need
to
like,
and
our
and
our
config
logic
is
just
like.
It's
hairy.
It's
it's
convoluted
and
there's
things
that
have
side
effects
on
one
another
in
order
to
implement
the
functionality
that
people
need.
So
it
would
be
really
nice
to
make
it
better.
B
Oh
last,
last,
and
certainly
not
least,
if
you
run
npm,
install
dash
dash
red
sit,
reg
sit
tree,
equals
my
private
registry
it'll,
just
install
from
the
default
registry
because
you
misspelled
it
so
and
this
this
the
fact
that
we
kind
of
allow
any
old,
willy
nilly,
config
and
we'll
just
parse
it
and
throw
it
in
the
throw
it
in
the
environment.
B
Even
if
it's
something
that
doesn't
match
what
we
already
know
about
has
really
caused
more
problems
than
it's
caused
benefits
caused
more
problems
than
it
solved,
so
it'd
be
nice
to
get
away
from
that
as
well
and
and
literally
say
like
if
it's
not
a
config,
we
know
about,
and
you
specify
it
in
the
in
the
cli
or
in
the
options
in
the
environment
or
your
rc
files.
We
will
actually
throw
an
error
and
say:
no,
I
don't
know
what
this
thing
is
you're,
trying
to
tell
me
to
do
something
whatever
it
is.
B
You
had
in
mind.
I
can't
do
it
so
I'm
going
to
give
up
so
yeah.
We
should
make
our
next
big
breaking
change.
A
complete
overhaul
of
the
config
system
get
away
from
oh
and
I'm
not
even
getting.
I
haven't
even
gotten
into
the
rant
about
like
nerf
darts
and
the
really
just
bizarre
way
that
we
track
off
across
multiple
different
registries.
So
I
will
wrap
up
to
say
our
next
big
breaking
change
should
be
a
major
config
tech
debt,
overhaul.
A
It
sounds
like
you're
venting
about
your
past
self.
B
Not
just
my
past
self
lots.
A
Of
people
lots
of
people
added
to
this,
but
we're
all
here
now
and
we're
all
in
it
together.
So
the
the
idea,
I
think
a
bit
of
synopsis
is
to
essentially
audit
config.
We've
been
talking
about
doing
a
comprehensive
sort
of
rfc
or
making
some
suggestions
on
how
we're
going
to
tackle
this,
including
like
what
you're
alluding
to
is
the
infinite
acceptable
configuration.
A
So
any
arg
is
accepted
by
the
npm
cly.
It
sounds
like
we
can.
Probably
you
know,
you
know,
take
this
back
internally
and
then
propose
some
sort
of
rfc
to
try
to
tackle
this
and
then
a
breaking
in
a
major.
E
One
idea
that
might
be
useful
for
doing
something
before
the
major
version:
this
could
go
into
user
space.
So
just
a
thought.
It
is
a
possibility
that
when
you
come
up
with
the
format
and
the
actual
values
to
put
in
it,
you
could
have
a
package
that
people
can
optionally,
install
and
use
to
have
the
new
config
format
and
then
use
that
package
to
translate
to
the
old
format
that
would
be
used
by
npm
7
and
then,
when
npm
8,
assuming
it
happens
in
eight,
comes
out.
B
Yeah
we
could
theoretically
have
a
have
a
thing
that
will
or
or
even
an
opt-in
feature
that
would
read
the
new
format,
the
new
kind
of
experimental
config
format
and
then
just
dump
everything
into
the
environment
that
it
finds
right,
and
that
could
also
then
throw
an
error
if
it
finds
something.
That's
you
know
something
gets
put
in
there.
That's
not
a
known
config
value,
the
the
reason
why
that
doesn't
quite
go
all
the
way
is
we
still
have
save
dev
save
optional,
like
there
are
actual.
B
There
are
actual
config
values
that
we
like
config
keys,
that
we
need
to
do
away
with.
We
should
probably
even
get
rid
of
dash
dash,
global
and
and
just
kind
of
make
our
the
space
of
our
config
name
space,
smaller.
C
B
Well,
you
can
do
that
today.
I
mean
there
are
some
good
aspects
of
our
config
system
that
I
would
certainly
want
to
keep.
It
is
extremely
flexible
and
customizable
to
a
large
number
of
workspaces
like
that's
that
much
we
wouldn't
want
to
get
rid
of,
but
right
now
like,
if
you
do
npm
install
dash
dash,
save
dev
dash
dash,
save
optional
dash
dash
save
peer
foo.
B
B
It's
just
when
we're
installing
something
we
can
only
have
one
save
type,
and
so
we
collapse
these
multiple
different
booleans
to
a
single
option
parameter
and
it's
just
not
clear
and
it's
very
order
dependent.
So
it
gets
really
bizarre.
B
Gotten
better,
I
will
say
it's
gotten
better
in
npm,
seven
like
at
least
the
logic
for
doing
this.
Weird
thing
is
not
smeared
out
in,
like
15
different
commands
and
being
done
inconsistently.
It's
happening
kind
of
all
in
one
place,
but
it
as
it
turns
out
moving
all
that
logic
and
putting
it
all
in
one
place
just
made
all
of
us
hate
it
even
more.
A
Yeah,
so
I'm
wondering,
if
there's
some
interim
step
as
well
in
terms
of
like
what
zb
was
mentioning
like,
creating
some
sort
of
like
path
for
how
we
we
get
from
here
to
there
hate
driven.
A
I
would
like
something
like
a
throw
on
unknown
or
something
that
like
is
a
net
new
flag
that
essentially
is
trying
to
limit
the
scope
of
what
we
accept
and
is
acceptable
and
then
creating
that
as
a
default,
going
forward
or
eventually
introducing
like
over
time.
We're
gonna
like
have
more
discussions
on
this,
but
because
everything
we've
been
talking
about
is
is
very
much
like
hand
wavy,
but
I
know
that
we
as
you're
saying
isaac
like
we
want
to
make
changes
to
this.
A
Put
that
into
an
rfc
say
what
do
we
need?
What
do
we
not
need?
I
think
we've
already
made
a
good
like
a
lot
of
refactoring
work
happen
here
in
this
place.
To
like
say
what
is
trinary,
what
is
affecting
what
flag
affects
what
other
flag
like
this
is
essentially
just
an
audit
of
all
our
config
and
then
potentially
introducing
that
new
format
for
doing
things
that
are,
like
you
know,
commit
command
specific
yeah.
B
B
Yeah,
so
the
the
I
I
don't
know
that
it's
all
that
hand
wavy,
but
one
other
thing
I
forgot
to
mention
is
not
not.
I
just
really
want
to
deprecate
it
and
never
see
it
again.
There's
there's
better
faster,
more
straightforward,
doing
less
stuff
options
out
there
now
that
we
should
just
use
instead.
B
Yeah
we
need
it,
we
need
to
have,
I
mean
you're,
you're,
right
and
zb
is
right
like
we
need
to
have
some
kind
of
on-ramp
to
it,
and
I
think
once
we
figure
out
kind
of
what's
the
goal
and
state
we
can,
we
can
figure
out.
I
mean
we
could
write
a
thing,
that'll,
just
sort
of
do
the
best
approximation
to
npm,
8
or
npm
9,
config
and
then
sort
of
squash
it
into
a
project.
Npmrc
file.
B
And
we
can
also
have
it
continue
to
read
the
ini
file
and
then
turn
it
into
the
new
format
for
you
or
somehow.
I
definitely
don't
want
to
live
long
in
a
world
where
we
have
multiple
different
kind
of
config
formats,
so
it
could
be
json
or
could
be
ini,
yep.
A
Okay-
and
it
sounds
like
we
should
also
like
defined
scope
explicitly
so
like
when
we're
talking
about
improvements
to
let's
say
we
want
the
ability
to
do
command,
specific
or
even
workspace,
specific
config,
that's
different
than
us
saying
that
we
also
want
to
eliminate
the
infinite
config
problem
we
have
today
and
rebecca.
I
see
you're
also
coming
in
here.
B
Ideally,
I
want
the
config
validation
to
like
you:
shouldn't
need
to
use
npm
doctor
because
npm
anything
should
crash
if
it
gets
a
config,
that's
not
valid
instead
of
right.
Now,
if
you
give
it
an
invalid
value
like
if
you
did
dash
dash,
save
dev
equals
seven
it'll
say:
well,
that's
a
number
and
I
need
a
boolean
for
this,
so
I'm
just
going
to
ignore
it.
What
it
should
really
do
is
crash.
C
B
B
We
could
surface
it
a
little
bit
more
make
it
a
little
bit
more
visible.
I
think
people,
I
think
mostly
people
don't
use
it
because
they
don't
know
about
it.
If,
if
we
could
detect
that
there's
something
some
weird
issue
and
say
hey,
you
should
run
an
npm
doctor
or
whatever,
but
the
problem
is
detecting.
The
issues
is
like
the
thing
that
doctor
is
for
so
it's
hard.
A
To
know,
there's
no
way
to
limit
the
set
right.
You
can't
just
filter
out
and
do
one
specific
check
with
doctor
today.
So
that's
another
like
improvement.
We
could
make
if
we
were
to
increase
the
scope
of
what
that's
doing.
You
should
also
introduce
something
to
be
like
just
run.
This
specific
check
like
npm,
docker,
os
or
whatever,
like.
B
Yeah
we're
getting.
I,
I
don't
think,
that's
the
the
the
thing
to
to
help
with
our
on
ramp
for
new
configs,
though
I
think
there
may
be.
It's
definitely
something
we're
gonna
have
to
think
about,
because
that's
and
that's
sort
of
why
we
flinched
away
from
doing
this
in
npm.
Seven
was
just
it's
it's
too
big
and
we
already
have
pure
depths
and
a
bunch
of
other
breaking
changes
in
seven.
B
So,
if
we're,
if
we're
going
to
break
config
like
we,
we
need
to
think
about
that
in
in
a
similar
way,
yeah
so
doing
it
doing
it.
In
user,
space
like
there
could
be
like
an
npm
wrapper
that
will
just
like
check
your
configs
and
sort
of
coerce
it
into
the
old
format
or
throw
if
it's
unknown
and
that
could
be
worthwhile.
I
don't
know
yeah
be
an
option.
A
Let's
try
to
get
to
the
last
one
with
the
time
that
we
have
left
and
I
took
a
an
action
item
for
our
theme
to
essentially
just
go
back
and
provide
you
know,
there's
a
lot
of
gripes
and
groans.
Let's
actually
put
a
rfc
together
about
what
we
plan
to
do
about
this,
so
number
425,
so
fpm,
unplug
billish
should
have
some
type
of
warning.
When
on
publishing
a
package,
I
will
copy
and
paste
the
ref
here
again.
This
was
made
last
week.
A
I
don't
think
anybody
else
has
noted
anything
about
this.
Yet
this
is
another
example
of
well.
We
could
also
provide
better
initial
context
around
which
registry
you're,
obviously
trying
to
unpublish
to
car.
I
see
your
hands
up.
Did
you
have
any
feedback.
G
B
Things
so,
if
you
yeah
also
again,
I
mean
we're
talking
mostly
about
the
the
npm
registry,
the
public
registry,
but
this
is
only
relevant
if
you're
unpublishing,
the
last
version
of
the
package
or,
if
you're,
unpublishing,
all
versions
with
dash
force.
B
A
A
E
E
Up
after
yourself,
because
you're
not
gonna
be
able
to
unpublish
something,
that's
not
very
fresh,
so
you're
not
gonna
break
anyone
anymore,
like
let's
had
famously
did
so.
This
is
not
that
big
of
a
deal
I
would
say.
I
think
the
the
annoying
thing.
B
B
B
And
the
reason
why
yeah
it's
it's
well
documented
as
an
annoyance
with
our
current
policy.
B
The
reason
why
we
don't
let
you
publish
a
new
version
for
24
hours
after
a
full
unpublish
is
because
a
full
unpublished
is
kind
of
leaving
it
in
this
somewhat
vulnerable
state,
where
an
attacker
could
publish
a
new
version
right,
because
there's
now
there's
no
auth
checks
on
that
name.
B
What
we
could
also
do
is
we
could
amend
our
you
know
we
could
try
to
like
look
at
the
registry
policies
and
just
amend
it
to
say
you
know
if
you're
publishing
a
new
version
of
a
package
that
was
unpublished
within
the
24
hours,
you
can't
publish
a
new
version
unless
you
are
the
person
who
unpublished
it
right.
So
if
you
were
the
one
who
did
that
full-on
publish,
you
can
still
write
to
it,
but
nobody
else.
Can
I'm
surprised
it's
not
the
case
now.
I
probably
just
nobody
thought
of
it.
B
I
don't
know
it
might
be
hard
for
some
reason.
B
I
assume
this
is
somewhat
difficult,
so
the
unpublish
not
being
able
to
unpublish
something
after
24
hours
was
added
after
left
pad.
This
is
not
being
able
to
republish
something
within
24
hours
after
a
full
unpublish,
which
is
a
different,
somewhat
newer
policy.
I
think
that
went
into
effect,
at
least
since
we've
been
at
github,
so.
A
And
just
to
be
my
photo
again,
this
is
all
specific
to
the
public
registry
and
our
policies
there,
but
the
yeah,
the
reasoning
behind
that,
as
far
as
I
know
for
context
is
so
there
wasn't
someone
that
can
go
and
squat
on
a
name
of
a
package.
A
E
But
isn't
this
not
helping
you
because
now
it's
a
matter
of
who
wakes
up
first.
B
It
just
makes
it
it
does.
I
mean
it
increases
the
barrier
to
attack
somewhat,
because
you
can't
just
have
a
script
that
will
hijack
any
that'll
be
watching
for,
deletes
and
immediately
hijacking
anything
that
comes
through.
So
anybody
who
is
depending
on
that
will
have
a
24-hour
window
in
which
their
build
will
break
and
they'll
see
that
there's
something
going
on.
A
So
I
know
we
are
at
time
I
just
want
to.
I
guess
capture.
One
more
thing
on
this
is
that
this
seems
very
similar
to
especially,
I
think,
cb.
You
know
it's
something
along
the
lines
of
a
two-step
process.
A
It
sounds
very
similar
to
when
we
were
having
discussions
about
npm,
published
props,
so
imagine
like
an
npm,
unpublished,
prompt
could
be
implemented
here.
That
might
be
might
allow
you
to
have
more
visibility
or
again,
like
a
two-step
process
or
requiring
force.
Even
might
just
make
folks
more
aware
about
what
they're
going
to
do
it's.
A
It's
sounds
like
you
know,
there's
room
for
improvement
around
the
ux
of
this
from
the
cli
standpoint,
but
the
actual
policy
and
any
kind
of
like
messaging
that
a
registry
wants
to
provide
about
its
policies
for
unpublishing
is,
is
going
to
be
specific
to
that
registry
right.
So
there's
mechanisms
today
for
folks
to
essentially
provide
messaging
back
to
to
clients.
So
so,
in
terms
of
actions
for
this
I'm
going
to
leave
it
open
for
now
and
ask
folks
to
comment
on
the
issue
itself
that
they
want
to.
A
I
don't
know
if
there's
anything
we
want
to
do
specifically
if
we
want
to
potentially
open
up
discussion
for
npm,
unpublished,
prompts
or
a
two
factor,
or
not
two
factor,
but
a
two-step
process
from
publish
yeah.
That's
the
potential,
but
I
encourage
folks
to
participate
in
the
next
week
in
these
rfcs
and
we'll
be
back
next
week
same
time
same
place
and
thanks
everybody
for
jumping
on
today
cheers.