►
From YouTube: Open RFC Meeting - Wednesday, May 13th 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
Hi
there
I'm
Cale
Shipman
I'm
in
Chicago,
Illinois
I
am
currently
C
terrible
financial
tech,
startup
called
up
in
finance
and
we're
building
everything
in
typescript,
which
I
adore
and
I'm.
Actually,
a
relative
newcomer
to
typescript
I
think
I
started
writing
in
typescript
about
three
years
ago
and
coming
from
PHP.
So
it's
been,
it's
been
a
wonderful
step
up
in
terms
of
you
know,
embracing
type
languages
and
anyway,
yeah
I've
been
running
into
this
I've
been
learning
a
lot
about
NPM
in
the
process
and
and
I'm
coming
at
it
with
a
lot
of
other.
A
C
A
E
F
Like
like
kli
I,
also
came
to
JavaScript
via
PHP,
although
not
so
recently
been
doing
NPM
the
whole
time
still
doing
it.
Cool.
G
Yeah
I'm,
Jordan
I,
actually
by
way
of
Rails,
also
came
from
PHP
and
many
many
years
ago,
and
I
maintained
a
bunch
of
projects
and
I'm
a
couple.
Node
working
groups
and
tc39.
A
A
The
integers
of
this
college
is
hopefully
to
a
new
channel
for
us
or
have
another
channel
for
us
to
you
as
an
NPM
team
and
community
to
collaborate
and
hopefully
move
our
C's
forward
and
to
address
any
concerns
and
work
through
features.
And
is
there
any
announcements
that
you
folks
have
on
the
call
before
we
dive
into
the
agenda.
A
Itemized
issues
to
github
discussions
so
are
you'll
have
seen
us
a
little
bit
sure
in
which
I
apologize.
That's
on
my
part
that
we're
going
to
be
testing
out
the
new
github
feature
for
discussions
in
our
RFC's
for
RFC's
and
questions
both
here
in
the
RCS
repo,
as
well
as
in
the
MPM
CLI
Reba.
This
should
help
a
bit
with
trying
to
deviate
or
delineate
essentially
between
you
know.
You
know,
topics
for
discussion
versus
more
feature,
driven
work
more,
you
know
more
focused
actual
issues
around
is
that
are
problematic.
A
Let's
say
within
the
RFC
grupo
itself,
we're
hoping
to
get
some
feedback
from
folks
are
Esau,
Wesson
and
Jordan
had
noted
some
of
the
drawbacks.
Apologize
for
the
spam
in
your
inbox
is
also
have
taken.
Note
that
you
know
discussion
threads
do
not
have
labels.
That
is
definitely
something
that
is
a
drawback,
and
so
the
automation,
I
think
that
will
have
in
place
going
forward,
because
these
agendas
are
automated.
A
We
do
pull
from
a
label
called
agenda,
so
issues
and
PRS
that
are
labeled
with
the
agenda
label
actually
get
picked
up
by
the
on
mission
that
we
have
in
place
across
all
of
our
repos.
So
we're
gonna
have
to
look
at
a
different
way
to
pull
in
some
of
these
discussion.
Threads
just
make
sure
they
aren't
lost
so
feel
free
to
ping
me
before
these
calls
in
case
there
might
be
something
that
you
notice
isn't
on
the
agenda
and
we
can
always
add
it
to
the
end
in
case.
C
C
We
could
also
figure
out
a
way
to
if
github
is
not
planning
on
adding
labels
to
those.
We
could
also
figure
out
a
way
to
automate
pulling
discussions.
If
that
would
be
helpful
and
I
know,
I
I
said
I
open
a
PR
and
never
did
to
get
that
enabled
on
this
repo.
But
you
know
now:
it's
probably
maybe
not
the
time
since
we
have.
A
I
think
there's
opportunity
to
potentially
look
at.
Maybe
it's
like
date.
So
most
recently,
bumped
and/or
commented
on
discussion
might
get
picked
up
by
that
automation.
I
think
potentially
could
be
some
piece
of
piece
of
data
that
we
could
use
to
delineate
whether
or
not
something
gets
added
to
the
agenda.
That's
kind
of
what
I'm
thinking
for
us
going
forward.
I,
don't
know
the
future.
A
This
essentially
addresses
some
or
tries
to
address
some
of
the
discussion.
We've
had
about
essentially
unraveling
or
withdrawing
support
or
intention
to
implement
RFC's
that
have
previously
being
ratified,
and
so
we
realized
that
going
through
and
grooming
our
backlog
of
things
to
be
implemented
that
some,
some
of
the
RFC's
that
we
had
previously
said
you
know,
got
a
stamp
of
approval
and
and
that
our
team
would
look
at
and
try
to
implement
and
no
longer
make
sense
or
that
they
are
essentially
associated
by
a
net
new
RFC.
A
So
hopefully
this
you
know
is
language
that
I'm
trying
to
propose
here
and
I'll
like
it
here
in
the
chat
for
everybody.
Hopefully,
this
sort
of
outlines
a
good
process
for
us
to
essentially
withdraw
support.
So
that's
PR
135
wondering
if
anybody
has
any
thoughts,
feelings
about
about
this
I
know
there
hasn't
been
any
discussion
on
it.
So
if
it's
uncontroversial
it'd
be
great
to
move
forward.
F
Like
I
haven't
actually
gone
through
and
digested,
this
apologies
apologize,
but
yeah
I
also
don't
have
really
strong
feelings
about
it.
As
long
as
there
is
some
kind
of
process
and
we're
not
you
know
under
the
under
the
mistaken
impression
that
we're
obligated
to
do
everything
that
our
past
selves
ever
thought
was
a
good
idea
which
can
be
kind
of
hazardous.
It's
it's
fine.
There
there's
a
handful
in
there
in
the
accepted
folder
that
I
feel
like
it's.
G
So
I
don't
have
any
issue
with
this
PR
and
with
the
general
concept
of
like
not
assuming
that
accepted
as
a
permanent
state,
but
it
seems
like
there's.
An
RFC
is
two
things:
it's
a
problem
statement
and
a
solution
suggestion
the
solution.
Suggestion
in
no
way
should
be
permanent
and
should
always
be
subject
to
evolution
and
breaking
changes.
G
Rightly
that's
House
members
for
but
ideally
the
problem
statement
is
something
that,
when
an
RFC
is
accepted
is
something
that
is
generally
considered
a
permanent
problem
to
be
solved,
which
would
mean
that
an
alternative
solution
is
always
fine,
but
if,
ideally,
it
would
address
that
use
case.
I
don't
want
to
suggest
that
it
be
like
set
in
stone,
but
I
like
I
would
like
the
spirit
of
it,
to
be
that
once
a
problem
is
agreed
upon
that,
it's
worth
solving
that
it
is
forever
worth
solving.
Somehow.
G
In
that
case,
the
stakeholders
for
the
original
problem,
the
folks
who
had
the
problem-
presumably
they
would
all
agree
with
it,
and
then
it
would
be
non-controversial
and
that's
exactly
why
I
don't
think
it
should
be
sentenced
on
but
like
if
it
shouldn't.
If
a
solution
becomes
unfeasible
that
shouldn't
unilaterally
make
the
problem
no
longer
a
desired
desired
to
be
solved.
Well,.
F
There
there
are
gonna,
be
cases
we're
speaking
extremely
meta
now,
but
there
are
going
to
be
cases
right
in
any
given
for
any
given
problem.
There
is
always
kind
of
a
null
the
null
solution,
which
is
we
just
accepted
that
this
is
a
problem
and
we
deal
with
it
and
and
don't
actually
have
the
CLI
address
it,
and
there
there
may
be
times
where
that
that,
like
non
solution
ends
up
being
the
one
that
we
do
settle
on
over
time.
So,
even
though
we
recognize
it's
a
problem,
we
explored
it.
F
G
G
B
Another
another
kind
of
solution
here
is
that
these
are
these
RFC's
are
accepted
via
pull
requests
and
they
can
be
withdrawn,
vehicle
requests
and
that
poor
equestria
we
have
documentation
about
who
created
the
initial
pull
request.
We
can
involve
them
and
it
can
be
optionally
more
of
a
discussion
so
like
here,
I'd
like
to
withdraw
this.
Here's
why
you
know
and
discussion
ensue
and
if
that
results
in
a
new
RFC,
then
great
yeah,
that's
great
yeah.
F
A
G
F
Yeah
I
was
just
gonna
say
as
long
as
the
like
when
we
move
it
from
accepted
to
unaccepted
or
however,
however,
this
process
defines
it
there
should
be.
Like
a
you
know,
a
bold
heading
put
at
the
top.
That's
like
this
is
why
we're
not
doing
this
thing
and
then
here's
like
here's
what
it
was,
and
that's
that's,
also
really
useful
to
have
those
like
rejected,
rejected
solutions
or
rejected
problems.
F
A
No
I
think
it's
just
a
good
I
know:
we've
talked
about
it
for
a
bit
so
I'm,
hoping
that
you
know
we
can
have
something
like
this
to
give
us
a
way
forward.
You
know
and
clean
up
our
backlog,
they're
awesome,
so
item
number
four
on
the
agenda
is
the
RC
for
removing
depth
from
NPM,
outdated,
I'm,
not
sure
if
there's
any
it's
here
or
if
you'd
like
to
speak
to
this
again
I
know
the
last
person
to
actually
comment
on
this
was:
was
you
Roy.
E
Yeah
I
don't
think
there
are
any
important
or
relevant
changes.
It
seems
from
last
week's
discussion
that
everyone
was
on
board.
Basically
the
syrups.
He
talks
about
removing
the
depth
blood
and
adding
a
new
one.
All
that
will
basically
just
display
all
outdated
packages
in
your
project,
so
I
unless
anybody's
the
games.
I
think
straight
forward
can.
C
E
It
seemed
like
on
v6
we
were
displaying
as
location,
basically
just
the
route
path
of
the
project,
and
we
were
just
showing
the
nested
packages,
the
nested
path
of
the
packages,
and,
in
this
case,
on
this
in
bloom,
b7.
We're
actually
gonna
take
the
physical
path
where
the
where
the
package
leaves
on
the
file
system.
This
is
the
only
change
in
information
that
is
gonna,
be
changing.
C
Yeah,
okay
could
I
propose
maybe
an
addition.
So
I've
been
messing
around
with
this
just
recently
so
and
I
found
that
a
couple
of
times
when
I
ran
it
I
was
like
I
wonder
why
that's
there
and
then
looking
just
at
the
physical,
you
know,
file
system
path,
didn't
tell
me:
I
had
to
do
an
NPM,
LS,
&
Co
that
was
brought
in
via
you
know.
Whatever
other
package
it
might
be
valuable
to
show
both
I
know,
I
would
probably
use
both
in
the
debugging
I
was
doing
the
other
day.
E
C
Know
it
could
be
multiple,
because
that
was
one
of
the
other
things.
I
was
trying
to
figure
out
the
difference.
I
had
a
package
that
was
I
had
two
versions
of
it
in
my
tree
and
both
were
outdated
and
I
wanted
an
outdated,
and
this
is
in
six
was
only
showing
as
one
which
I
think
was
I.
Don't
know
what
the
logic
was
on.
Why
I
was
only
showing
one?
Maybe
it
was
the
first
one
hit
anyway.
C
For
some
reason,
it
was
only
showing
one
of
the
versions
and
then
saying
this
is
the
you
know
the
version
I
want
here-
and
this
is
the
version
I
want
to
update
to,
but
then
I
found
it
other
another
spot
in
the
tree.
Where
was
actually
an
even
older
version
and
I
think
it
would
have
been
updated
via
NPM
update
but
wasn't
showing
in
the
outdated
I'm.
Not
I.
Don't
have
full
details
on
what
I
found
there,
but
it.
G
Was
definitely
in
Isaac's
new
NPM
audit
output
that
seems
like
it
has
attempted
to
tackle
the
problem
of.
How
do
you
display
one
dependency
that
may
come
from
many
places?
Is
there
a
chance
that
some
of
that
code
and
output
could
be
shared
so
that,
like
it,
builds
up
user
expectations
and
also
explains
the
provenance
of
the
package?
We.
F
Could
we
could,
we
could
probably
borrow
some
of
the
like
design,
language
and
concepts,
but
the
the
actual
output?
No,
it
would
be
okay,
it's
it's
a
different
kind
of
thing
right,
essentially,
what
we're
looking?
What
we're
dealing
with
is
the
design
challenge
of
displaying
a
a
dependency
graph,
displaying
information
about
a
dependency
graph
which
is
implemented
in
a
file
system
tree,
and
so
you
Wes,
it
sounds
like
you
ran
into
a
bug
in
v6
I,
don't
know
what.
C
F
F
F
There's
also
the
the
there's
kind
of
a
vague
idea
that
I
think
it's
still
just
the
level
of
like
me
and
Jordan
kind
of
hashing
it
out
in,
or
you
know
talking
about
a
little
bit
in
in
slack,
which
is
that
it'd
be
nice
if
you
could
pass
a
folder
path
into
NPM
LS
and
have
it
tell
you
like?
Okay,
what
what
is,
depending
on
the
node
at
node
modules,
slash
minimis?
F
Why
is
this
here
like
what
what
are
the
edges
on
it
and
so
on?
We
have
all
that
information
at
the
ready
when
we
run
our
load
actual
like
we
have
that
in
the
tree
shape
it's
just
displaying.
It
is
kind
of
challenging
in
a
way
that's
sort
of
ergonomic
and
useful
and
like
we're
most
enough
without
being
too
verbose,.
C
So
I
so
I
think
there's
two
points.
I
wanted
to
maybe
hone
it
on.
So
one
is
I
think
that
the
overlap
between
NPM
audit
and
NPM,
outdated,
slash,
NPM
update,
is
like
really
high.
I,
don't
see
a
end
user
experience
where
I
would
want
a
big
divergence,
because
it's
really
what
I'm
doing
is
hygiene
like,
and
this
is
why
I
was
you
know
talking
also
in
that
slack
I
feel
like
the
problem.
Right
now
is
our
hygiene
is
not
being
well
supported.
C
E
C
G
I
think
they're
they're
definitely
different
and
useful
views
of
your
dependency
graph.
One
of
them
is
what
stuff
has
vulnerabilities
like
what
stuff
is
the
security
team
angry
about
that
I
haven't
done
yet
another
view
is
what's
not
up-to-date
like
what,
in
general,
can
I
pull
in
newer
things
up
another
one
might
be
what
you
know.
What
parts
of
my
depth
graph
need
funding
another
right
and
the
another
one
might
be,
and
right
in
all
of
these
cases,
you're
gonna
have
direct
dips
and
you
even
have
transitive
deaths.
G
You're
gonna
have,
in
other
words,
you're
gonna
have
a
lock
file
or
not
right,
and
all
these
things
are
gonna
determine
actionability
you're
gonna
have
some
dependencies
like
are
there
for
more
than
one
reason?
Some
of
them
are
there
for
one
reason
right
and
like
you're
gonna
have
some
reasons,
meaning
like
X.
G
That
provides
all
that
information
can
then
be
used
as
a
trivial
building
block
for
other
things,
to
provide
different
views
on
the
dependency
graph
and
obviously
that's
like
a
big
set
of
changes
and
would
probably
require
some
architectural
changes
to
a
lot
of
these
commands,
and
possibly
some
breaking
changes
and
so
on,
but
like
the
like,
like
so
Wes
I,
would
say,
is
it's
not
all
just
hygiene
right
like
I?
Don't
most,
that
meant
much
of
the
time.
G
F
F
G
F
See
yeah
if
I
get
if
I
get
a
stack
trace
with
an
error
message
like
I
want
to
know
like.
Why
am
I
using
that
thing
and
there's
there
it's
really
challenging
when
I
see
you
know
when
I
see
two
copies
of
something
that
are
not
being
d
duped
in
NP
MLS
and
they're
they're,
the
same
exact
version
I'm
like
I,
want
to
know
why
I
want
to
know
like.
Why
is
this
not?
Why
is
this
being
nested
and
is
there
like
there's
something
I
need
to
do
as
a
result.
A
C
I
didn't
mean
to
fully
distract
I
just
wanted
to
talk
about
the
most
illogical,
yeah
well
yeah,
having
both
of
those
displayed,
the
logical
and
the
the
real
path
was
sort
of
where
I
started,
but
the
reason
I
want
that
is
because
I'm
trying
to
think
more
holistically
about
the
the
problem
of
developer
hygiene
around
these
dependencies
is
why
I
led
that
way.
So
I
track
ting
they're
part.
F
Of
a
you
know,
another
another
thing
that
might
be
interesting
to
explore
is
like
a
you
know:
NPM
outdated,
NPM,
update
that
also
fixes
audit
vulnerabilities
so
run
the
you
know,
run
the
Advisory
check
and
then
run
an
NPM
update
to
which
will
be
smart
enough
to
avoid
any
vulnerable
versions
to
the
extent
possible
sort
of
like
doing
doing
vixen
and
Kim
update
at
the
same
time.
Yes,.
C
So
I
see
this
really
having
like
a
strong
corollary
to
linting
right.
So,
like
I'm
of
the
opinion
that
we
should
be
like
very
careful
about
what
linting
rules
we
add
and
only
add
ones,
we
can
fix
right
and
like
a
dependency
check
or
like
an
audit,
is
like
critical
in
terrors.
Fail
build
right,
whereas
like
outdated
is
like
a
lint
warning
right,
but
really
what
we
should
be
trying
to
do
is
just
avoid
displaying
these
to
the
user
ever
right
and
just
like
running
fix
or
whatever.
That's.
C
F
C
Yeah
I'm
definitely
so,
and
doctor
takes
a
long
time
to
run,
which
is
the
only
route
today
and
maybe
that's
something
that
can
be
fixed.
That's
the
only
reason
I,
don't
like
that.
It
makes
me
hesitant,
you
know.
Maybe
maybe
this
is
where
I
see
some
composition
would
be
really
nice
and
we're
outdated
is
sort
of
one
view,
but,
like
I
think
we
want.
You
know
some
hybrid
view.
That
is
a
mix
of
doctor,
and
you
know
we.
F
Also
I
mean
this
is
what
this
is
also
getting
to
is
is
something
that
we've
we
have
identified,
which
is
like.
How
do
we
we
right
now
right
now
in
the
g7
release
branch,
we
have
a
everything
that
does
an
NPM
everything
that
doesn't
harbor
star
EFI
goes
through
the
same
code
path
to
display
the
results,
so
we
always
get
the
same.
You
know
this.
Many
packages
need
funding.
You
have
these
many
vulnerabilities,
this
very
level
blah
blah
blah
added
this
many
things.
F
Remove
this
many
things
and
that's
just
like
the
really
terse
output
like
I,
installed
a
bunch
of
stuff
for
displaying
the
dependency
graph,
though
we
don't
really
have
much
consistency
at
all,
so
we
have
outdated,
which
is
kind
of
this.
Like
pseudo
table
type
thing,
we've
got
LS
which
pretends
that
the
dependency
graph
is
actually
a
tree.
F
We've
got
what
was
what
was
the
other
one
and
then
there's
autumn
without
fix,
which
is
displaying
your
vulnerabilities
in
a
also
kind
of
like
a
tree
structure
to
show
you
which
vulnerabilities
are
dependent
on
which
other
vulnerabilities
are
caused
by
which
other
vulnerabilities
so
yeah.
It's
it's
a
tricky
design
challenge
and
we
don't
have
a
full-time
designer
working
on
NPM,
so
I
think
that
that's
probably
the
biggest
way
to
frame
the
problem
that
was
like.
Let's,
let's
have
a
bigger
conversation
about
how
we
display
information
about
the
graph.
A
Specifically
bringing
and
to
be
mindful
time
to
bring
conversation
back
to
this
specific
RCE,
I've
noted
or
see
that
there
was
just
one
know
by
Isaac
Claudia
to
maybe
add
a
note
about
depth,
and
you
know
its
relevance
as
it
stands
today.
I'm,
not
sure
if
that's
a
blocker
I
feel
like
we
could
probably
move
forward
with
this,
though.
So,
if
anybody,
unless
anybody
else
has
any
like
like
major
issues
with
with
the
all
flag.
A
F
We
went
back
and
forth
on
this
a
little
bit
more
and
and
where
we
landed
was
to
change
the
the
spec
so
that
a
given
override
it's
basically,
the
first
match
is
the
only
one
that
will
affect
a
particular
resolution
and
then,
if
there
is
a
dot
member
like
a
single
string,
you
know
string
key
with
a
period.
Then
that
will
define
the
version.
F
A
C
A
G
Yeah
I
guess
my
feedback
is
still
kind
of
the
same.
It's
that
the
like
a
simple
boolean
of
that
there
are
types
here,
isn't
really
sufficient.
They
look
mean
there
needs
to
be
a
path
to
the
types
because
they
might
not
be
in
that
package
like
if
we're
trying
to
build
something.
That's
forward
forward-looking,
so
I
think
it'd
be
nice
to
hear
back
from
the
typescript
team
about
the
possible
feasibility
of
that
sure.
A
A
D
E
D
If
you
want
to
filter
out
passing
a
workspace,
we
will
just
settle
for
the
glass
or
do
we
really
use
the
full
NPM
workspace
and
the
third
proposal
I
had
there
was
something
fancier,
just
like
it's
like
using
column
and
yeah
yeah
I
would
like
feedback
on
that.
I
think
that's
quite
actionable,
and
it's
just
like
it
small
back
yeah
we
can
get
over
with.
C
C
He's
saying
I,
don't
think
they're
the
same
I
think
that
was
what
I
was
trying
to
I.
Let
me
just
pull
up
their
Docs.
You
do
have
a
link
down
here,
because
I
think
workspace
will
operate
on.
One
and
workspaces
will
operate
on
multiple
right.
Isn't
that
what
the
how
it
works?
I
thought
there
was
two
commands:
yeah.
A
G
It
might
be
more
helpful,
rather
than
first
diving
into
the
bike
shed
about
the
CLI
spelling
to
like
list
out.
What
are
the
use
cases
like
in
pros,
like
I,
want
like
I
want
to
do
this
I
want
to
do
this
and
then,
like
from
those
say
like
this,
is
the
information
I
have
to
provide
in
order
to
do
that,
and
then
look
at
that
set
and
see
if
there
are
groupings
that
make
sense,
maybe
it's
all
one
command?
G
B
B
B
Yeah
and
I
guess
to
kind
of
seed
that
a
little
bit
I
know
there.
Were
there
been
some
comments
that
workspaces?
You
know
the
thing
that
I
was
kind
of
proposing
was
with
similar
to
workspaces
and
I
kind
of
I,
just
kind
of
got
a
first
look
at
the
workspaces
stuff.
Does
anyone
have
kind
of
an
overview
of
just
like
oh
well?
This
is
you
know,
per
Jordan's
comment.
This
is
it
like
I
want
to
be
able
to
run
this
and
like
this
is
the
the
thing.
D
B
D
Right
right,
to
recap,
a
little
bit
the
initial
implementation
of
workspaces,
just
like
enabling
the
NPM
CLI
to
install
workspaces
if
they're
defined
that
is
already
ratified
and
already
implemented
coming
to
link
m7.
So
what
we
are
discussing
now
is
more
workspace
related
functionality,
so,
specifically
around
running
commands
across
the.
D
So
you
can
now
see
me
mean
right:
okay,
yeah,
so
yeah.
So
basically
the
goal
here
is
to
be
able
to
run
commands
across
workspaces
that
you
have
and
yeah
I
think.
Also
one
thing
we
discussed
in
the
initial
workspaces
for
requests
RFC
was
that,
ideally,
like
a
bunch
of
commands
will
just
like
by
default,
they
will
just
run
across
all
workspaces.
D
So
what
we
have
today
is
that
the
workspaces
are
part
of
your
like
the
main
install
tree,
so
kinda
makes
sense
to
have
these
commands
behaving
that
way.
So,
like
commands,
like
fun,
LS
updated,
they
would
like
take
it
in
cool
from,
although
your
workspaces
into
accounting,
if
you
run,
if
it
happens,
that
you
run
them
in
the
top
level,
so.
D
A
Workspace
so
I
think
that's
the
piece
that
you
when
you
want
to
separate.
So
the
controversial
part
is
probably
anything
yeah
any
command
that
becomes
workspace
aware.
So
that's
almost
you
know
that
can
be
almost
ratified.
I.
Think
that's
kind
of
like
the
cows
born
like
install
just
works
similar
to
LS,
should
just
work,
and
is
it
fun,
should
just
work
TM
for
quotation
marks.
A
A
G
D
G
D
It
should
definitely
be
like
it
is
the
subset
for
all
of
these
commands
over
here
right,
so
so,
for
each
one
of
these
commands
you
should
be
able
to
like
NPM
workspace
use
the
name
of
one
of
the
workspaces.
You
have
and
run
that
specific
command
right.
So
so
here
tasks
like,
but
it
can
be
just
like
one
of
the
users
quits.
You
have.
C
A
D
A
B
Yeah
so,
first
of
all
I
should
you
know
preface
this.
As
I
said,
it
began
I'm
somewhat
of
a
newcomer
to
NPM
and
so
I.
You
know,
I
haven't
used
some
of
the
features
like
yarn,
workspaces
and
stuff
like
that.
Already
that
it's
very
possible
that
that
could
solve
my
problem.
I
think
that
the
as
I
was
kind
of
reading
on
it
and
reading
kind
of
looking
at
kind
of
how
it
works
versus
what
I
was
proposing.
B
I'm,
realizing
that
some
of
this
to
certain
degrees,
a
paradigm
issue,
and
it's
it's
in
many
ways,
it's
funny.
It's
in
many
ways
comparable
to
object,
oriented
paradigm
versus
functional
paradigm,
where
I'm
looking
more
for
I
want
it
to
be
explicit,
I
want
it
to
be
functional
and
what
workspaces
are
as
more
of
a
kind
of
stateful.
B
You
know
internally
stateful
paradigm,
which
you
know
it's
just
I,
think
to
a
certain
degree
you
either.
You
know
it's
funny,
because
it's
also
JavaScript
is
a
dual
paradigm
language,
and
so
it
kind
of
makes
sense
that
our
package
manager,
it
was
struggling
with
paradigm
ideas
as
well,
but
I
want
to
preface
it
with
that,
because
I
realized
that
this
is
not
really
a
better
way
to
do
it.
B
B
So
basically,
the
problem
that
I
was
that
I
was
addressing
here.
I
do
a
lot
of
development
of
kind
of
interconnected
repos
in
various
scopes.
So
I
have
you
know
project
a
that
I'm
in
active
development,
on
that's
a
dependency
of
project
B,
which
I'm
in
active
development
on
and
unrelated
project
C
and
with
solutions
like
Laura
and
I
think
workspaces.
B
B
This
is
this
is
where
you
get
the
version
that
this
depends
on
so
just
npm
install
you
know
it's
it's
the
most
basic
command
and
it's
gonna
tell
you
exactly
what
you
need
to
do
again.
This
is
a
functional
program
concept.
It's
gonna
tell
you
exactly
what
you
need
to
do
to
fulfill
that
dependency
via
this
kind
of
syntax,
where
you
can
say:
okay,
well,
this
isn't
published
yet
so
just
link
it.
B
You
know
you
have
to
link
it
into
this
and
it's
got
to
be
at
this
version
and
this
version
is
found
at
the
branch.
You
know
that
it's
kind
of
unstructured
data
about
like
we're
gonna
find
this
version.
So
again,
I
mean
this
is
this
is
kind
of
that
was
that's
the
problem
that
I
confront
surprisingly
frequently
actually
I
just
ran
into
it
yesterday
and
you
know,
I
might
I
might
just
be
using
the
program
wrong.
B
C
No
raise
hand
but
I
would
like
to
add.
This
is
a
very
common
problem,
and
this
is
one
of
the
reasons
why
I
was
so
so
I,
don't
think
about
it,
I
think
about
it
slightly
differently,
I
think
about
it
as
like,
bottom-up
or
top-down.
This
is
a
bottom-up.
Every
low-level
package
can
say:
here's
like
all
the
things
I
need,
whereas
workspaces
is
like
there's
the
top,
the
top
level
thing
it
says
like.
Actually,
these
are
all
these
lower
level
things
fit
together.
C
B
F
F
So
the
the
use
case
here
is
valid,
and
it's
actually
kind
of
you
know
it's
essentially
the
same
set
of
needs
that
led
to
their
being
an
NPM
link
in
the
first
place.
The
there
are
a
couple
of
couple
of
challenges
with
this
proposed
implementation,
specifically
that
just
kind
of
make
it
somewhat
costly.
If
we
were
to
do
it.
The
first
is
just
that
it
adds
a
new,
a
new
spec
type
and
in
dependency
spec
type,
which
means
that
there's
just
quite
a
lot
of
places
where
we
kind
of
need
to
be
aware
of
that.
F
F
You
know
NPM
install
Fuat
link
pound,
whatever
comment
right
like,
and
so
that's
not
a
deal
breaker,
but
it
is
something
that
that
bumps
up
the
kind
of
implementation
costs,
which
is
worth
considering
the
the
other
thing
I,
which
I
think
is
probably
a
little
bit
of
a
bigger
like
conceptual
obstacle,
and
I
think
that
there's
probably
a
way
to
thread
this
needle
is
that
it
it
sort
of
nudges
people
towards
using
the
global
install
space
which
we
generally
try
to
avoid.
So
the
the
reason
being
that
it
I
mean
I
think
it.
F
C
C
But
so
I'm
there's
a
mix-and-match
scenario
here
that
is
very
common
I'm
working
on
Express
and
I've
got,
although
I
express
things
but
very
commonly
I.
So,
just
now
recently,
I've
been
working
on
pulling
out
your
the
arborists
test.
Server
right,
well,
I
pulled
in
some
Express
dependencies.
So
now
I've
got
those
cloned
locally
and
I'm
not
actively
working
on
them,
but
say
I
was
right.
B
Generally
established
like
central
location
for
these,
so
that's
basically
a
way
of
saying
you
know.
Whatever
your
file
system
looks
like
NPM
link
is
a
standard
mechanism
for
targeting
file
file
system
dependencies,
and
then
we
add
to
it
the
version
constraint
to
me
honestly
if
they're
one
thing
that
we
can
add
from
all
this,
it
would
just
the
enforcing
version
constraints
on
links
and
then
NPM
would
at
least
say
like
hey.
This
link
doesn't
point
to
the
version
that
I
need.
You
know,
do
something
about.
F
E
F
C
I
have
a
sort
of
odd
thing
that
just
connected
in
my
brain.
What
about
overrides?
What?
If
we
do
overrides-
and
we
just
say
that
in
order
to
do
this,
what
you
need
is
you
need
to
write
an
override
that
points
to
a
get
path,
with
a
version
semver
compatible
version
tag
in
it
or
something
right
like
I'm
spitballing
but
like
it
seems
like
there's
some
overlap
here
that
could
get
us
the
result
we
want
without
having
to
do
something
that
we
weren't
already
planning
on
doing.
B
C
F
F
That
involved
mini
pass
when
you
cross
pipeline
mini
passed,
flush,
make
fetch
happen,
NPM
registry
fetch
and
like
the
only
way
I
could
get
it
to
happen,
is
if
all
of
these
things
were
being
used
in
concert,
and
so
it's
kind
of
like
bouncing
around
between
different
repos.
So
what
what
you
don't
get
by
an
override
that
points
at
a
git
ref
is
I,
don't
get
the
v
lo2
just
like
CD
into
that
folder.
Add
some
logging
and
then
run
the
test.
E
F
Other
place
and
have
it
all
just
work
so
like
yeah,
the
way
that
I
I
mean
my
my
standard.
Ammo
is
I
just
edit
folder
files
in
the
node
models,
folder
and
that's
I-
think
that's
actually
what
a
lot
of
folks
do,
but
that
that
does
feel
a
little
gross,
and
it
requires
that
you
know
a
lot
about
the
implementation
details
well,.
B
C
And
you
can
achieve
that
today
with
NPM
link
as
well,
which
you
know
again
has
its
own
problems.
I
mean
part
of
the
problem.
Is
the
node
module
resolution
then
is
detached
right.
So
that's
what
workspaces
solves
by
hoisting
right.
So
as
soon
as
you
go
into
this
simile,
you
know
other
location
you've
now
like
if
they
were
sharing-
and
this
particularly
happens
with
like
react
and
front-end
stuff
right.
C
If
they
rely
on
sharing
a
react
version
you
you
can't
simulate
that
over
because
now
that
one
needs
a
react
over
there,
it
won't
be
able
to
find
it
right
when
you're
bundler
runs
or
whatever
I
mean
the
or
or
if
it's
a
back-end
server
side
rendered
react
right.
Node
will
start
up
and
and
then
it'll
hop
over
there
and
now.
You'll
have
two
versions
of
react
right.
A
Time
yet
we're
already
about
five
over
and
I
do
want
to
get
make
sure
that
we
get
some
of
the
discussion
actually
put
back
onto
this
PR
I.
Think
a
good
few
couple
notes
West's
that
you
made
in
terms
of
the
overlap.
Some
the
existing
things,
we're
looking
at
in
terms
of
overrides,
might
help
solve
for
this,
and
workspaces
might
help
solve
for,
for
some
of
those
use,
cases
that
kls
and
I
would
love
to
hear
any
other
recommendations
actually
in
the
threat.
F
Been
helpful
to
just
kind
of
dig
into
the
the
need
here,
a
little
a
little
bit
more
than
Y,
so
I
will
try
to
capture
some
of
my
concerns
with
the
with
the
implementation
proposed
and
we
can-
and
we
can
just
kind
of
add
that
to
the
to
the
constraint
list
and
just
explore
offline
a
little
bit.
I
think.
B
And
actually,
just
a
just
a
final
comment
here
when
you
look
at
it,
npm
install
so
when
you
npm
install
a
package
on
the
command
line
it
assumes
at
latest
I.
Look
at
link
is
basically
doing
the
same
thing,
and
so
you
know
looking
at
this
kind
of
a
mirrored
syntax,
you
could
envision
like
NPM
link,
you
know
minimis
at
some
version
and
then
that
would
have
had
this
version
constraint
to
linking
so
so.
F
B
B
F
B
F
D
D
A
D
A
Thanks
for
your
jump
down
and
explaining
that
thanks
for
everybody
else,
where
I
think
you
were
taking
great
notes,
we'll
love
to
see
those
get
added
to
the
repo
and
hopefully
we'll
keep
up
discussion
and
further
our
C's
in
the
repo
itself
and
I'll,
see
you
folks
in
either
a
week
or
two
weeks
depending
on,
if
we're
doing
a
deep
dive
next
week,
so
I'll
post
a
thread
about
that
in
the
actual
repo.
So
I
look
forward
to
talking
to
you
folks,
soon
sure.
Okay,
thanks
again
everybody
thanks.