►
From YouTube: Open RFC Meeting - Wednesday, April 29th 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we're piloting an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
Awesome
and
we're
live,
welcome
everybody
again
to
another
open
RFC
call
today
is
Wednesday
April
29th
again
we'll
be
following
along
the
agenda.
First
appear
in
chat
and
you
can
usually
find
the
agenda.
We
do
our
best
to
get
it
out
before
this
call.
I
know
I've
been
you
know,
late
most
days,
I
think
I
got
generated
yesterday,
so
apologize
for
that,
but
you
can
be
following
along
with
these
meetings.
In
our
public
events
calendar
the
link
can
be
found
in
the
actual
RFC
issue.
Issue.
A
134
again
feel
free
to
add
yourselves
as
attendees
to
the
me
notes.
Doc
spamming
that
link
cloudy
is
again
create
to-do
notes,
so
appreciate
that
and
I'll
take
notes
when
she
gets
to
her
RC
quick
housekeeping
just
wanted
to
remind
everybody
that
these
calls
and
any
communication
in
our
repos
is
covered
by
MPs
Code
of
Conduct.
A
So
we
just
asked
that
Brady
be
mindful
and
thoughtful
when
speaking
and
laying
other
people
speak
as
well,
and
it
is
tradition
just
to
raise
your
hand
if
you
want
to
comment
on
a
topic
and
yeah
just
if
you're
looking
for
the
actual
full
code
of
conduct,
we
have
it
look
they're
linked
in
the
repo
which
can
be
found
at
NPM,
/
rfcs,
on
gale,
calm
and
again.
These
calls
the
desired
outcome.
B
A
C
A
D
Yeah
yeah
definitely
so
yeah.
This
is
pretty
much
the
leftover
from
the
original
workspaces
RFC.
So
what
you
want
to
do
here
is
standardizing,
like
the
set
of
commands
that
we'll
be
able
to
run
across
all
the
workspaces,
so
it's
kind
of
like
desired
outcome
to
be
able
to
just
p.m.
install,
and
then
you
get
all
the
workspaces
installed
and
also
like
you
can
run
completed,
commands
like
tasks,
so
you
can
NPM
test
and
have
test
run
across
all
the
nested
workspaces
but
yeah.
But
there's
a
few
commands
already
sourcing
that
we're
gonna
work
there.
D
D
Basically,
we
identify
a
subset
of
commands
that
we
definitely
want
to
support
that
are
relevant
to
the
context
of
workspaces
and
the
idea
of
being
able
to
filter
subsets
of
workspaces.
So
basically
we
could
add
a
command
like
NPM
SS.
Then
you
can
define
a
name
of
one
of
your
nasod
workspaces
and
have
a
command
render
and,
along
with
that,
I
also
identified
a
potential
idea
to
create
like
Elias.
So
you
could
basically
like
create
groups
of
workspaces.
D
You
have
internally
so
like
the
example
that
your
don't
say
like
let's
say
you
have
a
group
of
workspaces
that
you
you
come
only
like
they're
commonly
used
together,
let's
say,
example,
something
there,
maybe
located
in
a
specific
place.
So
you
could
define
like
this.
Like
you
have
a
group
of
workspaces,
so
they're
you
can
run
any
command.
D
E
So,
on
the
the
one
for
filtering
like?
Is
there
a
reason
not
to
like
follow
kind
of
learners
pattern
of
scope,
which
is
that
you,
this
command
is
identical,
except
that,
if
you
want
it
to
run
on
a
subset
of
workspaces,
you
pass
an
argument
with
a
glob
and
then
that
glob
runs
against
your.
We
know
with
your
workspace
settings
against
everything.
D
D
E
I
guess
what
I
mean
is
the
first
of
all
workspace,
vs
WS.
Those
seems
like
aliases
of
the
same
command
not
like.
They
should
do
different
things.
So
if
it's
going
to
be
a
separate
top-level
command,
I
feel
like
it
would
be
important
that
it
be
something
that
has
an
intuitive
name
that
conveys
what
it
does
and
I'd
be
surprised
if
that
intuitive
name
was
shorter
than
typing
and
then
something
like
filter
and
equals,
and.
D
E
That's
really,
but
that
seems
to
be
really
the
the
trade-off
between
the
two
is.
Do
you
type
the
standard
thing
like
NPM
workspace?
Something
equals
your
filter
or
Utah
type.
Npm
workspace,
filter
space,
your
filter
right,
like
like
I'm
sure
we
could
jump
through
some
hoops
to
find
a
way
to
make
either
one
of
them
shorter
than
the
other
one.
But
if
we're
going
for
an
intuitive
nice
long
name
where
they,
where
each
form
maybe
has
some
nice
comfortable
aliases
that
are
shorter,
like
npm,
install
and
PMI
right,
then
I.
E
E
And
it
you
could
have
a
long
and
a
short
version
of
the
filter,
parameter
name
and
have
a
long
and
a
short
version
of
the
top-level
command
name.
So
it's
NPM
workspace
package
scope,
equals
foo
or
something
could
be
the
long
one,
and
then
you
can
do
NPM,
WS,
P,
foo
right
and
that
also
mirrors
kind
of
npx
in
a
way.
So
everyone
kind
of
understands
a
little
bit
what
that
would
mean
and
then,
like
I,
don't
know
just
doing
that
out.
There.
A
E
D
A
B
B
B
Yeah
just
because
like
to
me,
if
I
had
seen
sorry
trunk,
of
course
right
when
I
start
to
talk,
I
had
seen
had
I
seen
that
conversation,
it
might
make
more
sense
to
me
why
we're
here
where
we're
at
because
I
jumped
a
little
like
and
I
mentioned
this
in
the
in
the
one
comment
I
left,
which
is
like
this
seemed
a
little
bit
weird
to
me
when
there's
other
ways
to
do
that,
but
I
think
had
I
seen.
Oh,
we
looked
at
what
that
scope
did
and
we
were
trying
to
replicate
it.
E
In
either
whatever
decisions
made
in
the
future,
when
everybody
inevitably
says
well,
why
the
hell?
Didn't
you
just
implement
it
this
way,
this
document
should
answer
that
question
so
like
it,
you
know
just
good
to
flesh
it
out,
but
but
yeah
I
guess
so
I,
regardless
of
the
bike
shedding
about
what
the
command
and
aliases
names
are
and
what
the
parameter
name
is
and
stuff
like.
We
can
paint
that
later,
but
the
I
feel
like
it's
useful
to
explore
whether
the
filter
should
be
just
an
implicit
positional
argument
like
in
JavaScript
terms.
G
Just
a
quick
check,
so
what
we're
make
sure
I'm
on
the
same
page
here
where
we're?
What
we're
bike
shedding
right
now
is.
Are
you
doing
npm
WS
name
of
workspace
command,
or
are
you
doing
npm
WS
command
with
a
config
argument,
the
config
option
that
sets
what
workspace
you're
talking
about?
That's
the
yes!
Yes,.
C
A
G
I
could
not
possibly
have
less
of
an
opinion
about
this
I
think
I
think
the
only
I
mean
if
methought
like
if
I
have
if
I
was
forced.
It,
like
you,
know,
gun
to
my
head
to
make
a
decision
on
this.
One
personally
I
would
say
like
let's
either
copy
whatever
yarn
and
learn
ado.
If
they
do
the
same
thing,
then
that's
all
the
more
like.
That's
extremely
compelling,
like
that's
obviously,.
A
G
Paved
path
right
or
wrong,
the
other,
the
other
small
consideration
is,
is
that
config
flags
and
config
options
that
we
pass
in
the
CLI
are
also
config
values
that
can
be
in
an
NPM
RC
file
and
that
so
that's
good
of
them.
That
could
be
either
positive
or
negative.
The
the
positive
of
it
is
it
gives
you
a
little
bit
more
flexibility.
You
could
specify
what
workspace
to
operate
on
by
you
know
by
putting
that
in
the
environment
or
somewhere
else.
G
On
the
other
hand,
you
could
end
up
in
a
situation
where
you
know
I'm
I'm,
trying
to
run
commands
against
one
workspace,
but
I
have
this
config
file
way
over
here.
That's
setting
it
to
go
to
a
different
one,
so
configs
are
sort
of
more
ought
to
be
more
broadly
understood
than
just
within
the
scope
of
a
single
command
in.
In
most
cases,
they
should
be
something
that
you
could
at
least
conceivably
want
to
put
it
in
our
C
file.
Now
it's
not
the
case
for
everything.
G
Prefix
is
a
great
example,
and
prefix
is
suitably
weird
that
you
know
when
we
shifted
from
in
NPM
zero
dot,
X
days
from
everything
being
a
global
package
to
defaulting
to
local
packages.
Prefix
was
kind
of
got
weird
and
it's
always
been
a
little
weird
ever
since
so,
if
you
specify
it
on
the
CLI,
then
it
applies
to
the
local
target.
But
what's
in
the
config
is
always
just
said,
it's
the
global
target
and
we
have
to
do
a
bunch
of
hoop
jumping,
so
I
wouldn't
want
to
get
ourselves
into
a
situation
like
that.
G
G
E
G
G
G
G
So
if
I'm
running
something
against
a
single
package
and
then
something
in
that
package
runs
a
script
like
maybe
NPM
test
runs,
you
know
some
other
NPM
command,
and
now
it
is
getting
that
config
sort
of
inherited,
and
so
that's
kind
of
the
hazard,
whereas
with
with
forests
like
if
I
want
to
do
something
with
dash
F
I
want
force
to
be
set
everywhere
in
every
subsequent
NPM
command.
That
could
be
done.
G
That's
the
point,
but
yeah
and
I
mean
also
with
like
OTP,
is
another
good
example
that
you'd
never
want
to
put
a
ap
in
your
in
your
config
file
like
because
it's
not
going
to
be
valid
after
90
seconds.
But
if
what
I
do
want
to
be
able
to
do
is
do
like
NPM
run,
release
dash
dash
OTP
equals
my
TOTP
code
and
then,
when
NPM
run,
release
actually
calls
NPM
publish.
It's
already
got
that
so
I
don't
have
to
Android
a
second
time.
G
A
E
Foo,
for
example,
where
it's
not
a
config
flag,
so
it
bypasses
that
rule
but
I'm
not
really
focused
on
the
implementation
or
the
implementation
consequences,
as
you
are
in
this
case,
I'm.
More
thinking
about
the
usability
of
certainly
of
typing
in
the
command,
but,
more
importantly,
the
usability
of
looking
at
a
command
that
someone
else
has
written
and
knowing
what
it
does
without
having
to
run
it.
So.
G
G
G
E
Think
it
depends
on
the
command
type
for
install
they'll
almost
never
want
to
filter
for
tests.
They
will
probably
not
want
to
filter,
but
for
lint
well
for
tests
or
lint.
If
they're
making
changes
to
one
project,
they
would
want
the
filter
and
if
the
error,
but
if
they're
making
changes
to
dependencies
or
configuration,
they
would
not
want
the
filter.
I
think
they're,
both
pretty
common.
E
A
C
A
F
C
B
Wanted
to
point
out
that
one
thing
that's
interesting
here
is
that
filtering
to
a
subset
of
workspaces
is
very
similar
to
defining
an
alias
and
then
using
the
alias
right.
So
if
we're,
if
we
look
at
2,
&
3
here,
I
really
like
3,
because
I
think
that
aligns
well
with
how
people
think
about
their
code
right.
B
Think
is
a
really
nice
feature
and
it
ends
up
being.
Basically,
the
exact
same
thing
is
saying:
well,
I
want
an
alias
I
want
to
be
able
to
filter
by
you,
know,
slash
packages
and
slash
my
packages,
and
you
know
slash
this
other
directory
star
right,
which
is
really
the
same
thing.
It's
just
less
arbitrary
because
you
actually
have
to
put
it
in
the
package
Jason,
so
I
think
we
should
look
at
like
how
those
two
features
would
interplay
and
what
like
real
use
cases.
B
We
want
to
unlock
here
right,
because
I
think
that
there
might
be
a
way
that
you
could
like
make
do
the
first
one,
the
subset
with
the
aliasing,
if
you
could
maybe
make
it
like
some
sort
of
arbitrary
define,
a
alias
or
a
grouping.
Rather,
you
know
on
the
command
line
as
well
right,
we
might
be
able.
D
B
D
G
B
And
I
think
that
I
think
that
it
might
end
up
working
out
that
we
had
two
distinct
and
almost
100%
covering
use
cases.
One
is
we
have
a
static
set
of
groupings
and
the
other
one
is
I
want
to
run
it
against
one
single
package
right
so
I
think
if
we
do
that,
then
it
makes
this
a
lot
simpler
because
it's
you
know
running
from
the
top
level,
but
one
package
or
running
from
the
top
level
and
running
an
alias
and
that
would
actually
simplify
I.
B
B
D
Yeah
and
I
think
it
also
yeah
this
something
that
or
to
remind
me,
like
I,
definitely
took
this
from
yarn.
Do
one
implementation,
so
that's
that
was
the
way
yarn
open
it
and
learn.
I
was
doing
the
scope,
so
I
kind
of
switched
between
them
when
I
opened.
These
are
see
over
here.
So
there's
definitely
worth.
E
A
A
Cool
just
move
things
along
if
there's
any
other
conversation
folks
when
I
have
feel
free
to
add
to
and
comment
on
the
RFC
itself,
but
moving
along,
we
just
I
want
to
quickly
touch
on
the
overrides
RC
I
know:
we've
done
to
keep
the
eyes
on
that.
Just
want
give
Isaac
a
you
know
a
second
here
to
maybe
give
an
update
on
I'm
worried
about
that
yeah.
G
G
If
you
want
to
apply
an
override
to
that
node
as
well
as
overriding
its
sub
dependencies,
then
you
add
a
dot
member
in
that
object
and
that
sort
of
applies
to
the
thing
that
the
object
matched
against
the
further
restriction
that
the
dot
member
cannot
be
an
object.
So
we
don't
get
into
like
really
weird
nightmare
scenarios.
G
It's
just
a
literal
period,
there's
no
like
dot
@foo,
so
I
think
I.
Think
with
that
I
actually
have
everything
I
need
to
finish
the
finish,
the
RFC
and
I'm
glad
we
got
there
before
before
I'd
gone
too
much
further
through
the
implementation
section,
but
it
should
be
relatively
straightforward
and
simplifies
a
lot
of
the
a
lot
of
the
harder
cases
now
that
we're
back
to
you
know
only
like
first
first
hit
wins
and
nothing
else
will
be
applied.
G
So
if
you
do
have
things
where
I'm
overriding
you
know,
Fuat
too
and
I
have
another
override
for
Fuat
2x.
That
second
one
is
just
irrelevant:
cuz
it'll
never
hit
something
that
wasn't
hit
by
the
first
one.
I
don't
have
to
worry
about,
like
you
know,
hitting
one
and
then
rechecking
and
rechecking.
So
that's
about
it!
It's
pending
pending
me
writing
some
English
words
sounds.
A
A
A
B
C
B
B
G
The
so
the
core,
the
core
issue
that
I
think
has
been,
has
been
driving
a
lot
of
attention
on
this,
and
a
lot
of
the
desire
for
this
is
the
fact
that
choke
Adar
is
extremely
widely
used
and
choke.
It
are
tries
to
install
FS
events
on
non
OS
X
systems,
which
then
blow
up
with
a
whole
bunch
of
build
errors,
which
are
then
ignored,
and
it's
like
it's,
this
perfect
storm
of
terrible
UX
a
like.
If
you
have
build
errors
in
it's
an
optional
dependency,
we
should
just
not
trouble
the
user
with
that.
G
So
that's
happening
in
NPM
v7b.
If
it's
an
optional
dependency
and
it
specifies
an
OS
that
it
works
on
and
you're,
not
on
that
OS,
we
shouldn't
even
try
like
skip
it,
don't
even
waste
time
downloading
it.
So
that's
also
happening
in
npm,
v7
and
so,
and
these
these
features
are
both
already
in
arborist
and
I
suspect
that
a
lot
of
the
a
lot
of
a
call
for
optional
depths
that
are
not
installed
by
default
or
don't
try
to
install
the
optional
depths
of
a
thing
on
depending
on
will
actually
be.
G
There
will
actually
a
lot
less
call
for
it
once
NPM
seven
gets
out
in
the
wild.
The
the
other
thing
that
is
a
little
bit
interesting
is,
and
the
use
case
that
I
know
Cory
Farrell
it
brought
up
is
the
idea
where
you
have
the
situation
where
I
have
an
optional
dependency
that
provides
polyfills,
and
if
you
don't
need
these
polyfills,
then
you
shouldn't
have
to
bother
with
them
right
like.
If
you
know,
you're
running
on
a
modern
OS
platform,
then
we're
only
in
modern
browsers
or
whatever
only
on
node.
G
However,
if
the
optional
DEP
is
there,
then
we'll
try
to
use
it,
and
in
that
case
you
do
want
to
restrict
what
version
of
the
optional
dependency
you're
you're
able
to
work
with,
because
the
the
thinking
there
being
like
look
if
I
try
to
load
this
polyfill
package
and
it's
the
wrong
version,
then
my
whole
thing
is
gonna
blow
up
so
I
have
it
listed
as
an
optional
dependency,
so
I
don't
get
the
wrong
one,
but
I
actually
don't
need
it
at
all.
Most
of
the
time,
and
if
it's
just
missing,
then
that's
fine.
G
So
we
had
talked
about
this
a
little
bit
in
the
context
of
the
accept
dependencies
RFC
where
perhaps
one
of
the
one
of
the
accept
dependencies
that
you
could
specify
for
a
given
dependency
would
be
null,
and
that
would
be
basically
a
way
of
saying:
I
need
to
get
version,
1,
dot,
X,
but
also,
if
it's
completely
missing.
That's
fine.
A
E
It
means
in
general,
with
polyfills
they're
with
engines.
You
usually
say
this
version
and
later
is
what
I
work
with
polyfills
you?
Don't
you
work
with
the
new
versions?
So
there's?
No,
you
usually
don't
say:
I
am
needed
on
these
versions
and
I'm,
but
I
work
on
these
versions.
You
just
say
oh
I
work
on
node,
4,
plus
or
whatever,
but
like
even
if
I'm
only
needed
until
node
6.
So
like.
Would
this
be
a
new
package
JSON
field
for
these
polyfill
packages
to
define
the
maximum
version
that
they're
needed
for.
G
G
D
B
Going
really
complicated
here
for
like
trying
to
solve
for
case
where
the
end
result
is
the
package
user
needs
to
just
say:
I
want
to
install
this
and
they
install
it
at
the
top
level
and
problems
done
right
like
if
they
need
it
because
they're
running
on
an
old
node
version
or
it's
a
browser
polyfill
like
right.
They
seem
to
know
that
their.
G
G
G
If
you
don't
have
glob
installed,
that's
fine,
but
if
you
just
npm
install
rim,
ref
you're
going
to
get
glob
along
with
it.
Now,
if
you
have,
let's
say
we
do
a
breaking
change
to
node
glob
and
it
changes
the
API
in
such
a
way
that
it
will
no
longer
work
with
rim
Raph.
If
I
install
that
new
version
of
glob
with
rim
Raph,
it's
not
okay,
for
it
to
be
a
different
version
right,
so
that
will
be
considered
a
error
in
the
dependency
graph.
G
What
this
proposal
would
be
talking
about
is
saying:
I
want
to
install
I
want
rim
Raph
to
to
install
by
default.
Without
glob
support,
if
you
want
glob
support,
then
you
can
install
glob
along
with
it,
but
it
has
to
be
version
X
in
order
to
function
properly.
I
think
yes,
I,
think
that
you're
right
that
this
is
probably
enough
of
an
edge
case
that
we
could
just
kind
of
punt
it
for
a
few.
E
G
G
It's
it's
a
declared
dependency.
The
the
only
solution
for
it
right
now
is
for
this
kind
of
behavior.
If
that's,
what
you
want
is
to
declare
it,
as
is
to
not
declare
it
as
a
dependency,
which
means
you
might
get
the
wrong
version
as
well
and
on
on
PN
p.m.
or
yarn
v2.
You
just
don't
get
it
at
all
ever
so.
G
E
G
A
G
G
B
I
was
just
gonna
say
one
other
thing
we
are
you
know
talking
about
here
is
these
are
all
problems
that
are
on
maintainer
of
packages
to
solve
and
I'm
actually
I.
Think
it's
pretty
fine
to
say
like
look
if
you're
in
this
situation,
we're
specifically
architecting
your
package
with
this
requirement.
Here
are
other
ways
you
can
solve
this,
that
have
a
good
user
experience
and
we
know
that
there's
certainly
ways
that
just
don't
if
we
just
document
some
of
the
ways
that
work
fairly
well,
you
know
wrap
your
thing.
B
It
like
wrap
it
in
a
try-catch,
your
requires
in
a
try-catch
and
like
you're
fine.
Maybe
he
doesn't
work
with
the
SM
or
whatever,
but
like
that's
just
the
requirement
you
have
in
the
case
of
being
choked
are-
and
you
want
to.
You
know,
not
declare
this
dependency
or
declare
it
and
have
the
R
and
V
to
work
like
we
just
have
some
documentation
around
this.
It
sort
of
circumvents
the
need
for
having
complex
solutions
for
those
very
specific
maintained,
errs
yeah.
G
I
think
that
with
the
choke
at
RFS
events
issue
like
npm
b7
is
gonna,
do
the
right
thing,
so
they
could
just
do
nothing
and
the
experience
will
get
better
like
what
they're
doing
now
is
fine.
There
try
catching
the
there
require
they're
kind
of
doing
the
standard,
optional
dependency
thing.
It's
just
the
install
experience
sucks
and
we're
making
that
better,
so
problem
solved.
So.
A
A
H
So
hi
everyone
I'm
Claudia
for
the
past
couple
of
days,
I've
been
working
on
the
factoring
in
piano
dated
we
don't
with
arborist
and
I
have
noticed
a
couple
of
interesting
thing
thinks
the
bottom
line
of
this
erupts
is
basically
to
ream
to
remove
the
depth
flag
in
favor
of
having
a
new
one
called,
maybe
all
which
would
be
to
display
all
our
data
packages
from
from
a
tree.
H
So
it
seems
to
me
more
clear
and
straightforward
to
just
remove
that
one,
because
it's
it's
highly
unlikely
for
users
to
try
to
check
a
data
packages
for
a
specific
date
like
level
three
or
whatever.
So
all
just
seems
clearer
to
me
as
a
configuration
flag.
That's
pretty
much.
The
bottom
line
of
that
they're
up
see.
B
I
didn't
have
many
comments,
but
until
now
that
we've
had
this
conversation
from
a
little
bit
earlier,
where
every
flag
has
to
be
a
config
option
which
I
didn't
realize
then
I'm
like
oh
all,
as
a
config
option
is
a
bit
depth
is
a
config
option,
is
even
weird
so
I,
don't
know
how
that
rule
applies
here,
but
other
than
that
I'm.
A
big
thumbs-up
for
this
change.
G
The
output
might
slightly
right
now
right
now.
The
output
from
the
from
NPM
outdated,
shows
the
location
within
the
logical
tree
and
every
time
somebody
says
logical
tree,
you
should
you
should
shudder
and
gasp
and
realize
it's
a
bug,
because
the
dependency
graph
is
not
a
tree.
It's
a
it's
a
graph.
There
are
nodes
with
multiple
routes
into
them.
So
when
we,
when
we
sort
of
cast
it
as
a
tree,
we
end
up
in
this
situation.
G
H
That
was
another
topic
of
what
I
wanted
to
discuss
about
the
UI
of
the
command.
Basically,
because,
as
I've
mentioned
right
now,
it
feels
like,
if
we
decide
going
on
these
for
this
old
flag,
we
can
end
up
having
also
a
lot
of
noise
and
a
lot
of
info
on
the
on
the
terminal
for
packages
that
are
deduct,
but
they
are
not
being
distinguished
right
now
by
the
piano
de
tucumán.
F
F
B
A
B
But
we
didn't,
we
didn't
address
the
all,
as
a
config
option
is
I,
don't
want
to
continually
have
that
discussion
necessarily
every
time
we,
you
know
talk
about
a
new
flag,
but
we
we
should
at
least
make
sure
that
we're
all
on
the
same
page
with
what
are
the
actual
requirements
here,
because
that's
gonna
be
weird
right.
So.
G
Some
other
some
other
approaches
that
we
could
use.
So
if
we
wanted
all
to
be,
you
know
a
config
value,
and
certainly
there
are
some
config
flags
that
have
been
added
rather
casually
over
the
years
and
we're
trying
to
kind
of
bring
some
some
order
to
them
and
how
we
manage
our
again
camps
Eli's
dependencies.
G
We
should
definitely
take
a
look
at
like
where
or
just
kind
of
sit
down
and
have
a
think
about
where
we,
where
else
all
might
make
sense,
you
know,
would
you
ever
want
to
do
like
I?
Don't
know
NPM
audit
all
like
what
would
that
mean
for
NPM
LS
all
might
be
another
one.
You
know
where
perhaps
by
default,
LS
only
shows
the
top-level
dependencies
someone
like
yarn,
but
then
a
all
would
say.
No,
no
show
me
the
entire
tree
and
all
of
the
dependency
links
and
everything
else.
G
G
A
E
So
I
ran
into
this,
where
the
air
B&B
was
broken
for
a
while,
because
the
same
we
set
some
flag
in
NPM
for
NPM
install
and
it
also
affected
NPM
shrink-wrap,
and
we
didn't
realize
that
because
they
happened
to
use
the
same
names
even
though
they
didn't
do
exactly
the
same
things.
So,
given
that
it's
a
global
scope,
that
the
names
are
kind
of
dangerous.
G
G
G
What
we
don't
have
is
any
way
to
say
use
this
use
this
config
option
when
you're
running
this
particular
command.
Only.
That
would
be
a
great
idea
to
explore
in
an
RFC,
but
it's
just
fact
of
the
matter
is
today:
we
don't
do
that
so
I'm
I'm
actually
fine
with
this
reusing
long,
since
it
is
very
similar
to
the
way
that
long
is
used
with
LS
and
some
other
commands
and
having
it
as
a
config
option
doesn't
feel
that
hazardous
to
me,
though,
we
should
be
conservative
by
adding
new
ones.
So.
A
G
A
A
Okay
and
then
it
does
sound
like
we
have
an
opportunity
to
talk
about
sort
of
the
way
that
we're
handling
config
today.
That
could
be
a
separate,
even
discussion
that
we
bring
up
for
another
time.
Does
it
sound
like
this
is
going
a
lot
broader
than
just
the
outdated,
and
it
also
sounds
like
we
can't
move
quickly
on
ratifying
this
RFC
right
now,
until
we
figure
out
what
we're
gonna
do
with
that
flag,
so
cool?
A
So,
if
folks
can,
please
add
notes
into
the
RFC
itself
that
be
great,
and
we
can
have
discussion
about
whether
or
not
we
want
to
move
forward
with
all
I
want
to
get
to
I'm,
not
sure,
if
anybody's
on
the
call
that
would
have
been
in
the
discussion
around
the
RFC
121
so
purple
so
for
package
version.
You
know
we
spoke
about
this
a
bit
in
our
last
open,
RC
call
I,
don't
think,
there's
any
activity.
A
A
F
C
What
I
tried
to
do
was
try
to
make
an
RFC
that
allows
for
tight
script
like
types
annotations
to
be
sort
of
declared
and
available
inside
the
NPM
registry.
So
the
sort
of
the
problem
today
is
right.
Now,
the
only
real
sort
of
index
of
NPM
packages
that
do
not
have
that
have
typed
included
in
them
so,
like
you
have
shipped
with
a
dot
DTS
file
included
in
your
package
is
on
the
algo
Lea
search
and
index,
where
I
added
some
codes
that
sort
of
every
time
they
they
look.
A
C
Is
then
adds
this
sort
of
little
bit
of
JSON
to
the
to
the
search
index,
and
then
that
makes
those
available
to
be
able
to
say
okay.
So
there
are
two
sources
of
all
types:
the
NPM
packages
that
are
included
and
then
there's
a
definitely
type
registry
and
the
definitely
type
registry
there's
many
ways
to
get
access
to
that.
C
But
the
NPM
type
types
included
an
NPM,
a
trickier
to
find
so
this
RFC
says
I
think
single
flags
that
stays
like
types
of
are
included
in
this
and
that's
it
and
that
gets
put
inside
the
pack.
You
man
that
goes
inside
the
registry
and
then
any
tool
can
consult.
Just
look
at
that
and
then
also
look
at
definitely
typed
and
the
same
can
be
applied
for
like
flow
of
the
future
type
system,
things
that
could
come
out.
A
So
so
I
think
when
we
discuss
this
last
apologize
order,
we
didn't
pin
you
to
be
in
this
discussion,
I
think
when
we
talked
about
this
last,
we
were
talking
about
the
ability
to
add
metadata
to
apartment
already,
to
identify
whether
or
not
maybe
your
package
is,
you
know
a
typed
or
has
like
tech
type
script,
definitions
right,
type,
definitions
inside
of
it,
so
that
there
was
potentially
a
way
to
give
you
the
information
you
wanted
or
for
the
ecosystem.
Essentially
to
get
this
information
out,
yeah.
G
G
This
is
my
type
file,
and
this
is
the
type
of
type
file
that
it
is
and
then
that
would
be
that
would
be
in
the
package
manifest
and
would
not
have
to
be
kind
of
automatically
inferred
in
in,
like
an
underscore
property,
it's
a
little
bit
more
there's
a
little
bit
more
complexity
with
adding
a
new,
privileged
top-level
field
like
that,
because
you
know
we
have
to
make
sure
that
nobody
is
using
it.
We
have
to
make
sure
we're
not
kind
of
creating
incompatibilities
whatever,
but
I.
G
Think
it's
pretty
straightforward
in
this
case,
and
it's
just
gonna,
be
a
matter
of
you
know
looking
and
seeing.
If
that's
currently
in
use
one
one
way
we
could
we
could
do
it.
There
was
also
some
concern
about
kind
of
over
privileged
typescript.
You
know
versus
other
typing
type
of
libraries,
but
I
think
that
I
think
that
typescript
is
kind
of
the
dominant
one
and
even
the
other
ones
have
very
similar
ways
of
declaring
their
type
definition
files.
G
You
know
what
what
what
flavor
of
types
it
is,
so
you
would
say,
like
my
type
definition
is,
is
typescript
and
it's
in
food
DTS
or
you
could
say
my
type
definition
is
flow
and
it's
in
food
JSL
flow,
and
if
we
did,
that
I
mean
you
can
do
that
today,
right,
like
you,
can
do
that
today
we
can
put
it
in
the
pack,
the
package.json
z',
and
it
will
take
time
for
people
to
start
using
it.
The
next
step.
G
Might
you
know
once
we
have
that
then
NPM
in
it
could
default
to
it
and
p.m.
publish,
could
even
read
that
in
and
say
well,
you
haven't,
you
haven't
defined
a
tight
file,
but
I
see
this
in
Dec
this.
You
know
you
have
a
food
jeaious
and
a
food
DTS
imma
go
ahead
and
guess
that
those
two
are
connected.
If
we
can
do
that
in
a
deterministic
way,
that's
not
likely
to
have
false
positives,
then
I
mean
I'd
have
no
problem
with
that
with
defaulting
it.
So.
C
Today,
we've
been
recommending
people
as
types
like
a
Lukas,
it's
in
the
package
to
manifest
so
there's
types
of
those
Taipings
which
is
an
older
version.
But
the
thing
is
like
because
typescript
supports
the
node
resolution
and
sort
of
just
hijacks
putting
DTS
files
for
this.
Then
it's
optional
effectively.
C
Yeah,
so
using
the
current
types
you
can
you
can
check
that
right
now,
the
types
of
the
manifest
again
it
all
just
comes
down
to
like
I'm
sure
there
will
be
people
will
just
be
like
I,
owe
more
potently
I,
think
people
that
I
run
JavaScript
libraries
get
thrown
a
indexed
DDS
file
to
them
by
some
random
type
scripters
and
they
never
know.
To
like
add
the
types
like
package
field,
or
something
like
that.
C
B
B
So
one
of
the
things
that
we've
been
trying
to
figure
out
for
I,
don't
a
long
time
for
Express,
is
like
how
we
can
like
tell
people,
here's
where
you
can
get
these
types
that
we
don't
maintain
like,
and
one
of
the
big
problems
that
has
happened
is
since
we
don't
maintain
them
and
we
don't
intend
to
maintain
them,
and
we
don't
want
to
maintain
them
unless
somebody
steps
forward
like
what
we're
gonna
do
permanently
is
say,
good
luck
right.
What
we'd
like
to
be
able
to
do
is
say.
B
Good
luck
here
are
some
at
a
specific
version
that
were
that
somebody
came
by
and
said
we
hear,
there's
no
file
in
your
repo
there's
one
field
in
your
package,
Jason
that
points
to
an
entirely
different
package
at
a
very
specific
version,
and
then
that's
the
maximum
that
we,
as
the
express
team
need
to
maintain,
is
this?
Would
this
allow
for
something?
Or
could
we
restructure
this
to
allow
for
something
like
that
where
it's
just
like
the
single
line
in
the
package?
B
C
B
Version
specifier
is
specifically
important
to
us
because
we're
fine.
If
somebody
comes
in
and
says
no
no
you're
on
Express,
you
know
4.16,
but
actually
the
types
haven't
changed
since
4.0.
Maybe
you
can
fight
like
we.
Don't
we
just
don't
know
we
don't
know
if
that's
true
or
not
right,
so
we
just
want
to
have
some
like
we.
We
did
have
somebody
come
in
and
verify
that
at
that
version
it
worked
and
that's
like
our
maximum
amount
of
commitment,
yeah.
G
G
C
C
B
Agree
and
I
think
this
is
the
biggest
bone
I've
had
to
pick
it's
not
even
about
being
old,
fogey
JavaScript.
It's
just
like
this
is
a
whole
new
ecosystem
and
support
it
takes
work
and
we
as
maintainer
x',
are
already
overloaded.
We
don't
have
enough
time
to
do
even
the
basic
stuff
that
we
are
expected
to
do.
So.
How
are
we
expected
to
also
then
support
typescript?
It's
not
whether
we
like
it
or
not.
It's
like
I,
like
textured
I,
think
it's
cool
I
want
to
support
it.
B
I
don't
have
the
bandwidth,
and
so,
if
you
all
can
come
in
and
say
no,
no.
Here's
how
you
can
do
this
in
a
way
that
our
consumers,
who
are
writing
typescript
applications,
will
be
able
to
seamlessly
work
with
you
at
a
very
minimal
low
effort.
You
know
thing:
yeah,
you're,
gonna,
get
tons
of
adoption
just
by
that
yeah.
G
G
A
G
A
It's
good
yeah,
awesome
and
hopefully
we'll
see
you
around
here
more
often,
so
thanks
again
everybody
for
jumping
on
for
another
call
I
apologize
again.
We
want
to
loop
it
over
and
we'll
try
to
be
mindful
of
time
going
forward
for
sure.
We
also
got
started
late
again.
So
that's
on
me
I'll
try
to
make
sure
that
we
have
a
deep
dive
conversation
poll
created
after
this,
since
we
can
get
time
to
talk
about
what
we'd
like
to
go
in-depth
for
next
week.