►
From YouTube: Open RFC Meeting - Wednesday, Oct 28th 2020
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
meeting.
Today's
date
is
wednesday
october
28th
and
we'll
be
following
along
in
the
agenda
that
was
posted
in
issue
268.,
I'm
going
to
copy
and
paste
just
for
everybody.
Just
in
case
again,
the
meeting
notes,
talk
in
chat,
feel
free
to
add
yourselves
to
attendees
and
I'm
not
sure
roy.
Are
you
gonna,
be
able
to
help
with
notes
or
we
can
share,
share
responsibility,
awesome
sure,
yeah
cool.
A
I
appreciate
that
quick
acknowledgement
of
the
code
of
conduct
all
calls
and
all
communication
in
our
repos
is
is
covered
under
code
of
conduct.
We
ask
that
you,
please
read
it,
please
be
respectful
of
each
other
and
when
people
are
talking,
please
raise
your
hand
and
just
be
kind
and
thoughtful
in
these
spaces.
A
A
I
guess
one
from
us:
we've
been
shipping
weekly
and
actually
almost
a
few
times
weekly
patch
releases
to
the
npm
client
so
be
watching
for
usually
tuesdays.
We
are
actually
posting
about
those,
so
the
change
logs
there
you
can
see
what
we're
working
on.
So
we
posted
a
blog
post
yesterday
about
a
few
of
the
releases
that
we
shipped
last
week
and
the
changes
and
expect
more
to
come
this
week.
So
keep
an
eye
out
there.
B
Yeah,
maybe
one
quick
announcement,
maybe
not
announcement,
but
just
worth
noting.
I
did
a
presentation
yesterday
on
a
github
online
meetup
and
I
put
together
a
quick
deck
that
just
demonstrates,
like
the
highlights
of
v7
right,
like
workspaces
peer
dependencies,
all
in
like
just
slides
that
you
can
just
like
kind
of
browse
in
a
minute
or
so
right.
So
if
anyone
is
interested
like
I
put
up
the
link
on
twitter,
maybe
I
can
also
drop
it
in
the
notes
or
something.
A
Yeah-
and
I
would
also
say
yesterday,
we
shipped
and
proved
looking
docs
website,
so
a
big
shout
out
to
our
our
friends
on
the
registry
team.
Also,
I
know
ed
thompson.
Edward
thompson
has
been
working
on
that
who's,
the
product
manager
there
has
been
helping
out
with
that.
So
if
you
check
out
docs.npmjs.com
you'll
see
it
looks
new
and
improved
and
I
think
there's
still
more
changes
to
come
there.
So
that's
another
thing
to
be
mindful
of
awesome.
A
So
if
there's
nothing
else,
let's
jump
into
the
first
item
here,
which
is
rfc
250,
to
provide
possibility
to
reference
the
license
file
from
papiando
yeah
is
papiando
here.
No,
unfortunately
not.
I
know
this
got
generated
pretty
late.
Today
the
agenda
got
generated
late,
so
they
may
not
have
got
pinged
in
time.
C
Well,
I
I
did
have
a
second
to
take
a
look
at
this.
I
think
moving
away
from
moving
away
from
speedix
indicators
in
the
license
field
is
probably
a
non-starter
there's
a
lot
of
tooling.
That
sort
of
depends
on
that,
but
certainly
we
could
add
another
field
to
package.json,
which
has
the
the
license
url
or
something.
C
What
we
could
also
do
is
just
provide
a
way
to
show
a
license
as
a
command,
for
you
know,
given
a
particular
package
name,
it
wouldn't
be
too
hard
to
kind
of
fetch
it
crack
it
open
and
grab
whatever
license
star
file.
We
find
in
there.
A
C
Url
or
license
file
really
license
license.
File
makes
more
sense
than
license
url
because,
yes,
the
reason
being
that,
like
the
license
on
the
latest
and
greatest
version
of
the
code,
might
change,
but
the
license
that
a
particular
thing
is
is
distributed
under
is
the
license.
That's
included
with
it
correct
yeah.
Sorry,.
A
Yeah,
so
that
I
think
that
would
make
sense
to
your
point
like
leaving
the
current
license
field
as
yeah
like
a
spit.
How
did
you
pronounce
that?
Have
you
pronounced
this.
A
Speedix
speed
x,
okay,
there's.
C
A
A
license
is
a
super
dock
you're
right,
so
yeah
the
the
recommendation
of
license
file
and
not
license
url
might
be
interesting
for
us
to
then
I
think
that
would
go
hand
in
hand
with
them
bubbling
up
that
information
in
a
subcommittee
similar
to
like
mpm
fund.
D
D
That's
not
an
argument
against
allowing
it
to
be
configurable,
but
in
that
common
case,
having
a
license
file
field
makes
sense
because
there's
one
license
and
it
points
to
the
file
for
that
one
license.
But
if
there's
dual
licenses
you
presumably
want
to
point
each
license
identifier
to
a
different
file,
and
I
don't
think
anything
would
be
worth
complicating
this.
C
D
D
If
that's
worth
the
tooling
churn,
because
there's
a
lot
of
tools
out
there,
that
expect
the
license
field
to
be
an
array
of
strings.
So
if
we
accept
that
that's
not
worth
the
tooling
churn,
then
the
question
is:
if
we
add
a
new
field,
how
do
we
avoid
duplicating
sources
of
truth
but
also
allow
multiple
files
to
be
specified,
because
it
can
only
specify
the
file
for
like
one
file,
then
I
don't
think
it
makes
any
sense
at
all.
D
Pretty
easily
that's
also
true,
but
that's
also
something
that
is
not
always
preferred
I've.
I've
actually
heard
legal
teams
ask
those
to
be
separated
in
dependencies
at
times.
So,
like
obviously,
that's
gonna
vary
from
lawyer
to
lawyer,
like
everything,
but
it
seems
pretty
critical
that
if
we
add
this
feature
that
we
add
away
to
all
to,
if
the
author
wants
to
support
one
file
per
license.
C
Right,
an
array-
and
I
don't
know
what
that
would
look
like
object
or
something
like
that
yeah
I'm,
I
kind
of
feel
like
we
should
we
should
sort
of
circle
back
to
the
use
case.
Here
I
mean
we
can.
We
can
guess
at
the
use
case
by
the
the
suggested
feature
right,
which
is
that
somebody
wants
to
see
the
license
for
a
particular
thing.
C
That
being
said
like,
if
you're
using
the
speedix
indicator
of
mit
you're
sort
of,
I
think
it's
a
reasonable
assumption
that
it's
going
to
be
an
mit
license.
It's
going
to
grant
you
certain
rights.
Obviously
the
the
source
of
truth
is
actually
going
to
be
the
license
file.
D
D
C
Yeah
and
I
I
really
really
I'm
very
uncomfortable
playing
amateur
lawyer-
you
know,
except
for
strictly
for
entertainment
purposes,
so
I
think
you
know
I
think,
for
this,
like
we
really
need
to
sort
of
circle
back
to
what
the
use
case
is
and
and
make
sure
that
the
right
people
are
sort
of
weighing
in
on
how
best
to
address
that
use
case.
C
In
a
way
that
doesn't
add
I
mean
even
even
the
move
to
speedix
was
like
entirely
non-controv
entirely
controversial
kind
of
it
wasn't
at
least
not
without
controversy
at
the
time,
and
I
know
that
that
an
awful
lot
of
thought
has
kind
of
gone
into
a
lot
of
these
things.
So
it's
you
know
it's!
It's
not
just
tooling
churn.
It's
like
entire
committees
of
lawyers
at
big
companies
who
I'm
not
eager
to
get
on
the
wrong.
D
Side
of
right
well
and
that's
the
thing
about
like,
even
if
we
wanted
to
play
amateur
lawyer,
what
matters
isn't
our
legal
interpretation?
It's
the
aggregate
legal
interpretation
of
like
entities
across
the
ecosystem,
which
isn't
something
we
can
really
like
know
in
advance
of
asking
a
bunch
of
lawyers
right.
E
It's
fine,
no,
it's
good!
I
was
only
going
to
add.
I
think
it
is
reasonable
to
say
no,
you
can
put
it
in
this
one
file,
not
configurable.
You
can
hear
here's
the
file
pattern
and
call
it
a
day
like
to
be
honest
there.
It
doesn't
need
to
be
a
super.
Complicated
thing
like
github
looks
in
like
two
or
three
spots
right
and
that's
what
it
displays
on
its
page
and
you
don't
get
a
choice.
E
You
just
get
where
it
goes,
and
I
think
it's
fine
for
everybody
to
do
that,
and
then
that
also
doesn't
get
into
any
real
conversation
about
the
legal
side,
because
it's
like
look.
This
is
just
what
the
tool
does
the
the
legal
side
of
it
has
nothing
to
do
with
it.
If
you
want
to
see
the
license
and
you
type
npm
show
license
like
it,
looks
at
license
and
license.md
all
caps
and
like
done.
C
C
D
D
A
Yeah
so
again,
I'm
going
I'm
going
to
go
back
with
isaac
as
as
well
like.
Let's
maybe
give
the
feedback
to
this
this
or
ask
exactly
what
they're
looking
for.
If
we
want
specific
changes
to
or
npm
license
command,
then
that
sounds
like
it
might
be
different
than
what
what's
specifically
here
yeah.
A
So
maybe
we
try
to
hope.
We
leave
this
on
the
agenda.
I
guess
for
for
next
week
and
let
folks
add
add
comments
async
and
then
also,
if
folks
are
interested
about
something
like
this
or
like
support
for
multiple
license,
then
we
create
a
separate
issue,
for
that
is
that
okay?
Was
there
like
more
that
we
want
to
oh
good
yeah.
That's
worked
for
me
cool.
Then.
Let's
move
on
to
the
second
item,
which
is
217
rfc
ad
registry
per
package
per
organization.
C
Yeah,
so
I
think
wes
I
did.
I
apologize
for
last
time
not
getting
a
chance
to
really
kind
of
understand
what
it
was
you
were
getting
out
here,
but
it
seems
like
the
hazard
that
was
brought
up
of
you
know.
A
company
has
a
mix
of
at
companies,
slash
star
and
company
dash
star
in
their
registry,
hacks
npm
six
will
never
use
a
different
registry
for
anything
that
doesn't
have
a
scope
right,
it'll
always
use
the
whatever
the
top
level
registry
configuration.
C
C
In
that
case,
it's
a
lot
easier
to
prevent
squatting
on
a
scope
than
it
is
squatting
on
every
package.
That
starts
with
your
company's
name
right.
E
E
Yeah
it
is,
it
is
absolutely
way
smaller,
so
so,
if
that
is
what
we
settle
on,
I
think
that
is
probably
acceptable.
That
said,
I
could
go
look
up
the
list,
but
I'm
pretty
sure
I'm
squatting
on
something
like
25
scopes.
Right
now,.
E
I
have
to
I
can't
not
no
there's.
I
have
no
option
right,
like
the
current
situation
is.
I
have
no
option
I
have
to
squat
on
these
or
I
have
to
go,
tell
40
teams
and
2
000
engineers
to
go
modify
code,
and
I
can't
do
that
right.
So,
like
I
mean
I
can't
and
I'm
working
on
it,
don't
get
me
wrong,
we'll
get
there,
but
like
we're
not
there
yet,
and
a
lot
of
organizations
are
probably
in
a
similar
boat.
E
So
this
would
then
mean
that
I
have
to
go
and
tell
them
now
we
have
to
list
all
25
of
those
scopes
in
their,
maybe
not
if
they
want
to
use
this
feature.
No,
okay,
I
guess.
Basically
the
idea
would
be
that
they
just
can't
use
it
to
say
no.
I
want
I
really
do
want
to
get
this
one
from
the
public
registry.
That
is,
that
is
an
unscoped
package
right.
I
guess
that's
the
only
drawback
there
I'm
trying
to
this
is
new
yeah.
So.
E
C
What
you
would
be
able
to
do
you
know
if
we
support
unscoped
packages,
you'd
be
able
to
say
you
know,
npm
installed,
dash,
dash,
I'd,
be
able
to
say,
like
registry
equals,
internal.registry.com
right
and
then
express
colon
registry
equals
registry.npmjs.org.
C
That's
if
we
support
unscoped
packages,
if
we
don't,
what
you
would
still
be
able
to
do
is
set
your
registry
to
your
internal
one,
but
you
know
at
netflix
slash
some
public
thing
I
want
to
get
from.
I
want
to
get
the
open
source
one
right
or
I
want
to
use
the
open
source
registry.
For
that
thing.
E
Yeah,
so
this
would
be
so
the
the
case
here
that
we'd
be
blocking
would
be
if
a
team
has
an
internal
pa
in
a
a
package
they
own,
that
they
publish
to
open
source
that
they
publish
and
has
been
shadowed
or
some
for
some
reason
internally,
but
they
want
to
make
sure
that
they
never
get
the
shadowed
version
like
say:
there's
some
internal
custom
fixes
or
something
that
you
know
only
apply
internally.
They
would
not
be
able
to
say
I
wanna.
E
D
In
other
words,
if
you're,
if
you
can
configure
your
internal
registry,
then
you
can
just
make
everything
go
there
and
it
has
the
rules
for
when
to
hit
the
public
one
and
not
right,
and
that's
what
airbnb
did,
because
that
was
the
only
option
available.
If
we
wanted
to
avoid
that
and
make
the
internal
registry
be,
just
you
know
very
straightforward,
and
it
only
contains
internal
packages
and
only
is
requested
for
internal
packages.
D
The
only
way
to
actually
make
that
possible
with
at
least
airbnb's
configuration
is
if
we
could
support
this
new
feature
on
both
unscoped
and
scope
packages,
because
airbnb
both
has
internal
unscoped
packages
and
public
scoped
packages
so
like
as
far
as
reducing
you
know,
reducing
it
to
just
scoped.
I
think
that's
that
definitely
dramatically
reduces
the
hazard,
although
it
does
not
eliminate
it
because
you
know
it's
entirely
possible
that
some
engineers
will
not
realize
that
they
need
to
squat
on
the
public
scope
and
then
that
creates
that
hazard.
D
But
it
definitely
mitigates
it
and
gives
them
a
solution
and
like
once
they
discover
it.
They
can
ask
npm
to
grab
the
scope.
Perhaps-
and
you
know
I
don't
know-
there's
there's
like
mitigations,
but
I
think
that
anything
that
that
I
think
it's
it's.
It
would
be
much
better
if
we
designed
this
feature
so
that
it
could
not
be
unsafe
ever
even
in
a
contrived
situation
in
like
npm
six,
let's
say,
and
if
we
did
that,
then
it
wouldn't
matter
about
scoped
versus
unscoped.
C
Yeah,
I
don't,
I
don't
see
any
way
that
we
can
add
a
new
feature
that
selects
a
new,
a
different
registry
that
is
only
supported
by
npm
seven
and
doesn't
break
npm
six
and
is
a
hundred
percent
safe
right,
like
that.
That's
sort
of
like.
D
C
Right,
it's
hard
to
break
npm
six
by
adding
new
fields
to
to
package
json
or
to
or
to
the
config,
because
it's
it's
pretty
open-ended
right,
like
any.
Our
config
accepts
anything.
That's
like
valid
ini,
syntax
and
I'm
not
really
willing
to
say
well
we're.
You
know
we're
going
to
start
having
json
configs
instead
of
ini,
configs
or
something
like
that.
B
C
It
will
break
npm6,
that's
that's!
That
would
be
awfully
disruptive
or,
like
you
know,
extending
it's.
It's
an
npm
rc
file
and
we've
always
kind
of
said
that
it's
ionized
syntax.
But
now
we
have
this
new
thing.
You
put
a
you
know,
slash
one
character
in
there
in
order
to
cause
the
the.
C
D
C
Well,
I
mean
so
the
other.
The
other
idea,
this
you
know
where
this
gets
us
back
to
is,
we
add
a
new,
add
a
new
spec
type
right,
like
a
registry,
spec
type
which
specifies
the
registry
and
the
name
app
version.
C
Or
name
at
sumber
range
there
are.
You
know
that
that
could
also
be
handy.
I
kind
of
I
kind
of
ran
into
this
recently
when
we
were
so
we
sort
of
cut
a
corner
in
the
end
in
the
npm
publish
in
v7,
where
now
it
only
publishes
folders
instead
of
taking
any
arbitrary
spec
and
part
of
it
was
like.
C
C
So
there's
something
that's
in
the
public
registry
today
and
you
want
to
install
all
versions
of
it
in
your
private
registry
right,
maybe
you're
like
mirroring
or
doing
something
something
weird
like
that
or
transferring
from
one
private
registry
implementation
to
another
as
another
kind
of
common
use
case.
For
that,
the
the
way
to
do
that
that
would
be
pretty
nice
is
to
say,
like
npm,
publish
and
then
the
spec
that
I'm
getting
the
thing
from
which
is
over
on
registry
a.
C
D
D
When
you
say
spec
you're
talking
about
like
what
would
also
be
called
a
url
protocol
like
git,
colon
and
ftp,
colon
and
stuff,
like
that.
C
Sort
of
when
I
say
spec,
I
I
mean
specifically
the
the
package
specifiers
that
can
be
passed
as
arguments
to
npm
install,
so
a
spec
could
be
either
file
colon
and
some
path.
It
could
be
file
calling
and
some
tarball
it
could
be.
You
know,
github
colon
username,
slash
package
hash
commit
any
any
of.
E
E
So
can
I
can
I
elaborate
one
reason
why
I
really
like
this
yeah
one
of
the
things
that
I've
run
into,
especially
when
everybody
went
remote.
All
of
a
sudden
one
of
the
things
we
got
a
lot
of
complaints
about
was
install
timeouts
and
almost
every
single
one
of
them
was
somebody
doing
an
install
where
the
package
was
doing
nightly
builds,
so
the
pacuments
were
like
drastically
larger
than
most.
You
know
most
other
packages
right,
and
so
it
would
time
out
and
what
I
had
been
thinking
about.
E
Doing
for
a
couple
of
projects
is
publishing
nightlys
to
the
github
package
registry,
which
maybe
this
will
change
in
the
future,
and
those
things
will
start
to
merge.
But
I
was
hoping
to
use
the
github
package
registry
as
a
source
for
nightly,
builds
and
then
publish
the
primary
releases.
Continue
to
the
you
know,
the
npm
public
registry.
E
If
you
did
that
you
could
say
in
a
test
run,
you
know
I'm
I'm
test
running
against
these
three
packages
that
are,
I
want
to
test
against
their
nightlys,
and
so
you
could
say
like
in
my
app.
I
want
to
test
against
the
express
nightly.
That's
actually
on
the
github
package
registry.
E
During
this
install,
I
would
say,
like
npm,
install
registry,
colon
github
package
registry
express
right
which-
and
but
I
want
the
rest
of
the
things
to
come
from
the
normal
public
register.
I
don't
want
to
mess
with
the
github.
You
know
package
and
this
would
go
for
any
any
registry,
but
the
idea
is,
you
could
have
this
sort
of
area
where
you
get
your
nightlys
from
for
specific
packages.
E
If
you
need
to
do
testing
and
the
only
other
way
to
do
that
now,
I
think,
is
to
publish
under
a
diff
a
scope
or
something
and
then
point
the
scope
at
the
nightly.
Or
I
don't
know
you
probably
could
hack
your
way
around
it,
but
this
would
give
sort
of
more
a
more
explicit
way.
C
Well,
the
way
the
way
you
could
do
it
is
npm
install
express
at
npm
colon,
oh
no,
express
at
and
then
the
the
tarball
the
result
tarball
right
right
right
right
to
get
up
back
into
registry,
which
is
which
is
fine,
but
you
know,
then
you
can't
do
things
like
you
know.
You
have
to
pin
to
a
particular
version.
There's
there's
other
kinds
of
drawbacks
to
that.
Yeah.
E
Like
the
nice
thing
would
be
you'd
be
able
to
use
the
normal
semver
resolution
right.
You
could
just
say
I
want
the.
I
want
the
the
tag.
I
want
a
tag
you
know
of
next
next,
seven
right
and
I
want
it
to
follow
that,
but
I
don't
want
to
like
bloat
the
pacument
by
publishing
nightlys
to
my
real
project
on
the
real
registry
right.
C
It's
just
adding
it's
such
a
heavy
sigh
for
me,
because
the
thought
of
adding
a
spec
just
because
they
a
spectate
because
it's
it's
threaded
through
so
many
different
things,
so
the
the
cost
of
of
implementing
this
feature
did
go
up
considerably.
By
with
that
suggestion,.
A
D
One
other
quick
question
isaac.
Would
it
be
possible
for
npm
publish
to
realize
that
you're
using
a
registry
spec,
and
also
like
you
know,
maybe
error
out
if
you
don't
specify
engines.npm
to
be
the
right
version,
meaning
prevent
people
from
like
public
make
sure
that
if
people
are
going
to
publish
these
specs
that
they
at
least
have
you
know
declared
that
they
require
that
version
of
npm.
D
C
So
the
as
far
as
things
that
are
going
to
be
in
a
dependency-
that's
that's
published
to
the
registry
right.
So,
if
you
have
a,
if
you
have
a
dependency
with
a
registry,
specifier
yeah,
we
could
we
could
throw
an
engines.npm
in
there
in
the
thing
that
we
actually
publish
pretty
easily
the
and
that
will
prevent
npm.
Six
from
installing
that
version,
which
is
great,
which
is
great.
The
thing
that
doesn't
work
for,
unfortunately,
is
the
top-level
app.
C
If
you
run
npm
install
and
your
root
and
engines.npm
says
you
need
version,
seven,
it's
just
going
to
be
like
yeah.
So
what
well
you're
not.
D
C
Yeah
any
any
any
specifier
that
we
add
or
change
significantly.
We
talked
about
that.
We
talked
about
that
with
the
get
get
repo
path
edition
right
as
well
that
like,
if
we,
if
we
detect
that,
when
we're
publishing
we
should,
we
should
set
engines
npm
right.
It's
a
it's
a
little
bit
of
it's
a
couple
lines
of
extra
code.
That's
only
gonna
be
there
for
like
bookkeeping
purposes
and
eventually.
C
A
It
goes
into
similar
territory
to
published,
prompts
that
we
have
had
in
the
past,
or
I
know
we
were
talking
about
it
like
expanding
the
ignore
list
right
and
then,
where
we
got
to
in
that
discussion
was
essentially
recommending
or
warning
about
certain
things
versus
failing
right.
It's
a
warning
that
potentially
you
haven't,
set
an
entrance
when
we
see
that
spec.
A
Potentially,
we
could
warn
but
again
that
that's
into
the
territory
of
like
a
whole
bunch
of
like
pre-published
checks
that
we
could
be
doing
on
behalf
of
the
community.
So.
D
C
Oh
yeah
we're
getting
a
little
a
little
far
afield
of
the
of
the
original
suggestion.
Here
I
guess
the
question
kind
of
comes
down
to
you
know
if
we,
if
we
limit
it
to
only
scoped
packages,
is
that
does
that
mitigate
the
hazard
enough,
that
we'd
feel
comfortable
implementing.
You
know
separate
registries
for
each
for
individual
package
names
that
are
scoped
and
then
there's
kind
of
a
separate
question,
a
separate
idea,
which
I
very
irresponsibly
just
sort
of
threw
out
here.
C
I
apologize
for
that
about
a
registry
specifier
and
that's
definitely
a
whole
other
rfc.
I
think
some
some
good
ideas
about
that
and
and
good
ideas
for
the
use
cases
sort
of
surrounding
that,
but
it
does
feel
somewhat
orthogonal
to
this,
even
if
they
address
similar.
C
A
E
So
so,
if
the,
if
the
the
only
thing
blocking
it
is
the
security
concern
here,
this,
then
what
if
we
in
npm
7
started
reserving
that
configuration
so
that
we
knew
that
so
that
the
npm
7
could
handle
it.
And
then
we
propose
adding
something
like
this
in
the
future,
in
npm,
8
or
9,
where
we
would
then
have
the
ability
to
you
know
well
ability
it
would
error.
We
would
say
if
this
key
exists.
E
This
is
an
error,
key
style
or
whatever
in
npm
seven,
and
then
you
know
three
years
from
now,
it'd
be
supported
without
you
having
to
add
a
registry
spec
type.
D
C
E
D
And,
given
that
there's
more
use
cases
for
the
registry
spec
like
that
one
solves
this
rfc,
but
also
other
things
like
the
transfer.
You
know
across
registries
use
case,
for
example,
like
I
mean
it
feels
to
me,
like
that's
the
better
path
forward.
D
A
So
can
we
at
least
give
the
feedback
that,
if
we
were
going
to
implement
this,
this
is
how
we
would
have
to
do
it
and
it
would
be
okay.
We
would
start
airing
out
to
reserve
the
that's.
I
yeah.
C
B
A
Sounds
good
also
because
they
weren't
able
to
jump
on.
Let's
try
to
hook
balloran
again
and
maybe
a
little
bit
earlier
for
next
week,
cool
then,
let's
move
on
to
and
also
like
did
we
want
to
queue
up
like
an
action
item,
to
write
that
rfc?
A
A
D
I
mean
it
seems
reasonable
to
me
whether
we
wait
a
week
or
not
to
basically
say
that,
like
these
are
the
only
two
paths
forward.
We
see
to
be
able
to
solve
this
problem
right
because,
like
I
think,
there's
a
sort
of
gray
area
here
right
that
rfcs
are
a
combination
of
a
problem
statement
and
a
solution
suggestion
and
like
if
we're
going
to
say
that
it
requires
a
new
rfc
for
a
different
solution,
then
like
it
might
be
worth
saying
that
the
problem
space
is
valid.
D
C
E
So
in
that
regard
it
feels
to
me
like
the
answer,
is
we
have
one
way
forward
and
it
is
this,
but
it
you
know
it
needs
a
whole
new
rfc.
If
you
want
to
champion
it
go
ahead,
because
I
just
don't
see
preventing
that
presenting
them
with
two
options
and
one
of
them
being
something,
we've
basically
said
no,
like
probably
not
super
productive.
Well,.
C
E
Right
jordan's
saying
that
wouldn't
have
solved
their
problem
at
airbnb
and
and
now
that
I'm
thinking
about
it
that
my
my
concern
was
somebody
we
don't
have
that
problem.
But
my
concern
was
that
somebody
would
use
it
thinking,
they're
solving
some
problem
and
then
it
would
cause
a
security
hole.
So,
to
be
honest,
like
yeah,
that
might
mitigate
some
of
my
problem.
But
then
all
they'd
have
to
do
is
use
it
for
a
scope
package
and
be
back
in
the
same
boat.
A
Know
I
think
I'm
going
to
unbox
this.
C
C
Let's
see
if
that
will
solve
their
problem,
because
I
mean
the
thing
that
they
were
originally
bringing
up
was.
I
want
to
set
this
scope
to
an
internal
registry,
but
except
for
this
one
package
within
that
scope,
so
it
sounds
like
limiting
its
scope
packages,
at
least
for
the
the
poster.
There
is
fine
and
it's
kind
of
it's
like
when
they
do
have
a
scope.
That's
in
both
places.
A
Okay,
if
you
can
follow
up
and
add
comments
there,
that'd
be
great.
I'm.
C
Certainly,
I
I'm
comfortable
doing
this
as
written,
but
just
for
scope
packages.
You
know
it's.
It's
opt-in,
it's
it's
not
going
to
end
up
in
a
situation
where
you
have
like
nearly
as
high
a
likelihood
of
of
the
kinds
of
hazards
brought
up
like
it's,
not
100
safe,
but
neither
is
anything
else
we
do
now.
There's
running
software
on
your
machine,
yeah
exactly
like.
So
it's
it's,
it's
a
very
small
amount
of
unsafe.
It's
acceptable.
A
Cool,
so
let's
move
on,
if
you
can
give,
I
think
you
already
saw
that
you
were
posting
there
isaac,
but
just
summarize
yeah.
A
There
yeah
so
the
last
rfc
that
we
actually
have
on
here
is
138.
at
configurable
data
to
hp
the
header.
So
this
is,
I
believe
this
is
mark.
That's
been
queuing
this
up
and
keeping
this
going
or
sorry
makita,
who,
I
think,
has
passed
it
off
to
mark
yeah
yeah,
that's
right
and
I
don't
think,
there's
been
any
update.
C
Yeah
there
hasn't
been,
I've
been
been
busy
fixing
other
npf7
bugs,
but
no
I
mean
I.
This
still
seems
to
me
perfectly
reasonable.
We
just
add
a
headers
blob
header
section
in
your
in
your
npm
npmrc
and
it
will
just
work
and
I
think
it
pretty
much
just
works
today.
A
C
The
ioni
syntax
is
a
slight
adjustment.
We
can.
We
can
have
a
separate
as
we
discussed
last
week.
We
can
have
a
separate
conversation
about
how
to
specify
key
value
pairs
on
the
cli,
which
we
don't
currently
have
a
way
to
do.
But
you
know
again,
like
that's,
that's
sort
of
an
orthogonal
question
and
similarly
in
the
environment,.
A
Cool,
I
know
roy
added
a
few
discussion
topics
that
we
haven't
addressed
in
a
while,
as
most
of
our
discussions,
probably
going
to
be
moving
into
sort
of
the
feedback
repo
that
we've
opened
recently,
which
one,
I
think
live
this
this
past
week
or
the
week
before,
and
so
the
first
item
that
is
on
here
is
228,
so
mpmls
by
scope.
B
D
Yeah
the
another
ques
so
a
long
time
ago,
many
years
there
was
talk
from
npm
people
about
some
sort
of
curating
feature
where
people
would
be
able
to
make
lists
of
packages,
and
it
was
sort
of
like
like
that
awesome
list.
Repo
trend,
that's
been
starting
to
float
around
well.
I
think
it
would
be
great
to
be
able
to
to
list
scopes
right,
like
I
have
scopes
that
group
packages.
For
that
reason,
but
I'm
wondering
is:
is
that
creation
thing
just
dead
or
like?
C
It
jordan,
this
is,
this-
is
just
using
the
npmls
command
like
within.
B
D
D
C
It
useful,
if
we're
doing
it
right
right,
what
is
the
selection
and
and
more
generally
like
what
should
sort
of
be
the
selection
syntax
for
packages
within
the
tree.
This
would
also
be
handy
for,
like
npm,
outdated
or
npm
update.
You
know
I
might
want
to
update
all
of
the
all
of
the
things
that
contain
typescript
in
the
name,
not
just
the
typescript
package
right.
D
D
C
Yeah
yeah
yeah,
so
the
one
thing,
the
one,
the
bigger
downside
that
you
know,
apart
from
apart
from
just
my
own
sort
of
like
eyes,
crossing
it
seeing
css
on
a
command
line,
the
kind
of
rational
objection
there
is
that
it
it
will
require
that
users
have
an
understanding
of
their
package
tree
that
they
might
not.
We
might
not
want
to
expect
of
them,
so
you
know
like
it.
C
C
Right
so
I
I
think,
there's
also
a
discussion
we
had
about.
You
know
we
currently
show
sort
of
this.
This
tree-ified
version
of
the
logical
dependency
graph
right
with
with
just
the
words
deduped
when
a
node
gets
shown
multiple
times.
C
It's
it's
challenging
to
go
from
that
to
like
what
is
the
physical
structure
on
disk
or
even
what
things
need
to
be
updated.
So
I
I'm
yeah,
I
I
don't
feel
like
css
is
the
best
fit
just
because
it's
it's
a
it's
more
ideal
for
a
case
where
the
person
who's
writing.
The
css
selector
has
is
expected
to
have
some
understanding
of
the
the
tree
that
they're
selecting
on
right.
C
B
C
E
So
let
me
just
say,
though,
wouldn't
this
be
an
exploratory
tool
anyway,
so
you
don't
actually
need
to
know
what
you're
trying
to
answer
is.
What
is
the
structures
right
when
you're
using
this?
So
you
would
be
saying
I
want
to
know
what
are
all
the
direct
dependencies
of
react
in
my
project
and
so
you'd
say
like
react,
carrot
or
well
not
carrot
right.
Is
that
that's
greater.
E
Greater
than
took
me
a
second
there
greater
than
star,
and
that
would
be
find
me
all
packages
that
are
directly
descended
from
from
react.
If
you
wanted
to
say,
I
want
to
find
all
things
that
are
directly
descended
from
anything
but
adjacent
to
right,
like
so
that
the
idea
here
is
what
you're
doing
is
exploring
the
tree,
so
you
can
learn
more
about
it,
not
necessarily
starting
with
knowledge
right,
yeah.
B
I
would
say
it
should
be
almost
of
a
subset
of
or
an
extension
of
those
pack
syntax
right,
so
we
have
that
we
support
like
this.
The
regular
npm
package
arguments
pack
specifier,
but
extend
that
with
more
capabilities.
D
In
order
to
provide
this
sort
of
functionality,
we
have
to
come
up
with
a
dsl
and
the
semantics
for
it,
so,
whether
we
use
css
or
not
right,
we
have
to
create
and
define
ways
to
do
the
things
css
already
does
that's
why
I
suggested
it
but
like
either
way
we
have
to
be
able
to
say,
like
I
want
the
directed
pennies,
the
direct
depths
of
react,
and
I
want
to
search
within
them
like
I
don't
I
want
to
list
them
all
or
I
want
to
show
me
all
of
the
direct
dependencies
of
react.
D
C
It's
useful
that
stuff
would
be
useful
and
wes.
That's
a
good
point.
It
is
kind
of
exploratory.
The
other
hazard
is
that,
like
roy
kind
of
touched
on,
we
support
npm
ls.
You
know
glob
at
five
to
show
me
all
versions
of
all
instances
of
glob
at
version
5.x
anywhere
within
the
tree.
C
D
I'm,
like,
I
think,
there's
like
two
action
items
that
I
see
here
right.
One
is
maybe
we
should
write
a
fuller
someone.
Someone
should
write
an
rfc
that
talks
about
some
sort
of
way
to
explore
the
package
tree
in
the
ways
we've
discussed,
but
I
think
regardless
npls
npm
ls
at
npm
cli,
for
example,
should
just
work
because
it's
exactly
what
everyone
would
expect
like.
A
Yeah,
so
just
be
mindful,
this
was
a
discussion
topic
so
feel
free
to
definitely
like.
We
can
add
a
lot
of
this
context
back
in
into
that
discussion
and
then
again,
I
think
in
the
future
a
lot
of
these
items
are
going
to
actually
move
into
sort
of
that
feedback.
A
Space
going
forward,
so
just
be
mindful
that
this
may
change
like
like
some
of
these
discussions
might
move
there.
C
I
do
I
do
want
to
make
sure
that,
like
whatever
kind
of
selection
syntax
for
packages
within
the
tree
that
we
land
on
I
wanted
to,
I
wanted
to
be
something
that
will
also
work
with
npm
update
or
npm,
outdated
or
npm
fund,
or
any
of
the
other
things
where
you
know
we
take
a
a
package
or
a
specifier
as
our
set
of
package
names
as
arguments
yeah,
you
want
some
consistency
across
yeah
yeah
agreed
right
now
it
is
consistent,
it's
just.
It
can
only
be
name
at
spec.
The
output
is
not
consistent.
A
Overlapping
there's
no
reason
why
we
couldn't
be
carving
out,
like
one
standard
view
that
just
is
filtered
based
on
those
things
right:
yep,
okay,
so
moving
on.
Let's
we've
only
got
about
five
minutes
left
here,
the
other
there's
another
three
discussions
that
were
linked,
the
next
one
up
was
260
or
sorry,
four
that
were
linked;
266.,
add
phone
level
info
to
audit
fix
output.
A
So
again,
that's
discussion.
266.
B
You
can
scroll
quickly
if
you
want
super
super
simple
one.
Maybe
you
can
just
turn
it
into
an
item
in
the
backlog,
but
it's
basically
the
proposal
is
to
add
same
as
we
have
the
level
of
each
vulnerability
like
at
the
end
of
just
the
install
just
add
that
to
the
result
of
npm
audit
fix,
I
guess
already
on
my
audit.
One
of
these.
A
Very
simple:
that's
a
good
comment,
but
yeah.
This
is
definitely
something
we
could
take
because
eq
is
like,
I
guess,
backlog
feature
and
somebody
can
pick
it
up
if
they
would
like.
Then
the
other
discussion
was
226,
bring
back
pre-update
and
post
update
again
roy,
I'm
not
sure.
If
you've
looked
at
this
already.
C
A
It
sounds
like
the
action
item
for
those
two
discussions
is
to
actually
queue
up
a
backlog,
ticket
yeah.
A
A
B
A
A
I
I
didn't
say
it
would
sit
in
the
backlog.
Roy
said
it.
A
With
love
pr
from
the
community
to
cue
this
up
by
backlogging,
I
just
mean
we'll
make
sure
that
there's
an
actual
ticket
somewhere
beyond
yeah
beyond
just
this
discussion
right
so
doesn't
mean
it's.
It's
gonna
go
gather
a
ton
of
dust,
hopefully,
okay,
very
last
one
if
we
can
get
to
it.
That
was
queued
up
here,
so
discussion
246
a
prompt
when
adding
recently
published
so
again.
Well,
I'm
not
sure
if
you
had
a
chance
to
look
at.
B
So
basically
it
would
be
a
prompt,
but
so
basically
like
they're,
proposing
a
solution
but
like
we
can
do
the
exercise
of
coming
back
to
the
actual
problem
right
and
I
think,
if
the
actual
problem
they
state
is
a
very
good
one.
So
yeah,
that's
so
what's
where
my
mind
was
going,
and
I
added
this
to
the
discussion
yeah,
I'm.
E
Also
a
big
thumbs
up
on
this
if
it
allows
you
to
slowly
ease
the
restrictions
on
the
registry
side
about
naming
collision
or
naming
closeness
is
maybe
the
better
term,
because
that
has
been
me
so
many
times
now.
You
know
that
it
would
be
great
if
you
could
start
like
letting
things
be
cl
more
and
more
similar
and
just
be
warning
on
install
instead.
A
Yeah,
so
I
know
lyran
has
commented
here
about
mpq
so
that
his
tool
that
tool
specifically
allows
for
for
configuration
to
to
check
for
these
types
of
things
for
like
around
npm,
install
so
like
length
of
package
or
like
a
whole
bunch
of
factors.
I
forget
all
of
them,
but
yeah
again.
This
is
something
probably
that's
going
to
take
more
time
to
flush
out
what
we
would
actually
want
to
do
here.
A
So
maybe
we
just
keep
this
on
on
the
agenda
for
next
week,
because
I
know
we're
at
time.
So
if
anybody
has
any
thoughts,
feel
free
to
add
them
to
that
discussion,
cool
apologize,
we
ran
a
little
bit
over
and
got
started
a
little
bit
late,
we'll
try
to
again
ensure
that
we
can
get
the
agenda
open
up
a
bit
earlier
if
we
can
next
week
and
appreciate
everybody
jumping
on
again.
So
hopefully
you
see
you
next
wednesday
ciao
bye.