►
From YouTube: Open RFC Deep Dive Meeting - Wednesday, March 11th 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.
B
B
So
this
one
can
be
discussing
workspaces,
oh
yeah,
everything
about
workspaces
and
come
to
an
agreement
so
that
we
can
ratify
the
DRC
and
move
on
with
implementing
the
actual
workspace
feature.
So
to
start,
maybe
with
the
agenda
here.
Maybe
we
should
do
a
little
round
of
introduction.
I
can
start,
my
name
is
read
or
no
I
work
in
the
open-source
team,
with
our
Syrian
Isaac
at
NPM
and
maybe
Darcy.
You
wanna
go
next
sure.
D
B
A
B
Hello
very
busy
right
now
so
yeah,
so
we
should
probably
well
I,
don't
think
announcements,
it's
an
item
that
will
go
into
the
deep
dive
get
rid
of
it.
And
yes,
let's
start
talking
about
workspaces,
so
basically,
yeah
and
PM
wants
to
introduce
support
for
installing
workspaces
one
of
the
things
with
data
for
DRC.
We
try
to
source
feedback
from
the
community
and
get
like
an
ideal
RFC
and
right
now
we're
going
through
the
process
of
like
starting
thinking
about
implementation
and
trying
to
come
up
with
an
actual
initial
implementation.
B
That
would
make
sense
from
the
technical
point
of
view
and
but
also
getting
a
lot
of
these
ideas
that
we
source
from
the
community
things
that
people
want
to
see
in
that
the
initial
support
so
yeah.
That's
what
we
want
to
ratify
today,
right
so
yeah.
Maybe
we
should
probably
start
defining
the
initial
scope.
B
What
the
NPM
CLI
needs
to
do
right
to
in
order
to
support
the
workspaces
and
basically
like
the
RFC
identified
three
main
things:
the
ability
of
rating
the
configuration
for
workspaces
in
which
we're
basically
following
the
lead
for
existing
support.
There
is
for,
like
yarn
workspaces,
so
basically
define
a
workspace,
is
key
in
your
package.
B
C
B
Yeah
right,
so
we
kind
of
starting
yeah,
we
kind
of
start
into
the
implementation
on
arborist,
which
yeah
basically
is
the
thing
that
those
incoming
stone
right
now
for
NPM,
seven
and
yeah.
So
that's
the
I
think
they're.
If
the
main,
probably
the
main
thing,
they
want
to
discuss
with
probably
Jordan
class
that
they
brought
up
during
the
RFC,
the
possibility
of
installing
things
in
a
more
flexible
layout
other
than
like
the
usual
mono
repo.
B
So
basically,
Wes
has
been
advocating
for
a
less
mana
repo
centered
approach,
where
you
could
not,
maybe
not
house
all
the
things
I
saw
the
things
the
top
and
have
package.
Oh
this
sub
package,
leaving
in
a
more
independent
way,
so
that
you
can
use
them
shuffle
them
around
like
a
jack
the
package
and
then
be
able
to
to
run
that
in
isolation.
So
with
the
about.
B
B
B
We
just
want
to
be
sure
of
what
we
are
signing
up
for
right
in
the
longer
term,
the
very
long
term,
with
the
workspace
support
so
yeah,
we're
kind
of
like
thinking
about
doing
more
lightweight
approach
to
start
with
and
going
with
this
thing
that
makes
more
sense
for
arborist,
which
is
basically
hoisting
everything
to
the
top
so
living
in
a
more
mono
repo
Center
for
this
initial
implementation.
But
we
want
to
make
sure
that
we
get
like
we
don't
we
don't
just
get
into
a
corner
where
we
cannot.
B
C
C
You
know
a
folder
just
in
your
in
your
repo
somewhere
in
your
project
somewhere,
and
then
you
have
a
link
dependency
on
that
that
folder.
Let's
say
it
contains
some
some
package
which
is
sort
of
like
that,
the
minimum
you
know
the
the
bare
minimum
like
atom
of
what
a
workspace
is:
it's
essentially
a
folder
that
has
other
packaged
folders
within
it,
and
then
those
things
gets
in
lived
around,
and
so
with
that
top-level
DEP
has
a
has
a
dependency
on
that
symlink
package.
C
So
we
can.
We
can
say
everything
you
know
my
workspaces
is
like
packages
slash
star.
Then
then
I
can
say:
okay
find
all
the
packages
in
that
folder
and
then
treat
all
of
them
as
if
they
were
a
link
dependency,
so
create
the
symbol
Inc
up
to
the
top
level.
If
they
depend
on
one
another,
they'll
be
automatically
deduct
and
any
dependencies
that
they
have,
it
will
hoist
up
to
the
top
level
in
the
most
efficient
way
possible.
So
this
is
not
so.
This
is
a
good
approach.
C
If
you're
doing
things
in
a
workspace
in
a
mono
repo
centric
way,
but
it
does
not
address
the
need
of,
let's
say:
I
have
a
bunch
of
projects
in
my
like
you
know,
projects
folder
and
then
completely
out
of
band
and
not
part
of
the
repo
at
all
I
create
a
like
a
package
JSON
or
in
that
root.
Folder.
That
just
says:
ok,
all
of
these
things
or
packages.
C
C
I
would
certainly
use
this
and
it
would
be
nice
to
not
have
to
migrate
everything
into
a
mono
repo
in
order
to
use
it.
That
being
said,
if
we
don't
put
things
in
them
on
a
repo
centric
way,
then
what
that
means
is
every
one
of
those
sub
packages
needs
to
have
its
own
package
lock
file,
as
well
as
have
those
things
sim
linked
into
into
them,
so
that
I
can
CD
into
that
folder
and
NPM
will
know
like
when
I
run,
npm
l
LS,
it
won't
look
like
there's
a
bunch
of
missing
dependencies.
C
The
the
challenge
with
doing
that
is
it's
it's
strictly
an
implementation
detail,
and
it's
not
something
that's
impossible,
but
it
is
something
that
just
adds
additional
work.
So
the
challenge
there
is
managing
managing
those
metadata
files
in
multiple
different
locations
instead
of
having
kind
of
one
authoritative
package
lock
or
shrink
wrap
for
the
project
from
from
arborist
point
of
view,
and
the
second
challenge
is
creating
links
to
a
single
thing
that
are
in
multiple
places.
So,
for
example,
I
have
this
thing
in
packages
/foo
and
it
has
a
dependency
on
packages.
C
Slash
bar
I
need
to
be
able
to
tell
arborist
like
yes,
I
know
that
your
dependency
is
being
met
by
this
root
level
link
but
go
ahead
and
also
create
a
second
link
for
that
one
as
well,
and
so
the
way
that
you
know
as
we
were
going
through
this
implementation.
We
realized
all
these
things.
Kind
of
are
probably
a
good
fit
for
a
v2
of
the
the
workspaces
feature,
and
it
would
be
great
to
kind
of
take
the
shortest
possible
path
to
something
something
workable.
E
C
C
B
E
And
as
Wes
had
pointed
out
like,
if
there's
the
appropriate
hooks,
you
could
easily
imagine
something
where,
like
post
workspace,
install
you
like
move
the
node
root,
node
modules
to
workspace
modules,
and
you
like
update
the
symlinks.
So
they
still
work
or
something
right,
and
that's
also
fine
like
as
an
MVP
to
just
like
leave
the
hooks
for
user
land
to
add
on.
But
my
what
I'm
trying
to
stress
is
that
I
want
to
make
sure
that
those
those
workflows
are
explicitly
documented.
Even
if
they're
not
supported
in
be
one
two,
three
or
ever
yeah.
B
C
A
Yeah,
so
just
quickly
to
follow
up
on
what
Dorn
was
saying
like
and
I
think
I
mentioned
to
you
before
this
call
actually
would
be
good
to
just
and
I
actually
reference.
The
changesets
dictionary
might
be
a
good
idea
for
us
to
create
some
sort
of
document
like
that
in
terms
of
the
language
that
we're
using.
So
when
we
reference
something
like
mono
repo,
we've
clearly
defined
what
we
like
what
that
means
to
us
which
might
help
the
obvious
gave
like
some
of
these.
A
You
know
some
that
confusion
or
just
like
clearly
define
what
we
think
that
means
to
us,
so
that
if
other
people
have
a
different
definition,
then
they
just
know
that
that
deviates
or
like
that
they
can
maybe
use
a
different
term.
But
when
we're
talking
about
mono
repo,
we're
talking
about
something
else
like
this
is
what
we
mean
by
that
and
we're
we're
solving
for
x
use
case.
You
know
that
we
clearly
have
defined
verbiage.
A
That
we
can
all
agree
upon
are
that
we
can
at
least
point
to,
and
so
I
just
linked,
changesets
dictionary,
which
has
you
know
at
least
some
definition
of
the
workspace.
In
some
definition,
and
around
some
other
things
there,
which
I
think
is
at
least
a
good
good
reference
and
something
we
might
want
to
adopt
in
in
terms
of
like
having
these
things
defined
so
that
we
can
better
speak
to
them.
Yeah.
B
It's
a
great
point:
I'll
definitely
take
that
there's
a
little
takeaway
from
updating
the
RFC
right
after
a
call
and
but
also
yeah
I,
like
the
Georgian
suggestion
like
trying
to
document
some
of
the
unsupported
use
cases
that
we
are
aware
of
right
now
at
the
moment
of
the
rectifying
this
RFC
right
so
that
we
can
follow
up
and
like
and
people
can
actually
comment,
maybe
their
favorite
workload,
I
could
say:
there's
there
seems
to
be
like
many
flavors,
so
the
favorite
flavor
is
not
there.
Maybe
they
can
raise
attention
to
that
like.
E
Any
other
useful
thing
that
may
come
out
of
that.
So,
for
example,
one
thing
I
wished
NPM
in
it
had
done
since
day.
One
is
ask:
is
this
an
app
or
a
package
like?
Are
you
publishing
it
or
not,
and
the
and
that's
because
like
if
it's
an
app
it
should
start
out
private.
True
and
like
should
probably
you
know,
should
have
had
a
shrink
wrap
file
or
you
know
in
as
soon
as
that
was
a
thing
and
so
on.
E
If
so,
here's
how
you
should
configure
things
and
then
like
that,
may
even
be
a
simplification
of
the
product
where
you
don't
need
a
lot
of
those
things
to
be
specified
in
package.json,
because
you
just
have
some
sort
of
like
workspaces.
Workflow
equals
one
two
or
three
and
then
like
overwrite
a
few
things,
but
like
there's,
no
way
to
know
until
we've
kind
of
listed
out
the
things
that
we
think
makes
sense
like
it
worked.
I
want.
C
To
I
want
to
circle
back
to
some
of
the
stuff
that
you
brought
up
Jordan
from
the
point
of
view
of
you
know
the
way
that
we're
kind
of
using
the
term
in
this.
In
this
discussion
and
in
other
discussions
around
the
work
spaces
feature
mono
repo
does
not
imply
a
particular
source
control
system,
but
essentially
what
mono
repo
means
is
I
have
I
I
expect
to
always
download
all
of
like
always
check
out
and
track
all
of
these
different
packages
in
in
kind
of
one
blog
right.
C
I
might
have
like
a
project,
slash
tap
folder
that
has
node
tap
and
tap
parser,
and
you
know
a
bunch
of
other
things,
T
report,
whatever
else,
but
it's
not
a
mono
repo,
because
each
one
of
those
things
you
can
very
easily
go
to
github,
slash,
tap,
j/s,
slash
whatever
and
get
them
as
just
kind
of
one
offs,
and
so
you
know
contrast
that
with
something
like
Istanbul,
where
there
is
a
single
get
repo
that
has
all
of
the
Istanbul
libraries
listed
out
or
jest
or
anything
else.
That's
currently
using
workspaces
with
yarn
it's.
C
B
C
That
being
said,
though,
you
don't
have
to
list
them,
I
mean,
especially
if
it's
internal,
only
right
like
you,
don't
have
to
list
them
as
dependencies
of
one
another,
if
they're
being
hoisted
to
the
root
level
in
a
mono
repo,
because
when
they
do
require
a
foo
they'll,
just
don't
get
the
one
that's
linked
right.
I
would
still
suggest
that
they
add
a
dependency.
Just
you
know
for
kind
of
good
hygiene,
but
that
should
so.
E
So
that
makes
sense
in
like
but
I
think
that,
like
for
open
doors
case
even
now
that
the
since
none
of
the
sub
packages
are
published,
it's
fine,
like
that's
perfect
right,
but
for
enzymes
case
for
local
development
and
for
testing
most
of
the
time.
I
want
to
be
able
to
to
do
that
exactly
that,
but
I
also
at
some
points
want
to
kind
of
downgrade.
C
C
C
Well
in
NPM
b7,
it
will
yeah,
if
you,
if
you
CD
into
those
folders
and
then
npm
install
with
a
with
a
linked
up.
It
will
work
it'll
work
that
way.
However,
if
you,
if
you
put
them
all
in
a
mono
repo
and
link
them
up
to
the
top
level
or
even
if
there
is
a
top-level
node
modules
that
npm
install
is,
is
aware
of,
it
will
try
to
hoist
them
all
the
way
up
it
again
so
and
I
think
for
b1.
That's
probably
fine.
C
The
the
interesting
thing
here
about
that
is,
if
we
do
have
this
D
hoisting
approach,
it
occurs
to
me
that
may
cut
off
the
use
case
where
the
root
project
is
itself
a
package.
That
depends
on
some
of
these
things
right
because
then,
when
you
do
you're,
essentially
breaking
that
things
dependencies,
but.
D
In
the
case,
where
you
have
that
conflicting
version
in
a
leaf
node,
it
automatically
just
like
you're,
installing
it
into
normal
mode
modules,
it'll
nest
that
version
of
it
underneath
that
leaf
right.
It
just
works
from
the
perspective
of
the
root
package,
which
is
not
a
pattern
I
really
like,
but
it
works
and
lerna
I
prefer
the
package
to
me
that
you
know
coordinator.
It's
it's
the
dev
tools.
It's
the
way
you.
B
D
The
nesting
really
I
mean
like
yes,
you're,
trying
to
hoist
everything
but
you're
not
trying
to
like
break
no
mom.
You
know
no
modules.
Resolution
right,
I
mean
it's
like
they're
still,
gonna
be
nesting.
D
C
There
is,
if
there's
a
conflict,
then
it
will.
It
will
resolve
the
conflict
by
by
adding
that
that
depth
a
kind
of
shadow.
The
room
where
we're
talking
about
is
mostly
in
the
case
where
there's
where
there
is
not
a
where
there's
not
a
version
conflict
or
where
the
version
isn't
even
listed
as
a
dependency.
It's
just
kind
of
a
unlisted
depth
that
gets
required
in
which
is
a
pattern.
I,
don't
I,
don't
love,
but
getting
to
a
point
where
you
know
like
PN
p.m.
C
D
I
was
gonna,
mention
PN,
P
ones,
approach
to
this
in
the
latest
major.
Basically,
they
have
a
route
link
for
all
the
all
of
the
transitive
modules,
but
every
every
leaf
has
its
own.
No
modules
has
their
explicit
dependencies.
You
know
sim
link
back
into
their
fancy,
symlink
registry
thing,
and
so
from
the
perspective
of
the
developers
running,
you
know,
working
in
the
Monterey
PO
to
Jordans
point.
They
can't
if
they
have
package
OMB
as
siblings.
A
can't
that
can't
require
B
unless
it
has
specified
I
have
a
dependency
on
B.
D
C
C
So
you
know
the
the
resulting
logical
tree
that
you
get
back
is
still
what
it
is
now
and
so
we
can
do
you
know
we
can
do
all
of
the
like
moving
and
shaking
and
shuffling
and
deduping,
but
then,
when
it
comes
time
to
reify
it
right,
we
can
sort
of
do
that
in
a
different
way
and
when
we
read
it
in,
we
can
also
sort
of
notice
hey.
This
is
like
using
the
new
format.
So,
let's
treat
this
like.
Instead
of
calling
this
a
link
tab,
let's
call
it
a
whatever
right.
C
Right
now,
if
you
run
arborist
on
a
PNP
M
tree,
it
will
work.
But
if
you
run
npm
install
on
a
PNP
M
tree
it
will,
you
know
pretty
much,
just
slaughter
it.
Yes,
you
know
it'll
club
or
anything
that
it
tries
to
update,
which
is
you
know,
maybe
what
you
want
right,
it's
probably
better
to
just
mow
that
lawn
and
and
now
you're
in
the
NPM
world,
rather
than
then
crash
and
burn
horribly
and
require
you
to
start
over
at
least.
B
E
C
B
C
C
Then
what's
gonna
happen
is
when
it
when
it
LS,
is
that
if
there's
a,
it
will
actually
walk
the
tree
and
it
will
walk
through
those
links
to
go
to
that
node
and
then
say:
does
this
node
have
it
steps
met
yes
or
no,
based
on
its
real
path
and
everything
else?
So
if
anything
is
missing
or
is
invalid,
because
the
version
range
doesn't
match,
then
yeah,
it
will
throw
an
error.
If
you
know
again.
E
Because
of
peer
depp's
and
the
peer
DEP
will
get
hoisted
to
the
root.
If,
let's
say
all
of
my
packages
have
a
peer
DEP
on
react
and
the
root
has
a
dev
DEP
on
react,
but
the
packages
do
not,
you
know
I
CD
into
the
packages
NPM
LS
I
would
think
would
fail.
Now,
if
you
see
the
end
of
the
packages
and
p.m.
LS
will.
E
B
What
would
you
scope
to
reach
you
yeah
yeah,
because
right
now,
so
we
because
we
are
the
original
RFC-
also
described,
having
like
a
package
lock
for
each
of
the
method
package,
so
we're
also
the
scoping
that
so
basement
right
now.
Everything
is
a
single
tree
for
arborist
to
install
and
there's
a
single
package
lock
at
the
top
level.
E
A
D
E
C
So
there's
two
things
you
got
up
here:
one
is
if
I
run
NPM
LS
from
the
root
should
it
should
it
find
problems,
and
the
answer
is
yeah.
It
absolutely
will
like
if
the
tests
in
there
would
fail.
If
the
depths
aren't
doing
that
properly,
it
will
fail
if
you're
running
it
from
the
root.
Now
you
CD
into
that
folder
and
run
NPM
LS
there.
You
no
longer
are
in
a
world
where
it
knows
about
workspaces,
but.
E
I
think
that's.
This
is
the
conceptual
issue
here.
Is
that
that
what
you're
saying
that
it
will
just
work
at
the
root
and
so
on,
like
that,
makes
sense
to
me
in
a
like
just
nested
package.json
scenario:
that's
totally
how
it
should
work,
but
workspaces
is
special.
It's
a
workspace.
It's
I'm
working
within
it
and
I'm
as
if
it
is
isolated
that
is
like
like
like.
If
you
open
up
a
workspace
in
vs
code,
it
doesn't,
it
doesn't
like
start
like
linting
the
files
outside
of
the
workspace
it
it's
right.
E
D
Projects
treat
workspace
as
an
interchangeable
word
with
leaf
package
or
root
note
or
the
whole
collection,
and
that's
extremely
ambiguous
I,
don't
believe,
like
I
I'm,
on
the
side
of
if
you're
in
a
Monterrey
PO
you've.
Also,
we
call
a
multi
package.
Repository
you've
already
opted
into
the
pattern
of
working
at
the
root,
because
that's
where
that's
the
unit
of
change
as
a
you
know,
conceptual
idea.
So.
E
E
D
Do
you
I
mean
if
you're
in
a
Monterrey
PO
it's
it's?
My
understanding
is
the
expected.
There's
a
relationship
between
the
packages
is
it's
not
just
a
big
blob
of
code
happens
to
be.
You
know,
n
number
of
packages,
its
packages
that
are
intentionally
put
there
for
a
reason,
and
they,
you
know
they
sure,
have
relationships
so
but.
E
In
most
cases,
all
the
babbles
are
not
all
installed,
in
most
cases,
right,
they're,
they're,
grouped
together
for
reasons
because
they're
related,
but
they're,
intended
to
be
often
used
in
smaller
subsets,
and
so
the
isolation
is
needed
in
order
to
ensure
that
that
will
work
correctly
because
it
doesn't
matter
if
babbles
mono
repo
works.
If,
when
they
publish
things,
never
all
their
users
are
gonna
break
okay,.
C
So,
let's,
let's
zoom
out
on
this
a
little
bit
and
just
kind
of
like
tell
you
where
we're
at
with
v1
and
where
we're
gonna
get
to
in
subsequent
iterations
of
this,
because
I
think
everything
you're
asking
for
is
reasonable
and
it's
all
stuff
that
we
intend
to
do
in
subsequent
iterations.
But
a
lot
of
it
is
not
what's
gonna
happen
in.
C
Package.Json
repo,
because
we're
not
going
to
be
for
the
first
pass,
not
going
to
be
d
hoisting,
you
know
moving
those
those
links
into
each
folder
that
has
a
package.json
within
it.
I
think
it's
a
great
feature
and
I
think
it's
something
that
should
not
be
a
tremendous
amount
of
work
to
do,
but
for
the
initial
release
like
we're
just
trying
to
shave
it
down
to
like
the
minimum
possible
thing
that
is
actually
useful
so
to
to
west's
question
about,
like
the
reason
why
cross-linking
instead
of
hoisting
is
what
is
more
difficult.
C
So
if
we
want
to
move
those
things
into
each
child
package,
what
we
need
to
do
is
be
able
to
have
a
little
bit
more
elaborate
referencing
so
that
we
can
say
this.
This
node
in
the
in
the
arborist
tree
is
a
child
package
of
a
workspace,
which
is
a
special
kind
of
thing.
So
we
should
not
host
its
dependencies
and
its
dependencies
if
possible,
should
be
met
by
a
second
link
to
whatever
the
the
root
level
workspace
link
goes
to
again,
it's
software.
C
C
Of
those
down
packages
right,
otherwise,
you
see
the
end
of
that
folder
and
it
doesn't
have
a
lock
file
and
you
install
I
know
it
does
have
a
log
file
and
things
are
all
kind
of
a
mess.
So
we
need
to
update
the
the
shrink-wrap
class
and
the
way
that
we're
handling
that
right.
Now
we
just
kind
of
slap,
a
shrink,
wrap
object
on
the
root
level
node
and
that's
the
only
one
that
gets
saved
after
an
install.
C
Work
space
can
mean
the
child
package
and
with
the
implication
that
I
should
be
able
to
work
on
it
in
isolation
from
everything
else,
as
Jordan
was
kind
of
bringing
up.
Workspace
can
also
mean
well.
This
is
the
this
is
the
Babel
workspace,
and
each
of
these
packages
are
pieces
of
that
Babel
workspace
that
I've
heard
people
use
it
that
way,
which
is
completely
the
opposite.
C
E
Mean
NPM
can
certainly
define
new
terms
here.
Whatever
terms
NPM
uses
will
override
the
any
other
usage
of
terms
in
the
ecosystem.
So
if
the
word
work,
space
itself
is
poisoned,
it's
totally
fine.
If
we
can
come
up
with
reasonable
names
to
better
describe
the
terms
like,
even
though
everyone
wants
NPM
workspaces
feature
like
they'll
get
over
it.
If
the
words
are
meaningful
and
not.
C
Especially
if
we
have
some
some
reasonable
way
to
translate
right,
if
we
can
say
look
if
you
said,
if
you
have
a
packaged
up
JSON,
that
has
the
word
workspaces
in
it.
We
know
that
that
actually
means
X
and,
like
that's
fine,
so
yeah
I'm
with
you.
What
we
probably
will
end
up,
maybe
moving
to
a
different
terminology
or
something
but
yeah.
B
E
D
B
C
The
the
key
in,
if
you
do
the,
if
you,
if
you
don't
set
workspaces
in
your
route
as
a
array,
the
the
key
that
defines
all
of
your
child
works
bases
or
the
projects
in
your
workspace-
is
packages
within
the
garden
presentation.
So
yeah
we
just
make
a
top-level
key
called
packages,
and
we
just
go
with
that
and.
A
A
B
B
B
E
C
C
C
E
B
B
C
It
is
actually
a
problem
if
you
have
a
workspaces
declaration
in
an
installed
package.
Json
all
that's
gonna
happen
is
it's
gonna
say?
Well,
let
me
let
me
glob
for
all
the
things
in
my
in
my
folder
that
have
that
are
in
that
list
and
if
any
exist,
a
lot
of
workspace
edge
for
them
and
then
I'll
simulate
them
into
my
know.
B
E
C
Like
to
see
these
kinds
of
desert
island
scenarios
written
out
in
JavaScript,
rather
than
ending
in
spoken,
English
I
mean
there's
probably
some
interesting
demons
there.
The
one
easy
way
to
stop
at
least
the
problem
that
you
just
brought
up.
Is
we
don't
allow?
No,
we
don't
scan
node
modules
when
we
do
this
glob
right,
like
that's
pretty
easy
to
do.
Yeah.
C
D
There's
code
in
learner
to
support
people
having
glob
stars
as
their
package
in
that
package
config
and
avoiding
reaching
into
node
modules.
It's
extremely
annoying
and
I
wish
you
didn't
have
to
do
it
but
open
source.
The
problem
being
I
quote:
why
wouldn't
a
workspace
field
in
a
and
I
can
note
in
a
node
module
dependency
that
should
be
treated
like
a
package
lock
inside
of
a
tarball
like
it's
just
it's
ignored
to
know,
but
why
would
we
be
even
considering
this
as
I
think.
C
B
B
E
So
I
mean
that's
good
and
I'll.
Try
and
take
a
look
whenever
there's
an
implementation
pure
up,
I'll,
try
and
see
if
I
can
suggest
some
test
cases,
but,
like
my
very
strong
suspicion,
is
that
we're?
It
would
be
better
if,
first
of
all,
if
workspaces
wasn't
an
estoppel,
but
even
if
it
was,
if
that,
if
it
very
explicitly,
never
did
anything
inside
node
modules
and
obviously
I
hope
that
the
globs
also
respect
get
ignore,
because
otherwise
it's
a
huge
mess.
C
Yeah
so
that
I
mean
then
we
again
just
in
the
interest
of
sort
of
simplifying
things.
I
was
wondering
and
I
think
we
need
to.
We
would
need
to
kind
of
do
some
investigation
to
see,
but
I
was
wondering
if
it
might
make
sense
to
not
support
globs,
or
at
least
not
the
full
flow
of
implementation,
or
this
the
the
reason
being.
C
E
B
C
We
also
have
that
in
like
how
we
treat
the
files
array
and
I
think
the
I
think
the
right
answer
is
we.
We
do
something
very
similar
to
how
an
impact
list
works,
and
essentially
you
know
at
some
point.
We
take
the
thing,
that's
that
Roy
Road,
which
is
just
using
node
glob,
and
we
replace
it
with
something
very
similar
to
an
impact
list
which
walks
walks
the
tree
based
on
the
the
files
away.
B
B
B
Yeah
I,
don't
know
yeah
I,
don't
know
to
want
to
stick
around
for
maybe
a
couple
more
minutes,
even
that
we
start
a
night.
But
if
not,
we
can
also
wrap
up
and
continue
on
in
the
ecto
in
RFC
call,
but
I.
Think
I
haven't
really
have
a
good
idea
to
at
least
ratify
the
installation.
Part
I
will
definitely
probably
want
to
cover
the
sub
commands.
I
know:
I
have
a
big
open-ended
question
on.
B
C
Yeah,
there's
a
ton
of
there's
a
ton
of
work
to
be
done,
I
think,
and
it's
it's
mostly
just
like
a
long
laundry
list
of
bike
sheds
to
be
painted
around
like
what
what
exact
output
do
you
get
from
n
can
tell
us
when
you
run
it
into
a
brutal
workspace.
If
I
have
a
hundred
packages,
it's
gonna
be
a
nightmare
to
like
mist
out
everything
right
and
like.
What's
the,
how
do
we
spell
workspace
or
ws
equals
whatever
like
we
can?
We
can
have
all
those
discussions.
C
The
much
harder
stuff
is
like
technically,
what
are
we
doing
and
like?
What
are
we
linking?
What
are
we
hunting
until
next
time?
So
I
think
you
know
takeaway
here
might
be
to
you
know,
carve
carve
out
the
RFC
sort
of
scale
it
back
to
exactly
what
we're
going
to
be
implementing
and
be
one
with
a
with
a
probably
long
like
thoughts
for
next
steps,
section
for
all
the
stuff
that
we
discussed
for
curvy
or
earth
things
sure.
C
B
Yep,
that
sounds
good,
so
yes,
I
think
that
that
well,
it
might
be
enough
to
to
follow
up
on
the
next
open,
IRC
call
and
if
there
is
no
feel
free
anyone
if
anyone
wants
to
continue
the
conversation
when
we
have
C
itself,
if
anything
comes
up
that
might
be
actually
blocking
the
ratifying
or
anything
or
then
I
think
it's
fair
to
follow
up
on
the
PR,
and
we
can
continue
on
the
regular
webinars.
You
call
we
have
next
week.