►
From YouTube: Open RFC Deep Dive Meeting - Wednesday, May 20th 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
B
Awesome
and
we're
live
on
YouTube
thanks
everyone
again
for
showing
up
to
a
number
of
Narsee
be
calm.
These
are
the
being
all
times
that
we
have
with
the
normal
open,
RC
Agenda
calls.
Today
it's
gonna
be
a
little
bit
different,
based
on
fact.
We
didn't
get
around
to
choosing
a
specific
topic
to
dive
into.
We
do
have
an
agenda
that
is
outlined
and
I'm
sharing
here
in
chat
feel
free
to
add
yourselves
as
attendees
there
on
the
agenda.
B
It's
essentially
outline
of
existing
Archie's
very
similar
to
you
know
the
list
that
we
looked
at
and
discussed
last
week
and
there's
a
couple
items
on
here.
We
we
thought
we
wanted
to
touch
on
a
little
bit
more,
since
some
work
has
been
done,
or
at
least
since
the
last
call
even
and
I
know
Roy.
If
you
just
add
his
laptop
crash,
is
gonna
join
in
and
and
wants
to
speak
to
a
few
of
those
items
have
been
queued
up
just
going
through
the
basic
housekeeping,
though
again
it's.
B
C
B
You
can
find
a
reference
to
that
in
the
NPM
/
or
the
NPM
RFC's
repo
on
github
and
again,
the
desired
outcome
here
is
that
we
push
this
forward
on
on
some
of
these
features
and
try
to
gain
consensus
with
the
community
and
work
closely
with
the
community,
make
sure
that
we're
building
right
things
and
having
the
right
discussion
so
Before
we
jump
in
to
sort
of
the
list
that
we've
sort
of
put
together
today.
It's
very
announcements.
C
B
C
C
B
B
B
No,
if
not,
then
we'll
get
going
so.
The
first
item
is
PR
135,
so
clarifying
and
outlining
sort
of
the
RC
withdrawal
process
and
sort
of
what
that
would
look
like
sort
of
this
is
a
document
they
threw
together.
Some
language
I
threw
together
to
again
formalize
what
that
would
look
like
and
just
to
make
sure
that
we
are
communicating.
C
B
We
might
even
afford
with
essentially
not
implementing
something
that
we've
previously
ratified.
It
seemed
like
there
was
no
qualms
about
sort
of
the
language
before
the
one
knit
that
I
know
Isaac
had
was
just
where
the
amendment
positioning
would
be
so
I
switched
that
up
in
the
actual
pro
request.
So
we
asked
the
you
know
as
a
community.
C
B
E
B
E
D
Yeah
I
think
I
think
the
where
we
ended
up
landing
on
it
was.
There
are
actually
a
few
other
cases
where
we
might
want
to
use
all
so
we
don't
want
to.
We
do
want
to
have
kind
of
all
be
the
default
when
you
do
an
update,
so
it's
not
relevant
there,
but
if
I
believe
it
was
MP
MLS
we're
sort
of
tossing
her
on
some
ideas,
for
you
know
basically
making
it
only
show
that
the
top
level
depths
by
default
in
a
somewhat
more
abbreviated
way.
D
So
you
don't
get
this
massive
terminal
dump
when
you
run
it
in
MLS
and
so
all
will
probably
be
relevant.
There
I
think
it's
fine
to
just
have
it
as
a
as
a
config,
it's
sort
of
meaningfully
different
from
from
long,
which
already
has
some
some
relevant
meaning
and
him
outdated,
so
yeah
I'd,
say
move
forward
to
this
I
mean
that
was
the
only
objection
was
kind
of
a
bike
shed
over
the
config
name,
and
it's
fine.
E
D
F
E
Mean
the
only
other
thing
that
was
my
other
comment
was
the
the
only
other
comment
was:
can
we
add
logical
and
physical
path,
but
I
don't
see
any
updates
since
that
comment,
there's
a
thumbs-up
which
leads
me
to
believe
this?
Oh,
that
was
just
Jordan,
so
so
the
problem
do
we
think
we
can
add
that
I
mean
we're.
We
landed.
D
What
we
there,
we
will
kind
of
do
a
couple
rounds
of
what
what
we
show
in
terms
of
the
The
Wanted
path
in
other.
It's
the
you
know
like
the
implementation
for
the
implementation,
for
the
way
it's
doing
all
right
now
in
the
v7
branch
I
think
is
most
of
the
way
there,
but
it's
got
some
weird
edges
that
probably
need
to
be
sanded
down
before
you
know
before
a
proper
seven
dotto
release,
but
yeah.
So
you
will
effectively
show
know
the
problem
with
the
problem
with
logical
path.
D
But
in
order
to
show
every
logical
path,
I
also
have
to
show
everything
that
depends
on
them
and
everything
that
depends
on
them
and
so
on,
because
each
one
of
those
will
be
a
different
logical
path,
just
what
we
do
now
and
it's
horrible
it
makes
it
makes
NPM
outdated.
You
know
death
kind
of
useless,
that's
sort
of
the
motivation
for
this
feature
in
the
first
place.
Well,.
E
Maybe
we
don't
show
it
in
the
standard
output,
but
maybe
it's
hidden
behind
some
sort
of
maybe
there's
long
or
I,
don't
know
whatever
but
like
if
I
did
Jason
and
all
and
long
or
something
and
got
every
single
logical
path
that
would
make
that
would
from
a
leaks
but
I'd
be
able
to
then
build
like
a
something
that
goes,
look
and
looks
and
sees
like.
Maybe
the
minimal
update
that
would
result
in
it
no
longer
being
locked
to
an
older
version
right
but
like
as
it
stands,
I
rely
on
NPM
I
mean
I.
E
D
What
we
have
what
we
could
do
to
give
you
to
give
you
that
is
in
the
inland
light
kind
of
long
all
output.
We
could
show
you
not
just
which,
which
versions
which
version
ranges
are
required,
but
the
physical
path
of
those
nodes
with
that
requirement,
so
you'd
be
able
to
say,
okay
well,
this
is
dependent
on
this
node
in
the
tree
is
dependent
on
by
these
other
nodes
in
the
tree,
and
you
know,
without
making
it
look
like
there's
a
hundred
and
fifty
things
that
all
depend
on
McDormand.
Really
it's
like
three
right.
E
If,
if
we
can
get
a
a
way
that
is
going
to
be
supported
by
y'all,
that
does
that
without
it
being
showing
to
NPM
I'm
super
happy
for
that
to
be
the
solution.
That's
actually
a
much
better
solution
in
my
opinion,
but
I
don't
want
to
be
the
one
building
like
third-party
tooling,
and
that
would
then
have
to
keep
up
with
whatever
changes
you
make.
You
know,
which
is
where
showing
out
to
NPM
sort
of
has
some
benefits.
Yeah.
D
Yeah
I
mean
I,
think
I
think
as
a
as
a
general
kind
of
strategic
to
Zion
goal.
The
NPM
CLI
should
really
be
first
and
foremost
for
humans
and
the
other.
The
other
modules
that
we
use
should
provide
that
kind
of
deeper
programmatic
access.
So
if
you,
if
you
do
want
to
yeah,
you
know,
I've
told
you
if
you
want
to
do
that
with
arborist
today,
it's
a
little
you're
kind
of
taking
on
some
some
risk,
because
it's
so
early,
but
once
that
gets
to
a
1.0
and
we
have
a
general
release
of
m57.
D
E
B
C
Yeah
I
want
to
make
a
quick
leave
why
we
want
to
add
up
idea
to
MPN
to
basically,
as
I
said,
I'm
working
on
Nexus
composite
data
manager.
It's
on
the
types
products
I
might
be
hurt
about
with
it,
so
I
catch
a
frog
and
a
VA
using
app
ID
parameter
a
while
performing
and
I
would
comment.
So
if
I
use
a
user,
our
user,
which
uses
Nexus
a
visitor,
a
manager
I,
have
to
provide
application
ID
to
perform
on
p.m.
C
C
We
can't
inject
it
anyway.
So
we
use
this
application,
a
different
package
work
and
we
have
to
say
for
a
user,
you
have
to
open
a
package
work
file
and
right
where
application
ID
and
when
we
can
do
it
with
information
in
our
application.
So
to
do
my
Chris
process
as
much
as
easier,
we
decide
to
add
this
parameter
to
HTTP
header.
B
D
D
If
the
server
responds
with
an
HTTP
header
of
the
npm
app
ID,
then
the
CLI
will
just
put
that
in
the
package
JSON
and
whenever
the
whatever
npm
the
CLI
makes
a
request
to
the
server
it
sends
the
app
ID
along.
So
what
that
can
actually
let
us
do
is
a
lot
of
interesting
stuff
beyond
just
audit
or
audit
advisory
overrides.
We
could,
you
know,
say
things
like
you
know
for
for
this
particular
application.
D
D
C
G
E
C
D
D
You
know
the
if
I,
if
I'm
publishing
something
that's
one
thing
and
there's
a
bunch
of
stuff
I
can
do
with
that
on
the
registry,
but
I
don't
run
npm,
publish
on
my
website
right.
I
just
I
installed
there
and
I
push
it
to
get
or
nick
goes
to
my
you
know,
CDN
and
gets
published
on
to
the
website
or
whatever,
but
I
still
may
want
to.
You
know
have
some
hooks
to
do
some
interesting
stuff
with,
like
who
hats
you
know,
tracking,
like
I
want
to.
D
I
want
to
log,
like
all
of
the
different
IPS,
that
this
server
has
been
installed
on
and
make
sure
that
you
know
if
I
have
a
server
in
production
that
has
a
security,
vulnerability,
I
can
track
it
down
and
say:
okay,
it
was
installed
on
this
date.
By
this
you
know
a
particular
process
at
this
IP
address
I
can
go
and
fix
it.
E
B
D
D
D
D
Happens
if
I
just
what
happens
if
I
just
go
into
an
application
of
mine
right
like
what
happens
if
I
just
copy
and
paste
your
app
ID
into
my
package,
JSON
like
so
since,
there's
no
stopping
that
the
server
has
to
have
a
way
to
manage
this
thing
and
have
some
be
the
kind
of
final
authority
on
it
and
say
well,
no
that
app
ID
is
actually
owned
by
Darcy
Clark.
Here's
a
new
one.
B
C
D
D
B
B
C
B
B
I
think
yeah
and
I'm
wondering
if
there's
any
way
we
can
get
some
sort
of
unique,
key
or
unique
identifier
out
of
existing
like
our
into
existing
infrastructure
like
if
that's
what
you're
looking
for
right
or
it's
you
know,
you're
providing
some
secret
that's
being
passed
through.
The
registry
is
more
like
that
sounds
like
yeah.
E
It
see
it
seems
like
more
like
this
would
be
at
least
to
start
something
that
other
providers
can
add
additional
like
features
based
on
or
leverage
points
for
them,
whereas,
like
for
the
public
registry,
it's
a
little
bit
less
valuable
and
maybe
that
maybe
that's
making
a
stretch
but,
like
you,
wouldn't
have
liked.
You
definitely
wouldn't
want
your.
You
know
my
random
Express
app
reporting
back
at
a
you
know,
tracking
ID,
to
the
public
NPM
every
time
I
install
right
but
like
at
Netflix.
E
D
You
know
one
way
to
one
way
to
thread
the
like
the
privacy
needle
might
be
to
say
that,
like
the
the
only
way
that
a
the
only
way
that
an
app
ID
gets
assigned
into
an
application
is
via
some
specific
action,
so
you
would
run
you
know,
NPM
app,
create
foo
and
it'll
drop
a
you
it'd
in
your
package,
JSON
and
then
from
then
from
that
point
forward.
It'll
keep
reporting
it
to
the
server,
but
it
would
not
have
a
situation
where
the
server
can
just
say:
hey
I've,
never
seen
this
app
before
here.
E
So
so,
since
this
you
know
brings
up
the
what
is
sent
with
audit,
it
actually
see
like
another
possible
way
to
approach
the
same
problem
that
would
at
least
solve
the
audit
part
would
be
to
provide
a
new
key
in
your
package.
Jason
that
just
sent
an
arbitrary
object,
always
like
anytime,
you
regenerated
a
package.
Locke
would
copy
over
that
entire
object
right
so
that
we're
not
just
like
pigeon
holing
ourselves
into
an
app
ID.
E
Well
I
would
send
an
app
ID,
along
with
everything
right,
I
guess,
I'm.
Just
trying
saying,
if
you're,
if
you're,
already
going
to
use
audit
to
leverage
inside
of
your
internal
tooling
right,
say,
you're
gonna
now
track
every
build
and
what
was
what
was
installed
at
the
you
know,
at
the
build
time
via
audit
app,
ID
is
just
one
possible
thing
you
might
want.
You
might
also
want
what
was
the
get
hash
at
this
time
right?
You
might
also
want
what
was
the
you
know?
E
D
This
starts
to
sound
more
like
a
more
like
a
plug-in
architecture
right
like
because
I,
don't
just
I,
don't
just
have
some
arbitrary
metadata
that
I
put
in
my
package
JSON
and
never
touch
again.
I
I
wanted,
like
I,
want
to
run
a
command
and
I
want
to
find
out.
What
is
the
Jenkins
build
ID?
What
is
the
get
hash.
E
Maybe
we
have
it:
we
have
a
metadata
file,
we
add
to
every
single
project
that
puts
in
the
Jenkins
master
and
the
Jenkins
job
names
and
a
bunch
of
other
metadata
about
how
our
build
infrastructure
works.
We
put
that
in
a
separate
metadata
file
that
gets
sent
along
with
all
sorts
of
stuff
and
is
very
helpful
when
it's
hard
coded
and
almost
never
changes
well,
you're
good,
nothing
that
works
for
everybody,
yeah
yeah,
yeah,.
B
But
I
think
that
we
should
probably
Wes
if
you
have
a
couple
other
use
cases
already
in
mind
that
would
like
you
could
see,
especially
broadening
the
scope
from
app
ID
to
an
object
and
for
us
to
like
figure
out.
You
know
where
this
would
fall
in
terms
of
power.
It
could
be
implemented,
like
feel
free
to
add
some
add
some
commentary
and
color
to
the
existing
discussion.
Absolutely
I'll
I'll
do
that
cool
moving
on
so
this
is
kind
of
exciting
Roy.
B
H
Yeah,
maybe
you
can
even
run
a
quick
demo
right
so
yeah?
No,
it's
just
that
I
got
bored
with
all
the
video
games.
I
was
playing
and
then
I
decided
to
hack
on
something
for
a
change
so
yeah
and
basically
it's
just
the
just
a
command
that
I
always
wished.
No,
this
year,
I
had
Mattingly
right,
like
we
have
some
solutions
on
the
userland,
but
I
always
wish.
It
was
a
native
thing
this
year,
like
so
I,
think
I
can
just
know
a
quick.
H
Yeah
you
mean
like
this,
make
it,
but
so
maybe
maybe
I
should.
H
So
yeah,
so
basically
it's
an
NP
and
DF
command.
So
maybe
a
good
starting
point
is
like
being
able
to
compare
two
to
two
package
right,
so
you
can
provide
it
any
spec
and
it
will
convert
it
to
something
and
it
will
fetch
the
turbos
for
further
the
two
versions
and
we'll
compare
it
and
the
basically
print
on
the
standard
output
get
unified
if
compatible
output.
So,
like
you,
can
kind
of
reuse,
any
tooling
you're
already
using
along
with
that
so
like
here
I
have
this
dummy
package.
H
What
you
expect
right,
like
get
with
compatible
kind
of
output,
so
that
means
I
can
also
like
use
that
output
in
any
existing
tooling,
like
that,
get
so
like
the
specific
parser
that
will
like
kind
of
print
prettier,
differing
output
right
going
to
be
like
pluggable,
right
away,
and
so
another
interesting
usage
for
this
is
like
complimenting
like
the
regular
just
like
audit
or
NPM
outdated
experience
right.
So
you
run
and
Kim
updated
you
find
out.
O
yards
has
a
change.
H
Oh,
there
was
a
patch
version
really
there,
so
you
could
like
also
just
run
in
pmdf
and
like
yards,
and
it's
going
to
compare
wherever
version
you
have
installed
with
whatever
is
laters
here.
Right,
like
yards
is
basically
just
be
the
same
as
latest,
but
you
could
also
possibly
just
say:
okay
I
want
to
know
specifically
against
three
that
one
and
you
have
the
expected
result
right.
Like
you
see
the
difference
between
those
versions.
I
have.
G
A
quick
question:
that's
okay,
so
the
NPM,
outdated,
app
would
include
current,
wanted
and
latest
I
see
a
use
case
for
diffing
between
current
and
wanted,
meaning
what
am
I
about
to
update
to
and
because
the
diff
between
either
anything
and
latest
is
almost.
H
One
way
I
was
approaching
this
problem
like
because
I
want
to
have
this
kind
of
interoperability
between
the
commands
right.
So
it's
kind
of
like
thinking
about
maybe
outdated.
You
have
it
more
friendly
output
right,
so
maybe
so
that
I
can
like
hack
some
things.
I,
don't
know
like
very
quickly
but
like
in
this.
In
this
example,
over
here,
I
could
fewer
for,
like
just
Jason
you're
like
wanted,
and
then
I
could
possibly
pipe
that
into
and
PM
differ.
I
could
like
and
like
get
that
kind
of
experience
right
away.
C
H
A
H
F
C
F
H
H
F
I
decided
the
questions
one
of
the
questions
I
had
there
is
like
like
yeah.
You
know
that
actually
kind
of
combines
nicely
with
what
my
idea
was,
which
is
like
you
know:
I
just
want
to
look
index
like
I.
Don't
care
about
the
changes
in
package.
Jason
I
just
want
to
look
at
a
single
file
because
that's
the
file
I
know
or
like
I.
Don't
care
about
tests
so
like
just
being
able
to
kind
of
pass
a
single
file
name
would
be
nice
right,
yeah.
H
H
Log
I
recommend
that
you
can
send
and
it's
going
to
filter
for
only
their
change
log
file,
but
maybe
that
can
be
extended
to
like
accept
any
arbitrary
file,
instead
of
just
doing
it
for
a
change
log
but
change
what
would
be
nice
because
it's
kind
of
a
very
relevant
one-
and
maybe
we
can
also
like-
have
a
fallback
to
comparing
against
github
releases
also
right
like
if
I
change
log
file
is
not
available.
Maybe
we
try
to
default
to
be
two
countries,
but
that's
a
more
advanced
use
case.
B
E
E
I,
what
I
posted
in
chat
is
sort
of
the
get
format
right,
so
you
can
do
anything
after
the
double
dash
will
be
at
your
filter
on
your
input.
It's
just
so
we
could
just
follow
the
same
like
right.
If
you
do
like
get
diff,
you
know
ahead.
Carrot
1
dash
dash
index
J
s
you'll
only
get
if
index.
Yes
right
right.
H
H
This
is
more
for
Pocket
package,
other
right,
so
you're
in
a
current
package
like
a
project
that
is
a
package
that
you
publish
to
the
in
CHEM
registry,
so
you
random
can
diff
and
you're
able
to
kind
of
like
get
a
similar
output,
but
this
is
comparing
against
the
latest
publish
release
in
the
in
the
NPM
registry,
so,
and
also
only
only
really
using
files
that
are
tracked
by
your
NPM
package.
So,
if
you
add
it
like
anything
outside
I
think
there's
not
published
to
your
your
a
package.
H
So
let's
say
I
do
a
change
in
the
test
file,
but
it's
not
published.
So
if
I
ran
and
canned,
if
it
is
not
going
show
up
right,
oh
I
can
get
this.
It
is
tracking
all
the
changes
in
the
record
so
yeah.
So
this
is
basically
like
the
surface
at
covert
in
my
small
POC,
but
Isaac
already
brought
like
some
interesting
use.
Cases
like
it
would
be
nice,
like
that's
back
I,
would
also
like
to
point
to
maybe
a
folder
right,
especially
with
workspaces.
D
H
D
Feed
bags
like
this
is
awesome.
I
have
I
drop
in
to
get
log
so
frequently
to
dislike.
Okay,
let's
figure.
What's
the
tag
that
I
last
published
and
then
get
diff
against
that,
just
to
kind
of
see
what
it
is
I'm
about
to
publish
like,
should
this
be
minor
or
major
or
patch,
there's
all
kinds
of
good
reasons
to
use
this
there's
also
a
lot
of
server
side
and
security
use
cases
where
you
know
we
we
might
want
to.
D
For
example,
there's
there's
some
some
code
that
we
have
now
that
that
actually
tries
to
detect
malware
by
detecting
by
running
a
diff
against
the
installed
or
the
published
package
artifact
and
the
the
git
repo.
If
we
can
figure
out
what
that
get
repo
is
and
what
the
head
is
that
it
was
published.
Trunks
is
one
one
common
way
to
try
to
sneak
malware.
D
D
So
there's
there's
two
things
here.
The
first
is
the
the
implementation
in
terms
of
like
what
what
can
sort
of
be
tweaked
from
from
Roy's
hacked
together
weekend,
project
and
and
I
think
this
is
a
great
start
and
we
could
just
make
it
a
you
know.
Tighten
it
up
a
little
bit,
but
the
the
other
thing
is
that
the
the
UX
around
it
and
that's
kind
of
where
it
gets
more
interesting,
where
we
need
to
see
a
much
more
full-featured
kind
of
RFC
conversation.
D
One
concern
is
that
NPM
CLI
argument
parsing
is
very
different
from
gates,
so
some
of
the
things
that
we
do
with
double
dash
and
stuff
like
if
we,
if
we,
if
our
goal
was
to
match,
gets
CLI
arguments
exactly
for
diff,
then
it's
gonna
be
very
much
an
odd
duck
in
terms
of
how
we,
you
know
how
we
pass
configs
to
it
and
stuff.
So
we
may
that
may
be
worth
it
to
match,
get
as
much
as
possible
or
it
may
just
be.
D
H
D
B
B
Want
to
make
sure
that
we
get
some
time
for
the
next
couple,
even
if
there's
just
updates
on
the
last
few
or
no
no
updates
is
an
update
on
the
last
few
items
in
the
agenda,
but
I
want
to
thank
Roy
for
for
doing
that
demo
and
encourage
folks
to
provide
some
feedback,
because
that
just
came
up
this
past
week.
But
this
is
definitely
something
that
I
think
is
definitely
useful.
B
We
constantly
are
figuring
out
and
trying
to
determine
whether
or
not
we're
gonna
update
a
depth
based
on
you
know,
what's
changed
and
if
the
more
that
you
can
stay
within
you
know
the
console
and
and
within
you
know,
where
you're
working
better
instead
of
having
to
go
off
and
try
to
determine
from
change
logs
and
github
or
get
lab
or
wherever
the
source
is
what
what's
changed.
So
I
really
like
like
this
is
amazing.
I
think
it
would
help
a
lot
of
people,
so
cool.
B
H
This
one
is
just
a
continuation.
We
started
the
conversation
as
a
as
a
discussion
in
the
issue
a
couple
of
months
ago,
but
basically
around
removing
the
current
update,
not
fire
logic.
We
have
there,
but
you
know
pops
up
that
that
box,
telling
you
that
there's
a
new
version
of
the
COI
yeah,
an
Isaac,
proposed
a
very
neat
kind
of
like
replacement
to
that
logic
in
which
we,
the
server,
could
send
you
a
header
and
then
the
the
CLI.
H
If
that
header
is
there
that
it
presents
the
output,
but
given
that
the
conversation
actually
originated
around
the
package
itself,
it
can
be
quite
noisy.
We
had
some
problems
with
it
in
the
past,
so
also
reworking
the
UI
around
that
didn't
hire
you
axe
around,
showing
you
not
notify
you
that
there
is
a
new
version
of
the
CLI
available.
H
B
H
H
But
yeah
right
now,
I
focus
on
the
on
the
new
mechanism
of
adding
hadar.
So
so
you
send,
the
CLI
is
going
to
send
the
user
agent.
I
specifying
that
whether
it's
a
person,
current
version
of
the
CLI
and
the
server
is
going
to
reply
with
response
if
it
knows
that
a
new
version
of
the
CLI
is
available.
D
D
It
might
be
you
know,
and,
and
we
could,
we
could
should
probably
spec
out
exactly
what
that,
how
that
works
right
like
how
do
we
know?
How
do
we
know
which
document
we
should
be
looking
at
and
based
on
the
user
agent
string
and
and
just
like
what
is
the
name
of
the
header
and
at
least
have
that
speck
sitting
there
as
a
kind
of
a
registry
RFC
and
then
in
the
meantime
we
can,
we
can
add
support
for
it
in
our
CLI
and
then
also
maybe
evangelize
it
for
it
on
yarn
and
yeah
and.
E
That's
the
one
yeah
yeah
that
works
in
a
slightly
different
way,
though
right,
because
that
would,
if
you
set
that
header
on
the
server
side,
that
would
display
for
every
single
pack,
you
meant
or
something
right,
like
you'd,
have
to
figure
out
the
state
management
yourself,
whereas
the
like
update
workflow
is
just
here's
a
message
at
the
beginning.
If
you
write
like
this,
you
might
what
I'm
saying
with
the
difference?
Does
that
make
sense
right.
D
So
you'd
want
it
to
be
almost
yeah.
You'd
almost
want
to
a
different
kind
of
notify
header
that
the
CLI
knows.
Okay,
I
got
I,
got
8,000
of
these
duplicate
messages,
I'm
gonna,
just
but
they're,
a
special
header
that
I
just
like
save
until
the
end
and
I
print
at
the
end
of
the
run
right.
So,
even
though
it's
in
every
response,
you
know
it's,
it's
maybe
something
more,
a
little
more
of
a
paved
path.
I,
don't
know
if
I
would
use.
C
D
A
general
purpose
send
a
notice
to
the
to
the
user.
I
might
just
kind
of
rely,
keep
continue
to
lean
on
it.
The
NPM
notice
header,
for
that
and
have
this
be
something
that's
like.
No,
no
specifically,
you
are
using
this
version
of
this
of
a
CLI
and
here's
the
version
you
should
be
using
and
then
well.
E
I
guess
I
was
just
thinking
the
like.
We
would
like
to
enforce
more
of
this.
These
opinions
that,
like
like
my
team,
might
have
like.
We
just
don't
want
if
people
are
using
NPM
5,
we
had
somebody
come
into
our
help.
This
saturday,
zhing
npm,
3
I,
want
to
be
able
to
tell
them
in
their
CLI
the
right
when
they
run
that
command.
You
shouldn't
be
doing
this
like
I,
want
it
to
be
huge
and
I
want
it
to
be.
E
Like
I
know,
we
can't
do
that
from
the
open-source
side,
but
like
as
a
company
like
we
want
to
do
that
right.
So
we're
looking
at
what
is
the
tooling,
we
have
to
yeah
that
we
have
to
instrument
to
get
that
to
the
user.
If,
if
you
know
in
the
future,
NPM
had
more
generic
form
of
that.
You
know
when
we're
on
NPM
10
and
we're
trying
to
give
people
often
p.m.
7
it'd
be
a
lot
nicer.
If
we
had,
you
know
actually
it'd
be
nicer.
E
B
To
be
my
full
time,
no,
we
only
have
four
or
five
minutes
left
and
I
apologize
order.
Your
you
just
jumped
on
I
know:
you're
RC
is
the
next
one
that
was
on
the
agenda.
I,
don't
know
if
you
frozen
or
you've
taken
a
screenshot
of
you
smiling
I'm,
not
sure
which
Isaac
does
that
to
me
all
the
time
it
calls.
So,
hopefully
it's
the
latter.
B
Would
you
like
to
dive
in
and
give
us
any
updates
on
the
RC
126,
specifically
for
adding
types,
information
and,
and
just
note
on
the
last
discussion
folks
feel
free
to
Wes,
definitely
top
off
with
the
sentiment
that
this
could
be.
You
know
if
you
can
see
usage
beyond
the
scope
of
just
the
updating
CLI
for
for
using
those
headers
right
so
but
yeah
order
that
you
want
to
give
an
update
with
RCA
126,
adding
type
information.
H
B
H
Really
yeah
I
guess
from
what
I
saw
in
the
arts
in
terms
of
comments,
I
really
like
p-n-p-n
p.m.
alder
left.
A
comment
like
saying
usage
of
config
name
would
be
actually
nice
and
he
left
an
example
using
just
like
W,
which
actually
like
saying
it.
It's
it's
way
better
than
what
I
was
when
I
was
just
thinking
about
it
because
having
just
W
as
an
alliance
for
like
that's
that's,
where
it
space
right.
It's
a
much
more
useable
like
interface
for
users,
so
I
was
kind
of
reconsidering
that
but
I
know.
G
I
was
just
I
mean
the
like
the
sort
of
structures,
the
use
case
use
cases
that
are
there
now
right.
One
of
them
is
like
I
have
just
a
single
package.
The
other
is
I,
have
a
repo
that
has
a
packages
folder
and
all
of
my
publishable
things
are
inside
there,
but
then
the
other
one
which
I
think.
Usually
everyone
agrees.
We
shouldn't
do,
but
I
actually
have
a
new
use
case.
For
that
I
can.
G
Defense
would
be
one
where
the
route
is
a
package,
but
I
have
another
publishable
package
nested
inside
it,
and
that
there's
my
defense
for
es
lint
plug-in
import.
Is
this
that's
the
way
the
other
person
built
it
and
I
want
em
PM's
commands
to
work
with
it
I
you
my
new
use
case
I,
don't
have
to
get
into
right
now,
but
like
I,
don't
want
to
build
that
structure
if
it's
not
gonna
work,
so
that's
all
I
was
asking
was
like.
Is
that
a
use
case
that's
going
to
work
or
is
my
should.
C
G
G
G
Is
not
for
for,
like
esn't
plugin
import,
the
route
is
published
and
so
are
some
of
the
sub
packages.
For
the
like
saying,
I'm,
I'm
building
one
thing
where
I'm
using
learner
at
the
moment
and
I'm
using
dot,
because
I
want
to
be
able
to
run
the
same
commands
in
the
route
as
well
as
the
sub
packages.
Even
though
the
sub
packages
are
published
and
I
want
to.
You
know,
I
wanted
to
leverage
like
learner's
parallelization
and
then
for
my
new
use
case.
G
H
H
B
Apologize
were
at
and
a
little
bit
over
time,
but
order
I
know
so
you
jump
back
on.
Can
you
in
the
I
apologize
for
put
you
on
the
spot,
but
maybe
you
give
us
for
folks
that
have
to
drop
off,
feel
free,
we'll
go
a
couple
minutes
over
here:
I
apologize,
but
maybe
order
if
you
want
to
give
us
update
on
the
types
RC
and
maybe
some
discussions
that
I
know
have
happened
out
of
that
discussion
specifically
sure.
A
A
The
sort
of
package,
in
the
same
way,
that
we
do
the
main
fields
in
a
package
and
so
I
updated
the
current
RFC
to
sort
of
basically
reflect
that
and
paints
the
flow
team
who
don't
have
a
similar
sort
of
equivalent
field
as
main
four
for
flow
files,
because
they
just
automatically
resolve
and
I,
can
kill
a
video
that
they'd
have
the
equivalent
main
field.
So
it
was
also
requesting
that
they
support
a
field
like
that.
A
B
A
B
B
For
folks
that
haven't
kept
up
with
that,
you
can
jump
in
and
and
see
the
updates
that
horse
made
apologize
again
for
running
a
couple
minutes
early.
But
our
late
appreciate
everybody
jumping
on
today
and
hopefully
I'll
see
you
all
next
week
same
time
same
place
and
feel
free
to
follow
up
in
the
MP
MRC's
repo,
with
any
discussions
that
you
found
interesting
today.
So
hopefully
everybody
staying
safe
and
healthy
and
I'll
talk
to
you
next
week.
Good.