►
From YouTube: Open RFC Meeting - Wednesday, September 1st 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
rc
call.
Today's
date
is
wednesday
september.
The
1st
we'll
be
following
along
the
agenda
that
was
posted
in
issue
number
444
in
the
mpmrc's
repo
I've
spammed
the
meeting
that
stock
for
folks,
if
they
want
to
add
themselves
to
the
attendees
list
and
I'll,
be
trying
to
take
notes
as
usual
in
that
doc.
A
There's
also
a
reference
there
to
last
week's
meeting
notes
and
yeah.
I
just
want
to
quickly
acknowledge,
as
I
usually
do,
that
these
calls
and
all
comms
on
the
rfc's
repo
are
covered
under
of
code
of
conduct,
and
we
just
asked
folks
to
please
be
kind
and
thoughtful
to
each
other
as
we
discuss
drc's
in
flight
and
please
raise
your
hand
if
somebody
is
speaking
so
that
I
can
call
on
you
and
ideally
we'll
have
a
good
discussion
quickly.
A
A
If
not,
we
can
jump
right
into
the
agenda.
The
first
item
that
was
up
here
was
the
most
recent
issue
that
we
actually
created.
I
know
if
you
helped
get
this
together.
This
is
our
rfc
issue
number
445..
A
This
essentially
relates
to
the
breaking
changes.
We're
planning
for
npm
eight
milf
did
you
want
to
maybe
speak
a
little
bit
to
this.
B
Sure
so
the
idea
here
is
we're
we'd,
like
the
next
december
major
to
not
so
much
contain
a
lot
of
breaking
changes
so
much
as
it
does
just
kind
of
setting
us
up
for
success
for
the
future.
B
B
The
idea
there
is
we've
got
a
lot
of
node
10
workarounds
in
a
lot
of
different
places,
and
it
would
be
nice
to
get
all
those
chopped
out,
and
you
know
it
also
brings
us
up
a
little
bit
into
the
standards
that
we
can
follow.
As
far
as
javascript
itself
goes.
B
Another
big
part
of
what
we
want
to
do
with
this
is
with
the
release
of
npm
7.
We
created
quite
a
few
issues
where
people
who
were
using,
like
node
8,
for
example,
managed
to
install
npm
7
because
we
left
them
and
then
they
had
no
easy
means
of
restoring
an
npm
that
actually
works
for
them.
B
So
one
of
the
big
things
that
we'd
like
to
get
accomplished
with
npm
8
is
fixing
that
problem
and
making
it
so
that
npm
will
flat
out
refuse
to
install
a
version
of
itself
that
is
not
compatible
with
the
current
node
that
the
user
is
using
doing
that
will
just
kind
of
help
us
make
sure
that
we're
not
in
breaking
things
that
we
don't
need
to
break
for
one,
and
it
also
gives
us
a
way
to
encourage
people
to
update
their
node
and
their
npm.
B
By
saying
no,
you
can't
update
your
npm
until
you
update
your
node
go
here
to
find
out
how
so
that's
as
far
as
breaking
changes.
That's,
I
think
all
we
have
planned,
but
sorry
go
ahead.
Darcy
I
was
just
gonna,
say
yeah.
I
agree
yeah
yep,
so
it
should
be
a
relatively
painless
migration
for
anybody
who's
already
using
npm7,
and
it
just
will
set
us
up
a
little
bit
later
to
do
npm9
with
some
actual
braking
change
features,
and
not
just
this.
A
B
B
Yeah,
I
just
saw
that-
and
I
also
just
saw
gars
so
the
stricter
peer
depths
change
becoming
default.
That's
one
that
we
could
consider
but
yeah.
I
don't
know
if
we'll
we'll
do
that,
we
want
to
try
to
keep
it
as
easy,
a
migration
as
possible.
So
it's
it's!
It's
a
possibility.
That'll
not
happen
in
the
next
release.
B
The
dropping
the
programmatic
api
is
another
one
that
we
should
very
much
consider.
We
expose
a
programmatic
api,
but
right
now
it's
all
callbacks
and
it's
not
very
good,
not
very
consistent,
so
we're
kind
of
thinking,
npm
8,
will
just
remove
that
api
entirely
for
now
and
that
will
allow
us
time
to
design
something
with
intent
before
the
next
december.
Major.
C
Yeah,
I
I
so
one
thing
I
think
might
be
gar's
comment
as
well.
The
refuse
to
install
broken
npm
should
really
be
an
npm,
seven
change,
that's
not
a
breaking
change
and
that
will
actually
set
us
up.
Then.
If
anybody
installs
eight,
we
know
they
have
a
working
node.
Yes,
the
other
thing
as
far
as
stricter
peer
depths
you're
right.
That
is
a
whole
other
proposal
in
conversation,
I'm
assuming
that
that's
setting
the
strict
pure
depth
flag
on
by
default,
that's
going
to
be
a
really
really
tough
one.
C
I
think
you
know
even
anytime
soon
it's
it's
still
very
much
the
case
that
you
know
if
you,
if
you
look
at
a
lot
of
projects
out
there
in
the
wild
they've
all
got,
you
know,
peered
ups,
that
end
up
with
an
invalid
kind
of
overridden
edge,
because
it's
just
it's
a
it's
a
mess
out
there
so
and
things
are
mostly
working.
So
it's
probably
fine
how
it
is.
C
I
think,
that's
probably
going
to
stay
opt-in
for
the
foreseeable
future,
just
until
there's
until
it
will
break
less
than
you
know,
a
huge
majority
of
projects
using
peer
devs
today.
D
Yeah
the
I've
been
kind
of
having
pre-talks
with
like
miles
and
some
other
notejs
folks,
the
less
that
breaks
here,
the
more
likely
we
can
get
this
into
the
current
node
at
16
too.
D
If
all
we're
doing
is
dropping
a
node,
that's
not
16
and
just
breaking
the
programmatic
api,
and
that
that's
going
to
be
our
our
soft
point.
For
with
them,
it's
much
more
likely
to
come
in.
If
we,
if
we
change
the
pure
depth
flag,
there's
no
way
it
lands
in
16.
A
That's
a
good
thing
to
note
is
the
reason
why
we're
limiting
these
changes
is
is
for
the
best
possible
outcome,
which
is
we
can
yeah
land
and
npm
eight
in
note,
16
right
so
yeah,
that's
a
very
good
thing
to
caveat
and
and
the
reason
why
we're
we
have
sort
of
a
very
small
scope
here.
A
I
think
it's
good
to
note
as
isaac
said,
and
I
took
the
note
that
yes,
the
the
change
to
refuse
to
install
an
npm
version
that
has
a
mismatch,
engine's
mismatch
or
is
unsupported
by
the
current
version
of
node.
That
you're
trying
to
install
under
is
npm7
change
that
we'll
make
before
we
cut
the
node
or
npm
8
version.
A
Okay,
if
there's
no
other
comments
there,
we'll
we'll
keep
this
issue
open,
probably
right
up
until
we
cut
the
npm
eight
release
just
to
consolidate
any
communications,
we
can
continue
to
reference
it
until
we
actually
make
that
change
and
yeah
appreciate
nilfu
you
championing
and
opening
up
that
that
issue
moving
on
to
issue
or
sorry
pr
number
441.
A
This
is
the
addendum
to
the
overrides
spec,
which
I
think
came
out
of
some
internal
pairing
sessions
that
I
know
isaac
and
I
think
nilf
have
been
doing
to
actually
implement
override
so
isaac
did.
You
want
to
speak
to
maybe
just
the
change
and
whether
or
not
there's
anything
we
need
to
consider
based
on
jordan's
comments.
As
last
week.
C
Yeah,
so
essentially
what
this
does
is
it
says
if,
when,
when
considering
sort
of
a
an
override
rule
and
trying
to
decide
whether
it
applies
to
a
given
node
in
the
tree,
we
of
course
look
at
the
key
in
that
overrides
object.
C
However,
if
the,
if
the
value
either
is
a
string
or
it's
an
object
with
a
dot
member
and
that
that
value
that
kind
of
self
value
also
matches
the
current
the
current
node,
then
we
will
also
consider
that
a
matching
override
rule.
C
Otherwise,
we
can
very
easily
get
into
a
state
where,
if
we
only
look
at
the
key
right,
we
can
build
out
the
entire
ideal
tree,
and
then
we
put
that
you
know
we
reify
that
tree
to
disk
and
then
later
we
want
to
look
at
the
look
at
that
tree
and
say:
oh,
is
this:
is
this
what
I
should
have
well,
because
the
overridden
the
override
rule
is
applied
based
on
what
it
resolved
to
we?
We
have
no
way
of
knowing
that.
C
That's
why
it
was
sort
of
re-resolved
in
this
other
state
unless
we
start
doing
kind
of
additional
bookkeeping
somewhere
else,
which
is
pretty
brittle
right,
because
node
modules
folders
get
deleted.
C
People
blow
away
their
package
locks
like
it's,
it's
totally
common
and
what
we
don't
want
to
do
is
have
npmls
start
raising
a
warning
because
you
have
an
invalid
dependency
when
actually
it
is
valid,
it's
an
override
you've
said
you
want
this
one
instead,
so
yeah
the
changes
is
basically
the
an
override
rule
will
apply
if
the
key
matches
or
if
the
self
value
matches
a
given
node.
A
I
think
that's
good
synopsis
is
there,
like,
I
haven't
seen
other
than
jordans
ask
about
any
kind
of
like
caveats
beyond.
A
C
It
does
have
some
implications
for
the
for
the
actual
results
in
a
number
of
cases,
and-
and
I
was,
I
was
very-
very
glad
that
we
that
we
added
a
ton
of
examples,
even
though
it
made
this
rfc,
even
though
it
made
this
pr
more
significantly
more
work.
You
can
see
in
the
in
the
changes
like
exactly
what
got
changed
in
in
all
of
those
examples.
C
So
there's
a
couple
of
cases
where
you
know
we
end
up
with
things
either
being
applied
or
never
being
applied,
because
the
because
an
earlier
override
role
affected
it.
A
So
the
action
I
am
here
like,
I
think
we
can
just
close
this
out-
do
you
want
to
take
the.
A
C
Yeah
we
haven't
made
too
much
progress
on
implementation,
but
it's
it's
basically
like.
If
we
can't
do
this,
then
we
got
to
figure
out
something.
That's
going
to
be
a
lot
worse.
So,
okay,.
A
So
just
pull
it
in,
though
okay
sounds
good
cool.
Moving
on
to
the
draft
rfc,
there
were
both
robust
lifecycle,
scripts
pr437.
This
is
from
fritzy.
Is
there
any
update
here
that
you
want
to
share.
E
A
brief
summary
is
that
for
life
cycle
scripts,
as
they
are
now
well
in
previous
version
of
npm
npm
6,
we
had
an
uninstall
and
pre
and
post
script
doesn't
make
sense
with
the
way.
E
Now,
maybe
I
shouldn't
have
made
an
rfc
before
I
had
a
fully
fleshed
out
idea
of
what
this
should
look
like,
but
I
wanted
to
start
a
conversation
with
the
community
on
how
we
could
have
more
robust
life
cycle
scripts,
because
people
really
do
rely
on
these
scripts
for
their
packages.
A
Yeah,
I
think
it's
good
to
do
it
this
way
like
drop
the
rfc
and
just
that
makes
it
notable
that
it's
not
like
a
fully
fleshed
out
idea
and
then
ask
for
help
and
support
from
community
and
and
feedback
on
the
initial
idea.
So
I
don't
think
that's
a
bad
idea
at
all
at
fritz,
so
yeah,
but
we
can
develop
it
over
time
and
and
hopefully
get
to
somewhere.
That's
more
concrete
in
the
months
to
come.
It's
not
something
that
we're
going
to
be
able
to
queue
up
right
away,
but
yeah.
A
It's
important
for
sure,
like
a
clear
context
between
you
know
the
consumption
and
the
consumer,
and
those
events
I
think,
is
important-
and
I
think
this
is
is
good
to
like
have
map
this
more
and
potentially
have
a
way
to
delineate
between
those
types
of
events.
Right.
So
that's
cool
awesome,
so
we'll
move
right
along.
Maybe
we
can
take
an
action
item.
If
do
you
want
more
visibility
on
this?
Should
we
get
like
more
people.
E
A
So
moving
right
along
to
the
next
pr
that
we
had
open,
number
436
new
installation
mode.
This
is
the
pure
mode
or
restricts
mode.
We've
been
discussing
quite
a
bit
lately
proposed
by
vincent
bailey
vincent
did
you
want
to
give
a
quick
update
on
on
sort
of
the
changes
and
and
some
of
the
communication
and
conversation?
That's
happened
in
the
rfc.
F
Yeah,
so
so,
at
the
end
of
the
meeting
last
week
we
had
two
action
items.
F
F
So,
like
the
question
is
like:
should
that
be
a
major
bump?
That's
kind
of
how
I
read
that
question
and
I
think,
since
it's
going
to
be
an
opt-in,
it's
it's
not
going
to
cause
any
need
for
measure
bump,
and
I
I
think,
as
far
as
we
can
see
now
they
won't.
F
We
will
not
need
to
introduce
any
breaking
change
to
support
that
mode.
That's
our
current
thing,
our
current
vision,
but
it
it's.
Okay
later
we
discover
it
needs
a
major.
It's
it's!
Okay!
I
think,
and
then
the
second
action
item
was
to
figure
out
what
what
is
the
scope
like
how
much
the
ecosystem
would
break
with
the
stricter
installation
of
dependencies.
F
So
we
get
some
more
data
here.
So
luckily,
pnpm
and
yarn
plug
and
play
have
already
been
shipping.
A
strict
package
manager
for
a
while,
now
and
they've
been
actively
working
on
fixing
the
community
and
they
are
like
to
to
kind
of.
F
Thing
that
will
break
with
the
with
that
symlink
approach.
The
first
one
is
packages
that
have
omitted
to
declare
some
dependencies
to
their
in
their
packages,
and
so
this
is
like
apparent
from
the
the
feedback
we
got
from
the
owner
of
yarn.
This
is
not
an
issue.
There
is
no
good
reason
for
owners
to
omit
these
dependencies.
It's
only
a
mistake
and
some
don't
want
to
fix
them
because
they
only
care
about
pnpm.
But
if
we
implement
simulink
in
pnpm,
then
everyone
should
care
about
fixing
these
issues.
F
So
this
should
this,
should
this
should
be
able
to
to
be
fixed.
It's
still
undecided
whether
we
want
to
have
a
back
door
or
a
way
to
locally
override
or
declare
dependencies
that
you
know
are
missing
for
an
external
package
or
third
party
package.
F
So
that's
the
first
kind
of
things
that
can
break
with
sim
link
and
the
other
thing
is
environments
that
don't
support
sim
link.
As
you
know,
they
don't
follow
symlinks
and
we
got
from
the
pnpm
owner
an
example
that
apparently
the
amazon
web
services
functions,
don't
support
symlink,
and
we
know
that
the
metro,
which
is
the
react
native
bundlers,
also
doesn't
support
symlink
yeah,
so
that
that's,
I
think,
that's
all
we
are
aware
of
that
are
like
incompatible
with
the
use
of
symlinks.
F
A
So
there's
the
last
last
example,
so
you
said
amazon,
web
services
and
another
that
you're
aware
of
so.
E
So
there's
one
more,
I
believe,
vincent
and
that's
that's
packages
that
do
static
analysis
of
the
node
modules
directory,
like
for
logging,
like
eslint
loading,
plugins
right.
F
Okay,
okay,
so
so
this
is,
but
this
is
something
we
can
fix
because
they,
okay
and
and
the
fix
is
in
in
this
package
themselves.
Yes,
okay!
So
it's
in.
E
F
I
don't
know
yeah
it.
It
seems
that
the
you
know
it
won't
be
much
since
you
know
pnpm
and
yarn
already
paved
the
way
there
in
the
ecosystem,
and
it
seems
also
that
the
extra
step
that
is
needed
that
yarn
and
pmpm
didn't
manage
to
do.
They
didn't
manage
to
do
it
because
they
didn't
have
the
because
they
didn't
have
the
the
the
community
using
their
package
manager,
which,
which
would
not
be
an
issue
with
p
with
npm.
F
So
so
that's
that
so
it
it
doesn't.
That's
my
personal
opinion,
but
it
doesn't
feel
scary.
It
would
feel
scary
if
that
was
if
we
would
propose
this
as
a
default,
but
since
we
propose
it
as
an
opt-in
and
we
plan
to
make
it
in
a
way
that
you
can,
you
can
easily.
F
Swap
between
mode,
so
you
can
like
in
your
development
environment
and
your
ci,
you
can
have
use
trick
mode
or
pure
mode
to
kind
of
validate
that
your
repo
is
fine,
but
on
a
new
production.
If
you
want
to
develop
to
an
to
a
an
amazon
function,
you
you
may
decide
to
install
dependency
there
in
in
the
hoisted
mode,
and
things
will
still
work,
because
everything
that
will
work
in
pure
mode
will
also
work
in
hoisting
mode,
because
this
is
like
strict.
F
So
so
I
think
that's
that
makes
the
concern
less
less
scary.
A
No
comments,
really,
I
just
want
to
make
sure
I
captured
everything
and
so
yeah.
It
does
seem,
like
we've,
we've
presented
sort
of
like
a
few
of
the
known
problems
with
like
projects
that
might
want
to
use
this
new
reification
mode,
but
again-
and
I
posted
this
in
our
chat-
but
this
is
essentially
opt-in,
so
it's
there's
still
options
for
these
these
projects
in
terms
of
doing
package
management.
A
They
don't
have
to
try
to
use
this
mode
and
it
might
not
be
it's
not
viable
for
them.
Based
on
you
know
the
existing
pro
like
package
managers
going
down
this
road.
So
it's
I
just
wanted
to
essentially
note
that
yeah.
I
feel
like
your.
Your
comments
are
fairly
accurate
and
yeah,
like
the
concerns
with
is
this
going
to
break
me
has
already
been
that
that's
sort
of
already
been
discovered
by
implementing
this
strategy
and
other
package
managers
isaac.
I
see
your
hands
up.
C
Yeah,
so
I
do
so
the
main
thing
or
take
away
from
just
kind
of
a
brief
sync
up
before
this
meeting
I
think,
is
implementation-wise
the
way
it's
probably
going
to
look
is
that
we
create
the
hoisted.
C
You
know
as
if
it's
about
to
be
nested
tree
in
memory,
that's
what
actually
gets
written
to
the
lock
file,
but
then
we
have
a
you
know
when
you're
in
this
unhoisted
mode,
we
transmute
that
tree
and
then
that's
what
we
actually
put
on
disk.
So
there
is,
there
is
potentially
that
caveat
where
the
lock
file
and
the
node
modules
folder
are
no
longer
in
sync
with
one
another.
However,
we
still
have
the
hidden,
lock
file,
which
will
always
represent
exactly
what's
on
disk,
because
that's
its
purpose,
and
that
provides
interoperability.
C
If
you
have,
you
know
that
allows
us
to
keep
all
the
same
contracts
that
we
have
today
in
terms
of.
When
do
we
generate
resolve
errors
and
so
on,
as
well
as
allowing
interoperability
with
other
people
who
are
not
using
this
mode
on
the
same
project,
for
whatever
reason
you
know,
you'll
have
differently
shaped
node
modules,
but
other
than
that,
like
you'll,
be
getting
the
same
depths
and
the
same
versions
same
resolutions,
everything
the
the
other
comment.
I
wanted
to
say.
C
I
know
vincent
kind
of
touched
on
this
a
little
bit,
but
the
conversation
around
like
what
should
be
shared
if
there's
workspaces,
if
there's
peer,
dabs,
etc.
That's
a
separate
conversation
going
on
in
rfc,
pr,
335
or
375.,
and
anything
we
decide
there.
We
can
implement
with
unhoisted
mode
actually
more
easily
than
with
our
current
reification
strategy.
So
I
think
that's
a
little.
It's
a
little
bit
of
a
red
been
a
little
bit
of
a
red
herring
in
this.
In
this
unhoisted
rfc
proposal.
F
Yeah
this
there
has
been,
I
think,
some
inefficient
discussions
due
to
unclear
vocabulary,
and
I
I
may
be
only
speaking
for
myself,
but
at
least
for
me
the
term
sharing
was
not
always
clear,
so
so
yeah,
that's.
F
C
So
I
think
we
got
next
steps
and
maybe
even
a
start
of
kind
of
how
to
start
looking
at
this.
So
thinking
about
it.
A
Yeah
sorry,
what
were
the
action
names
from
the
the
call
before
you
said,
you're
gonna
take
on
the
ashland
vincent
to
split
out.
So
could
you
just
reiterate
what
what
it
is
you're
gonna
do
next.
F
A
F
E
Right
to
to
specifically
to
rework
the
motivation
section
to
be
focused
less
on
the
the
side
effects,
discussion
and
more
on
the
the
the
motivation
behind
the
unhoisted
mode
in
workspaces
itself,
so
yeah
and
then
the
other
action
item
that
we
came
up
with
when
thinking
earlier
today
was
what
isaac
said
was
to
kind
of
redirect
some
of
the
discussion
on
what
things
should
be
shared
to
that
other
rfc.
C
F
Yeah
so-
and
there
is
like
a
few
more
points
in
the
in
the
comments
of
the
rfc,
so
there
is
one
about
the
naming,
so
it
seems
to
be
consensus
that
pure
mode
is,
is
not
the
name
we
want
to
go
with,
so
we
will.
We
haven't
decided
yet,
but
we
will
not
go
with
the
pure
mood.
We'll
come
up
with
something
more
all
right
and
you
know
in
computer
science
there's
two
hard
things:
there's
caching
validation
and
naming.
So
we
will
we'll
work
on
that.
One
on
naming.
A
I
thought
that
was
it
was
too,
was
it
two
hard
problems
or
three
hard
pro
or
four
heart
problems,
and
the
third
problem
is
off
by
one
errors,
I
think,
is
the
one
or
yeah?
Oh.
F
A
F
I
think
I
can
come
up
with
the
list
of
candidates
next
week
to
this
meeting
and
then
we
can
discuss
it
yeah
or
pull
yeah
that
too,
so
we
don't
exclude
people
that
cannot
join
the
call
yeah.
A
Async
poll
has
worked
in
the
past
when
we
were
trying
to
come
up
with
names
and
just
see
where
people
felt
best,
so
it
might
be
even
a
good
idea
to
create
a
separate
issue,
and
just
for
that
itself,
I
think
we
even
have
a
poll
generator.
I
think,
as
a
as
like
a
slash
command
within
our
issues,
but
I
can
take
up
with
you
separately
to
get
that
going.
A
A
G
F
There
yeah,
so
we
will
we'll
we'll
work
on
this,
so
it's
ready
for
next
week
and
then
there's.
Another
question
is
whether,
because
like
this
rfc
like
the
motivation
is
about,
you
know
not
not
over
sharing
dependencies
between
workspaces,
and
so
this
is
like
in
the
motivation.
F
This
is
like
this
comes
from
workspaces,
and
there
is
this
question
whether
the
implementation
should
be
limited
to
workspaces
or
whether
any
project
using
npm
should
be
able
to
obtain
that
mode,
and
the
answer
is
that
any
any
project
should
be
able
first,
because
the
implementation
is
actually
pretty
generic,
it's
not
specific
to
workspace,
and
so
we
can
get
the
same.
F
F
F
So
I
think
that's
also
a
good
motivation
to
to
enable
that
that
strategy
in
in
projects
that
don't
use
workspaces.
A
A
That's
last
note:
properly.
There
was
a
question.
It
seemed
like
that
whether
or
not
this
rfcu
should
be
or
will
apply
to
all
projects
and
not
just
workspace
projects
and
what
you've
said
is
yes,
this
work
and
and
this
rfc
should
encapsulate
all
projects
that
want
to
take
advantage
of
this
strict
mode.
A
F
Possibly
I'll
I'll
I'll
read
for
from
it,
I
know
tierney
you,
you
said
you
were
disappointed
that
this
would
not
be
supported
by
project,
so
you
maybe
have
misread,
and
if
this
is
the
case,
then
is
the
proof
that
we
need
to
rephrase
yeah.
H
For
sure
I
definitely
miss
my
perception
reading.
It
was
that
it
wouldn't
be
supported
in
non-workspaces
environments
and
that
that's
something
I
would
like
to
see,
although
I
know
that
that
would
definitely
require
additional
work
and
that
that
can
be
done
separately.
I
think
that's
potentially
fine
like
if
there's
a
global
cache,
even
that
kind
of
that
becomes
an
interesting
thing
that
is
probably
separate
from
the
implementation
for
workspaces,
but.
F
Take
it
yeah,
so
you
must
read
we
from
the
beginning.
We
we
wanted
to
support
this
for
all
projects
and
I
don't
think
there
is
extra
overhead
in
implementation
to
support
it
everywhere
and,
like
maybe
you
know,
the
npmcli
team
can
confirm
this,
who
are
more
familiar
with
the
code,
but
I
don't
see
it
as
a
as
a
big
concern.
F
F
Only
one
more
comments
from
jordan
and
I
jordan
and
I
think
these
comments
like
are
created
by
this
confusion
in
the
vocabulary,
so
I
I
think
we
will
like
wait
for
the
re,
rewrite
or
the
clarification
and
then
and
then
follow
up
on
this
after
that.
A
Sounds
good,
that's
good
cool,
so
there's
a
couple
to-do's!
I
guess
on
your
plate
that
vincent
that
I've
added
here
I
appreciate
you,
updating
us
and
yeah,
we'll
we'll
obviously
work
with
you
to
try
to
get
this
in
good
shape
for
next
week
as
well.
Moving
on
then
to
rc422
npm
audit
assertions,
I'm
not
sure
tierney.
If
we
were
able
to
if
you're
able
to
essentially
give
an
update
of
maybe
some
of
the
conversation,
that's
happened.
H
Yeah
the
conversation
at
this,
I
I
believe
I've
completed
the
to-do's.
I
mean
there
wasn't
a
lot
from
what
I
recall.
Sorry.
I
have
a
little
bit
of
a
list.
It's
my
tongue
yeah,
but
I
I
believe
I've
completed
the
to-do's.
H
That
that
we
kind
of
left
with
there
seems
to
be
conversation
around
having
and
a
way
to
trust
third
parties
and,
like
their
have
third
parties,
tell
you
who
you
can
trust
or,
like
you
know,
say
I
don't
trust
dan
and
react
and,
like
I
don't
trust
the
react
team,
so
I'm
gonna
ignore
their
assertions
and
still
get
them.
H
I
I
don't
necessarily
agree
that
that's
the
best
path
forward,
because
it
it
because
it
gets
to
the
point
of
being
viral
where,
like
I
just
don't
trust
anyone
and
then
just
or
like
I
new
people
are
just
like
randomly
thinking.
Oh,
if
I,
if
I,
if
I
don't
trust
people,
that's
more
secure
and
then
the
problem
persists,
like
I
don't
think,
that's
a
particularly
excellent
path
to
solving
this
problem.
H
Further,
I
think
figuring
out
a
mechanism
for
sources
of
trust
is
annoying
and
very
hard,
and
I
don't
necessarily
think
it's
something
we
should
try
to
do
like
the
best
solution
I
can
come
up
with
or
that
I,
the
thing
that
I
would
think
would
be.
The
best
solution
would
be
to
have
a
module,
be
your
published
sources
of
trust
and
like
depend
on
that
somehow,
but
that's
just
it's
annoying
like
that's.
H
That's
it's
a
lot
of
work
and
I
don't
necessarily
think
that
the
value
derived
from
it
is
deserving
like
of
that
amount
of
effort.
H
Yeah,
so
that's
that's
where
it's
at.
I
could
be
wrong.
I'm
happy
to
back
off
on
that
point
and
build
that
in,
but
I
I
I
am
unconvinced
that
that
is
a
good
tool
or
a
good
good
thing
to
support,
but
happy
if
you
know
others
disagree
with
that,
I'm
more
than
happy
to
back
up
on
that.
A
Sure
I'll
just
again
give
the
reference
here
to
the
rendered
docs.
Since
I
some
folks
probably
haven't
read
in
a
while,
and
I
think
you
have
made
some
edits.
A
Yeah
I
I
agree.
I
basically
in
chat
noted,
like
some
folks,
are
never
going
to
be
happy
or
pleased
with,
like
the
trust
model,
I'm
like,
if
you
trust
the
authority
to
provide
you
audit
like
audit
alerts,
then
you
should
trust
that
same
authority
to
provide
you
with
like
metadata
about
those
alerts
or
like
essentially
create
like
the
mechanism
for
claims
that
this
is
no
longer
relevant
to
it.
To
me,
it's
like
not
trusting
the
ecosystem
at
large
so
like
that,
I
feel
like
we
can
never
build
any
tooling.
A
A
You
know,
however,
they
want
and
to
utilize,
that
metadata
than
to
make
that
like
actionable
in
a
way
that
is
specific
to
your
projects
right
like
yeah.
It's
not
that
we're
trying
to
enforce
what
you
consider
to
be
relevant.
I
guess,
but
it's
trying
to
introduce,
I
think,
brand
new
information
into
the
ecosystem.
That
is,
that
will
make
audits
more
useful
and
helpful
in
the
future.
So.
H
Yeah-
and
I
I
think,
there's
also
something
to
be
said
for
like
someone
can
go,
build
this
tooling
and
if
it's
compelling
and
if
it
has,
if
it
gains
usage,
I
think
that's
entirely
reasonable
to
rfc
it
in
because
it's
not
like
I'm
like
with
the
unfiltered
property,
you
can
just
get
all
that
data
and
then
like
have
an
additional
tool
that
you
pipe
that
out
to
and
process
it.
However,
you
want
with
your
with
your
trust.
H
I
I
think
that's
you
know
if
people
are
able
to
build
a
compelling
experience
with
that,
that's
fine,
I
think
that's
something
to
rfc,
but
I
think
initially,
I
I
think
the
kind
of
all
or
nothing
approach
is
a
bit
better,
because
I
mean
there's
a
lot
of
problems
with
with
deciding
who
to
trust.
Like
are
the
people
who
are
the
people
making
that
decision
who
are?
H
Are
they
informed
on
who's
like
actually
trustworthy,
that
that,
like
I
don't
even
know
necessarily
and
like
I
spend
all
of
my
time
in
this
space
and
like
I
can
make
educated,
very
educated
guesses,
but,
like
I
don't
know,
if,
like
you
know,
gmod
fan273,
who
maintains
a
module
that
has
13
million
downloads,
is
like
trustworthy
or
not,
and
so
getting
that
data
and
processing
it
and
is,
I
think,
like
if
you,
if
you're
at
the
level
where
you
care
about
that
filtering,
is
important
and
like
you're
you're
yeah,
I
don't
know
I
I
I
think
it
gets
real
rough
and
it's
not
a
model
that
we
thought
we.
A
Yeah
like,
if
you
trust
your
the
top
level
depths
to
then
have
maintained
depths,
and
then
they
they
like
trust.
It
like
it
starts
with
whoever
you're,
including
into
your
project,
right.
A
Yeah
yeah,
okay,
is
there
anything
to
consider
in
terms
of
the
actual
design
of
what
you've
proposed?
Just
looking
at
it,
like
some
of
the
patterns
are
a
little
bit.
I
guess
unique
to
this
one
command
yeah.
One
thing
that
I
noticed
is
like
just
the
module
flag.
A
I
I
don't
want
to
bike
shed
too
much
on
that,
but,
like
it's,
it's
definitely
a
pattern.
I
think
I've
only
seen
us
use,
maybe
with
mpx
or
npm
exec.
I
think
it
takes
a
package
flag,
I'm
not
sure
if
there
was
any
particular
reason
we
couldn't
no.
A
A
package
specifier
package-
I
don't
know:
okay,
okay,.
H
Yeah,
I'm
happy
to
show
you
that,
if
there's
any
design
decisions
in
this
that
are
weird
it's
just
because
it's
how
my
brain
thought
about
it
happy
too
happy
to
make
those
changes.
As
as
we
go.
A
Did-
and
I
I
can't
say
this
because
it's
a
long-running
thread
but
if
you've
been
following
the
conversation
there
did
mike
from
github.
Yes.
H
Asking
mike
yep
he's
jumped
in
he's
he's
jumped
in
a
few
times.
I
think
the
latest
one
was
on
the
trust
stuff.
I
asked
him
kind
of
he.
He
proposed
a
straw
person
example
of
how
to
potentially
set
up
trust,
and
I
I
kind
of
asked
how
he
would
how
he
would
use
like
how
what
identity
model
he'd
use.
He
kind
of
backtracked.
H
On
on
what
part
of
the
example
you
used
and
said
you
know,
domains
are
potentially
a
bad
option
for
ownership
and
then
suggested
something
that
basically
either
having
a
similar
function
to
the
gpg
keys
that
npm
or
the
github
publishes.
So
if
you
go
to
you
know,
github.com
user.gpg
you'll
see
the
public
gpg
keys
for
that
user.
The
github
has
or
trust
flag
with,
like
the
order
or
the
specific
org
slash
repo.
H
I
can
see
that
I
get
concerned
about.
I
mean
I
think,
having
the
you
know:
npmjs.com
user
dot,
gpg,
I'm
fine
with
that.
I
don't
know
necessarily
what
the
dx
would
be
on
that
and
then
the
trust
worker
org,
slash
repo.
H
I
would
prefer
it
to
be
a
like
a
scope
or
like
a
user
on
npm,
rather
than
tying
it
directly
to
github,
but
yeah.
That's
that's
the
only
thing
there
like
I,
I
think
you
know
if
we
want
to
go
down
that
trust
model
which
it
doesn't
sound
like
we
do.
At
least
I
I
I'm
I'm
unconvinced
of
it
at
this
point
yeah
that
I
I
think
that
the
trust
and
then
like
a
username
on
npm
would
be
the
most
ideal
path.
For
me.
H
Clear
from
your
side,
or
is
this
something
I
mean
making
those
changes
that
you
just
asked
for
it,
but
other
than
that,
I
don't.
I
don't
think,
there's
anything
clear
for
me.
A
Okay,
this
is
something
that
can
go
ahead
of
the
actual
api
existing
as
well.
We've
had
that
conversation
in
the
past,
where
we
don't
necessarily
need
the
service
to
actually
support
this,
especially
if
you're
configured
to
a
registry
that
might
support
this
and
like
especially
if
you're,
getting
like
your
audits,
audit
alerts
and
advisory
db
is,
is
being
hosted
somewhere
else
then,
potentially.
This
is
something
that
somebody
could
implement
other
than
the
public
registry,
so
yeah.
A
So
just
to
be
mindful
that,
like
we
could
say
that
we
want
to
do
this
and
add
this
to
the
cli,
but
it
may
not
actually
work
until
there's
a
service
for
it
to
actually
pull
out
that
information
or
yeah
send
the
information
cool
okay.
If
nobody
else
has
any
feedback
there,
we
can
move
on
to
the
last
item
that
was
on
here.
This
is
this
is
adding
types
information
to
package.json
in
the
registry.
I
think
the
reason
why
this
had
bubbled
up
before
was
gar.
A
D
Accurate
read
package
json
and
yeah,
we
iterated
on
it
since
the
last
meeting.
Basically
the
changes
between
then
and
now
are
that
there's
no
reason
to
even
evaluate
flow.
It
wasn't
part
of
the
original
request.
It's
just
like
hey.
We
should
do
this,
we're
supporting
more
than
one
thing,
but
no
one
has
asked
for
it
and
that
to
me
doesn't
meet
the
requirement
of
thus
putting
it
in
it's
way.
Easy
someone
says
hey,
you
should
do
this
to
flow.
D
Also,
it's
like
four
lines
now,
so
we
dropped
flow
and
I
think
that
was
the
only
tweak
so
basically
the
pr
which
I
can
pull
up.
103.
there's
chat.
There's
chat,
free
package,
json,
pull
request,
number
103.
D
So
I
clarified
that
they
wanted
on
types
and
not
typings.
Typings
is
the
old
way
of
doing
it
and
that
we're
adding
it
and
not
flow,
and
then
I
ping
the
original
author
of
the
rc.
It's
like
this
would
solve
what
they
need.
So
if
this
lands
anyone
publishing
in
this,
whatever
version
the
cli
has
this
update,
the
types
attribute
would
be
in
the
registry
if
they
have
types
auto
detected.
A
D
A
Cool,
let's,
let's
try
to
land
this
this
week,
then,
let's
try
to
prioritize
this
and-
and
today
I'm
trying
to
get
pulled
in
for
tomorrow.
Okay,
unless
there's
any
pushback
from
folks.
A
D
A
Okay,
to
pull.
D
A
We
got
a
couple
minutes
left.
Did
anybody
else
else?
Have
anything
they
want
to
bring
up
or
speak
to.