►
From YouTube: Open RFC Meeting - Wednesday, February 24th 2021
Description
In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
And
it
looks
like
we're
live.
Thank
you.
Everyone
for
joining
another
fpm,
open
rfc
call.
Today's
date
is
wednesday
february
24th
2021
we'll
be
following
along
in
the
agenda
that
was
created
the
agenda
issue
that
was
created
in
the
fpm
rfcs
repo.
That
was
issue
number
330..
A
You
can
follow
along
and
and
feel
free
to
add
yourself
to
the
meeting
notes
doc.
The
hackmdtalk
there
that
I
just
shared
in
chat,
feel
free
to
add
yourself
as
an
attendee
as
usual.
A
These
calls
and
all
communications
on
the
rc's
and
and
all
on
camera
repos
are
covered
under
a
code
of
conduct.
So
we
just
ask
that
you
please
be
kind
when
others
are
talking,
raise
their
hand
and
I'll
call
upon
you.
If
someone
else
is
talking
and
yeah,
you
can
read
more
about
that
code
of
conduct
on
mpmjs.com
itself.
There's
a
link
there
in
the
issue
just
wanted
to
open
the
floor
for
folks.
If
there's
any
announcements
that
anybody
had.
A
If
not
the
one
announcement
that
we
have,
we
still
have
an
open
position
posted
on
the
github.com
careers
page.
So
we're
looking
to
build
up
the
team
a
little
bit
here
feel
free
to
share
that
with
your
networks.
If
you
would
like
and
yeah,
if
there's
no
other
announcements,
folks
or
or
news
that
folks
would
like
to
share,
we
can
dig
right
into
the
agenda.
So
the
first
item
that
we
had
was
issue
327,
I
believe
isaac.
This
was
yours.
A
A
No
you
just
joined,
but
did
you
want
to
give
an
update?
I
I
think
we
can
yeah.
B
So
we
we
did
a.
We
did
a
bit
of
investigation
on
this
and
and
decided
it
did
not
merit
further
discussion
in
a
in
an
open
rfc.
B
You
know
in
an
rfc
process,
basically
what
we've,
what
we
found
so
in
in
npm,
if
you
have
an
optional
dependency
and
the
the
platform
like
the
os
or
cpu
does
not
match.
What's
stated
in
the
package
json
as
a
requirement
for
that
for
that
package
we
don't
bother
to
install
it,
the
thinking
being,
probably
not
going
to
work
and
it's
optional
anyway,
and
there
are
packages
out
in
the
wild
that
depend
on
this
and
then
and
we
we
had
a
regression.
B
But
if
you
have,
let's
say
a
bunch
of
pre-compiled
binaries,
which
are
all
four
different
platform
versions,
and
then
you
have
them
all
listed
as
optional
depths,
with
the
understanding
that
you're
only
going
to
get
the
one
that
works,
then.
Obviously
this
is
a
problem
because
they're
pre-compiled,
so
there's
no
build
step.
B
While
we
were
investigating
that
we
found
that
npm-6
actually
would
install
a
mismatched
platform
optional
depth
if
you
had
specified
force,
and
the
reason
is
that
it
went
through
the
same
code
path
where,
if
you
did
npm
install
foo
and
the
op,
it
was
a
a
mismatch
platform.
We
would
just
ignore
the
warning
if
you
did
force
so
what
we
decided
was.
You
know
doing
this
for
optional
depths,
like
we
already
have
this
way
to
install
a
proper
dependency.
B
If
you
actually
depend
on
it
and
you
want
it
for
optional
depths,
you
really
don't
want
some
optional
dependency,
which
is
platform
specific
buried
deep
in
your
tree,
even
if
you're
installing
with
force-
and
if
you
do
want
it,
there's
a
way
to
get
it.
You
just
install
it
so
yeah,
so
we
just
decided
this
is
this:
is
a
foot
gun?
It's
a
foot
con
that's
been
around
for
a
long
time
and
it's
very
unlikely
that
anybody's,
depending
on
it,
behaving
the
way
that
it
is
so
we
went
ahead.
B
A
I
just
I
removed
the
agenda
label
from
it.
Any
other
comments
on
that
folks.
B
C
B
And
let's
totally
dig
into
that,
but
I
think
that's
unlikely
it's
it's
a
very
obscure
kind
of
a
thing.
A
Cool
moving
on
then
to
issue
number
325,
the
rrc
for
pre-installed
post,
install
scripts
on
a
single
package
installation.
I
believe
we
spoke
a
little
bit
about
this
last
week
and
I
see
that
there
was
some
update
between
our
last
call
looks
like
carl.
B
Responded
so
yeah,
so
I
think
the.
B
This
is
this
kind
of
gets
to.
We
we
discussed
this
a
little
bit
internally.
I
don't
see
carl
on
the
call,
so
I'm
gonna
just
kind
of
present
a
little
bit
of
context
around
this.
We
we
discussed
this
a
little
bit
internally
and
I
think,
essentially,
what
we
need
here
and
what
we
may
want
to
roll
this
rfc
into
is
the
need
for
a
a
general
purpose
like
the
package.
Tree
has
been
changed
script
because,
using,
I
think,
repurposing
pre-installed,
post
installs
is
sort
of
mixing
the
semantics
in
a
way.
B
That's
not
great
pre-install
post
install
should
be
do
these
things
when
you
install
this
thing
and
we
do
that
on
a
no
arguments-
npm
install
because,
presumably
you
you
need
to
act
as
if
you
have
just
been
installed
right,
that's
that's
kind
of
the
context.
You
want
to
get
your
project
into
when
you
run
npm
install,
but
if
we're
also
doing
that,
if
we're
running
the
top
level
install
script
when
something
else
is
installed
like
that's
kind
of
not
what
it's
for
and
it
mixes
the
the
semantics
of
when
that
script
gets
run.
B
So
what
I
think
we
very
much
need
is
a
like.
You
know,
on
on
mutation
type
script
or
something
that's
like
I've
added
a
new
dependency.
I
have
removed
a
dependency.
I
did
something
to
change
the
package
tree.
So
if
you
need
to
do
anything
because
every
time
the
package
tree
changes
go
ahead
and
do
it
now
and
that
seems
to
be
the
use
case-
it's
a
use
case
that
we
have
in
the
clay
ourselves.
C
Of
add
on
to
what
isaac
was
saying
the
to
me:
it's
pre-installed
post-installed
script
should
be
when
you
installed
this
package
into
a
different
project
and
that
the
completely
valid
use
case
of
I
want
to
be
able
to
run
some
scripts
when
someone
types
up
their
npm
install.
C
I
think
that
that
that's
the
use
case
that
should
have
something
else
right
like
I'm,
not
suggesting
we
deprecate
the
way
that
currently
works
or
anything
like
that,
but
that
like
when,
if
I
would
hope
that
this
mutation
hook
or
whatever
also
runs
when
I
type
a
bear,
npm
install
and
doesn't
run
when
my
project
is
installed
somewhere
else.
C
And
if
that's
the
case
then
to
me
that
that
actually
matches
my
intuition,
which
is
that
there's
a
difference
between
whether
it's
the
top
level,
the
app
or
whether
it's
as
a
package
in
someone
else
in
another
apps
tree
yeah.
So
does
that
align
with
your
thinking,
isaac.
B
B
Like
a
the
the
package,
tree
is
changing
script.
We
also
might
want
to
have
something
maybe
separate
from
that
or
maybe
one
thing
is
enough
to
satisfy
both
use
cases,
but
a
like
the
package
tree
is
being
reified
type
of
event,
because
there's
there's
kind
of
a
like.
If
you
have
a
shrink,
wrap
file
and
you
run
npm
install
with
no
arguments,
you
have
a
shrink
crop
file
and
no
node
modules
and
you
run
npm
install
we're
not
changing
the
ideal
tree.
We
are
reifying
it
and
and
like
so.
B
That
feels
somewhat
different
from
I'm
going
through,
and
I've
gone
through
and
resolved
all
your
dependencies
right.
So
if
you
run
npm
update
okay
well,
we
we're
changing
the
we're
changing
the
the
ideal
tree,
we're
changing
kind
of
what
is
in
the
lock
file
and
they're
they're
similar.
But
subtly
different,
I
mean
I'm
not.
C
Sure
I
mean
I
know
that
those
are
differences
in
the
npm
implementation,
but
I'm
not
sure
that's
something
developers
have
literally
any
concept
of.
I
think,
like
there's,
really
kind
of
two
directions
that
I
think
we
should
decide.
One
is:
do
we
go
with?
Do
we
list
out
the
use
cases
we
want
to
support
and
make
a
script
for
each
or
like
a
hook
for
each
or
whatever
you
want
to
call
it
or
do
we
have
one
big
old
hook?
B
So
I
think
the
answer
there
is
we
we
don't
describe
in
any
great
detail,
the
the
command
that's
or
the
change
that's
being
made,
because
it
gets
very,
very
convoluted
and
complicated
to
do
that.
I
think
the
the
the
npm
command
environment
variable
and
the
process
arc
v
should
really
give
you
everything
you
need.
If
you
need
more
information,
then
like
read
the
package
tree
or
read
the
package
the
package.json
like
and
we
can
have
a
pre
that
runs
like
the
the
main
script
and
the
pre-script
can
run
like
before.
B
C
Exactly
exactly,
and
so
I'm
saying
that
that
in
the
pre-step
you
can
look
at
the
file
system
to
know
what's
there,
but
you
need
to
have
some
way
to
know.
What's
coming
and
while,
yes,
you
might
be
able
to
infer
it
from
the
command
string.
That
seems
brittle
to
me
the
and
then
similarly
in
the
post
script
you'll
know,
what's
already
there,
you'll
know
the
after
state,
but
you
won't
know
you
won't
have
any
way
to
know
what
it
used
to
be.
C
Unless,
like
I
don't
know,
the
original
package,
json
and
log
file
are
put
in
a
temp
directory
and
those
file
paths
are
injected
as
environment
variables
or
something
right
like.
So
I
think
that
there's
there's
probably
some
there's
a
lot
of
exploration
to
be
done
there
to
like
figure
out
how
to
support
the
use
cases
so
that
the
proper
information
is
available,
and
I
I
really
would
dread
writing
or
maintaining
a
script
that
tries
to
look
at
how
the
exact
spelling
of
the
npm
command.
They
ran
and
then
figure
out
like
infer
what
it
did.
B
Yeah,
so
I
think
that
for
for
things
that
need
to
do
a
more
or
less
stateless
like
any
time
the
package
tree
changes,
I
need
to
update
my
bundles
right,
my
like
webpack,
bundles
right,
for
example,
like
you,
don't
really
need
to
know
the
pre
and
post
state
for
those
you
might
be
able
to
get
a
little
fancy
or
whatever,
but
like
you
can
also
just
look
at
file
change
times
and
stuff,
and
the
I'd
really
want
to
see
a
use
case
that
needs
that,
because
it
is
somewhat
costly
to
you
know,
both
in
complexity
and
in
time,
like
runtime
costs,
to
gather
that
info
and
make
it
available.
C
B
Yeah
I
mean
I
as
as
the
cly
maintainer.
I
I
very
much
want
a
just
just
tell
me
that
the
tree
has
changed
like
I'll
figure
out
what
I
need
to
do
as
a
result
of
that
change.
But
I
need
to
know
that
it
has
changed
and
I
think
that's
kind
of
the
the
use
case
that's
being
brought
up
in
this
rfc,
which
is
why
I
mention
it
or
rrfc.
A
Yeah,
so
just
to
be
mindful
of
time
here
also
they,
I
want
to
know
that
they
did
go.
Investigate
hooks,
which
I
mentioned
last
week
as
well,
are
hook
scripts
and
it
looks
like
they
filed
an
issue
saying
that
they
don't
seem
to
be
running
right
now.
So
it
does
look
like
that
might
be
a
bug,
because
those
also
should
be
at
least
a
way
to
be
kicking
off
events
and
like
post,
install.
A
A
I'm
not
saying
it's
the
right
solution,
but
just
want
to
say
there
is
a
solution
and
yeah
like
there's,
obviously
like
you're,
essentially
having
to
navigate
through
the
weeds
there,
but
it
I
just
want
to
at
least
update
that
it
does
seem
like
they
went
and
tried
to
look
at
hook
scripts
and
then
have
followed
up
with
a
bug
report.
So
that's
something
that
we
can
take
away
from
the
team
just
based
on
time
and
we're
only
on
the
second
item.
I'd
love
to
move
on.
A
If
there's
any
other
like
feedback
or
if
there's
a
net
new,
you
know
either
api
or
like
ability
for
us
to
expose
sort
of
like
plug-ins
or
something
into
arborists,
like
the
what
you're
speaking
to
isaac
with
like
other
life
cycle,
events
that
you
might
want
to
plug
into
specifically,
maybe
in
arborist,
then
maybe
we
should
start
a
separate
rfc
for
that.
Our
separate
conversation,
unless
it
makes
sense
to
just
like
carry
on
in
this
thread.
B
I
think
it's
fine
to
carry
on
in
this
thread,
I
think
also
so
gar
was
in
in,
is
in
process
of
like
organizing
and
and
bringing
some
some
structure
to
our
documenting
and
specifying
sort
of
what
what
life
cycle
scripts
we
run
today
and
in
what
contexts
and
kind
of
what
they
mean.
B
A
Cool,
so
if
we
can,
I
will
leave
that
open
for
now
we
can
leave
the
agenda
label
on
it
too.
If
there's
future,
you
know
updates
in
the
thread.
We
want
to
move
on
to
issue
and
rrc
324,
so
preferring
we've
closed
this
out,
but
it
was
preferring
pure
dependencies
over
regular
depths
when
both
are
specified-
and
I
think
you
were
the
last-
to
give
some
feedback
there
isaac
and
then
we
closed
this.
B
Yeah
we
we
went
ahead
and
implemented
that.
B
Yeah,
I
think
so,
I'm
just
kind
of
scanning
over
this
yeah.
We
went
ahead
and
implemented
it.
It
was
not
hard
to
implement
and
the
the
one
caveat
is
that
we
would,
I
think,
only.
B
Yeah,
we'll
only
save
it
as
a
pure
depth
if
it's
specified
in
both.
I
think
we
may
have
addressed
that.
I'm
not
sure.
A
Just
yet
the
last
note
I
think
you
said,
there's
a
there
might
be
a
bit
more
work
to
answer
so
yeah.
We.
B
A
So
moving
on
then
to
dom's
rfc
323,
I
don't
know
it
doesn't
look
like
he's
on
the
call.
This
was
really
a
pretty
pretty
hefty,
very,
very
large
issue
that
was
brought
up
I'll
share
it
here.
It
looks
like
jordan,
you
shared
some
thoughts
but
as
well
less.
I
think
that
you
commented
here
not
sure
if
you
want
to
share.
B
A
Okay
sounds
like
that's
great
feedback,
so
we'll
leave
we'll,
leave
it
open
for
now
and
leave
the
agenda
label
and
I
think
the
action
item
there
is
yeah
to
to
break
up
and
just
be
mindful
also
I'm
not
sure,
appreciate
roy.
It
looks
like
you're
taking
notes
again
as
you
have
before,
so
I
just
thought
of
that
now.
So
I
appreciate
that
moving
on
since
there's
no
update
there
then
to
pr
and
rc-117
so
roy.
E
A
Yeah,
can
you
blow
maybe
increase
the
font
size
just
for
better
clarity,
sure.
E
E
So
I
can
see
that
right
now
I
have
nothing
here,
but
basically
you
can
see
that
it
tried
to
run
and
can
fund
it
in
that
workspace
just
print
the
header.
There's
no
dependencies
installed
there.
So,
basically,
you
can
also
maybe
just
print
to
show
what
the
demo
is
doing
here,
so
workspaces,
a
and
b.
So
in
my
current
project
here,
I.
F
E
A
and
b
folder-
and
these
are
properly
linked
within
my
node
modules,
so
yeah.
So
that's
where
we're
kind
of
going.
But
when
we
started
putting
down
some
of
the
implementation
we
were
discussing
internally,
we
quickly
noticed
that
it's
probably
a
very
good
idea
for
the
architecture,
point
of
view
of
the
client
to
try
and
keep
everything
to
a
single
place,
so
we're
leaning
more
towards
having
top
level
command
just
to
help
out
internally,
but
also
it
also
brings
some
benefits
of
avoiding
some
foot
guns
for
the
for
the
user
point
of
view.
E
So
we
have
been
exploring
going
the
route
of
npm
double
s
or
workspaces
top
level
command,
and
then
you
specify
the
name
of
the
command
you
of
the
top
level
comment
from
the
client
one
around,
and
this
should
run
that
top
level
command
across
all
the
workspaces.
E
So
maybe
a
little
bit
more
so
running
fun
here,
just
as
a
example
of
a
simple
command,
but
it
has
nothing
on
it
right
now,
but
I
can
also
just
quickly
show
like
ls,
which
right
now,
in
my
proof
of
concept,
has
a
custom
implementation
that
will
just
try
and
highlight
the
workspaces
within
your
current
install
tree,
unlike
like
the
regular
npmls
from
the
top
level
right
so
yeah.
This
is
all
in
this.
E
E
I
think
two
important
changes,
departures
from
the
original
ideas
in
the
rfc
that
I'd
like
to
highlight
is
that
we're,
probably
gonna
narrow
down
the
scope
and
take
away
the
elias
grouping
idea,
define
being
able
to
define
groups
within
the
package.json
so
for
now
we
might
punt
on
that.
E
Just
for
the
sake
of
getting
the
base
functionality
right
and
instead
we
were
looking,
maybe
maybe
now
exploring
a
way
you
can
send
the
path
to
a
directory
in
order
to
run
a
group
of
workspaces
within
that
word
that
directory
like
you,
could
run
a
single
command
in
all
of
them.
A
C
Yeah,
it's
in
general.
I
think
it's
okay,
it's
a
lot
to
digest.
So
it's
hard
to
like
form
an
opinion
right
away.
I
think
that
something
that
I
would
expect
is
that
I
have
one
set
of
commands
to
manage
the
workspaces
in
my
project
and
that
I
have
a
different
command.
C
Let's
say
where
it
runs:
npm
exec
in
each
of
the
workspaces
I've
specified
exactly
like,
like
with
the
exact
same
semantics,
so
that,
in
other
words
I
can,
if
I
that
I
should,
if
I
wanna,
if
I
have
a
command
that
that
I
run
in
the
top
level,
and
it
does
something
in
a
given
workspace,
I
should
be
able
to
see
it
cd
into
that
workspace
and
run
the
exact
same
command
but
elide
the
workspace
related
parts,
and
then
it
should
do
the
exact
same
thing
and
if
that's
true,
then
I
feel
like
my
intuition
will
be
met.
C
And
then
the
third
comment,
which
is
sort
of
a
rose
from
our
discussion
on
the
pr
is
I'm
I'm,
I'm
not
content
with
the
dictionary
of
the
glossary
of
terms.
It
feels
really
confusing
to
me
that
workspace
can
mean
both
the
repo
and
the
little
projects
in
each
one,
and
I've
always
avoided
using
the
word
workspace
when
I'm
talking
about
this
stuff,
because
I
think
intuitively,
I
find
it
confusing.
C
Maybe
it's
just
me,
but
it
would
be
really
nice.
Whatever
terms
we
come
up
with
here
are
going
to
be
become
the
way
people
talk
about
it
and
be
really
nice.
If
we
could
sidestep
things
like
that,.
B
I
I
tend
to
think
I
found
work.
Workspace
should
refer
to
the
the
thing
in
packages.
Slash
whatever
and
like
project
or
or
root
project
is
kind
of
the
the
root
of
the
project.
At
least
that's
how
we've
been
kind
of
being
clear
about
it
in
our
own
internal
communication
about
it.
D
There's
any
precedent
with
the
yarn
community
or
lerna
that
we
can
leverage
here
to
make
it
easier
for
folks
to
understand.
That
would
be
super
valuable
because
I
agree
the
terms
are
confusing,
but
I
also
haven't
seen
any
precedent
from
lerna
or
yarn
that
I've
heard
in
general
conversation.
D
B
It's
like
it's
like
package
versus
module
like
there's
a
there
is
a
there's,
a
difference
which
matters
sometimes,
but
in
practice
people
are
pretty
sloppy
with
their
language.
Just
because
that's
how
language
is
used.
One
thing
I
wanted
to
mention
about
the
you
know
cd
and
then
do
it.
B
That's
actually
that
was
actually
the
first
proof
of
concept
was
it
would
just
set
the
prefix
and
run
the
command
as
kind
of
the
default
behavior
and
there's
a
bunch
of
commands
where
that's
totally
appropriate,
like
that
is
actually
what
you
want
to
do,
because
the
only
thing
it
does
like
if
you
run
npm
view
with
no
arguments
right.
It
just
looks
at
the
current
working
directory
package
json
and
then
it
uses
that
as
the
package
name
same,
if
you
run
npm
disk
tag.
Npm
author
add
that
kind
of
stuff.
B
However,
for
some
things
you
kind
of
don't
want
that.
What
you
want
is
something
that's
a
little
bit
smarter,
for
example,
if
I
run
you
know,
if
I
do
npm
run
npm
run
build
right
to
like
build
all
of
my
css
and
js
across
a
bunch
of
different
workspaces.
B
If
there's
a
workspace
in
there
that
doesn't
have
a
build
command,
I
don't
want
the
whole
thing
to
fail
right
like
I
want
it
to
just
be
like
okay.
Well,
I
ran
three
things.
This
one
didn't
have
it,
so
it's
probably
fine,
but
if
nothing
has
a
build
command
because
I
spelled
it
wrong.
I
want
that
to
fail.
So
there's
like
there's
kind
of
these,
these
subtle
edge
cases
and
we're
going
through
and
putting
each
of
the
commands
into
a
different
bucket
of
either.
This
needs
its
own
custom
thing.
B
This
can
just
be
a
cd
and
run
it.
This
just
shouldn't
be
a
workspace
command
at
all
like
if
you
run
ncmws
whatever
like.
Maybe
that
should
just
fail.
I
don't
remember
now
there
was
there
was
we
identified
five
different
buckets
and
I
think
once
that's
once
that's
done.
I
think
it'll
become
much
more
clearer
about
in
terms
of
like
where
the
how
it
needs
to
be
kind
of
organized
and
it
might,
it
might
inform
this
whole
process
a
little
bit
more.
C
B
B
Exactly
exactly
yeah,
it
should
be,
it
should
be
like
what
would
what
would
be
done
and
what
would
like
give
me
the
same
reaction
if
I
were
to
tell
a
human
being
who's.
Intelligent,
hey
run
this
for
all
the
things
right.
I
would
expect
that
that
human
being
would
be
like.
Oh
well,
there's
no
build
script
here.
I'll
skip
this
one.
F
Yeah
so
one
question:
I
I
assume
that
this
is
intended
to.
I
I
think
there
was
some
discussion
about
this.
I
just
wanted
to
make
sure
that
this
is
the
plan
is,
are,
is
you
know
with
npm,
ws
or
workspace?
I
assume
ws
is
an
alias.
F
Is
that
planned
to
have
the
full
set
of
npm
commands
like
maybe
not
like?
I
don't
know
log
in
like
I
guess
that
doesn't
make
sense
necessarily,
but,
like
you
know,
the
ones
that
allow
me
to
operate
in
my
package
is
that
the
plan
to
have
the
full
set,
no
matter
what.
B
B
E
Maybe
the
five
types
of
the
five
categories
of
top
level
commands
that
we
kind
of
surfaced
during
our
brainstorm
session,
and
I
think
the
the
question
of
whether
or
not
we
support
them
like
definitely
tied
to
that.
So
it
would
basically
be
one
category
of
things
that
just
read
from
the
installed
tree,
one
category
of
things
that
write
to
the
install
tree
and
as
a
third
one
that
would
be
basically
cd
into
that
workspace
and
trying
to
run
the
top
level
commands
so
basically
setting
the
prefix
for
for
npm.
E
So
a
custom
implementation
which
might
be
might
be
the
case
for
some
of
the
top
level
commands
and
just
do
not
apply
at
all
like
things
that
doesn't
make
any
sense
like
should
it
support
logging,
org
teams
right
so
yeah.
These
are
the
kind
of
like
five
categories
that
we
kind
of
surfaced
and
we
want
to
make
sure
we
categorize
the
top
level
commands
and
make
a
decision
about
whether
or
not
is
it
even
worse,
to
try
and
support
them
within
the
workspaces
top
level
command.
Yeah.
B
I
think
most
common
commands,
though,
if,
if
we
get
this
right,
most
common
commands,
semantically,
like
as
a
human
being,
I
could
tell
you
well,
if
you
run
this
command
with
the
ws
sub
command,
it'll
just
do
what
you
would
think
right.
It'll
do
it
in
that
workspace.
E
A
So
I
tried
to
capture
the
the
five.
If
you
can
flush
out
that
note
there
as
well
that'd,
be
great.
A
I
noted
noted
in
the
chat
specifically
more
demos.
More
often
I
I
would
love
for
us
to
be
sharing
more
more
often
and
and
maybe
even
weekly,
try
to
give
updates
as
we
we
move
along
here.
So
hopefully
we
can
do
that
with
with
folks
as
this
progresses
and
yeah.
I
appreciate
that
the
feedback
in
terms
of
that
any
other
questions
or
comments
on
on
what
jose
roy
just.
B
Shared
well,
so
I
wanted
to
mention
one
other
thing.
This
has
been
brought
up
in
conversation
a
few
times
like
every
time
we
bring
up
every
time.
We
talk
about
workspaces,
and
I
do
not
want
today
to
be
any
different
that
right
now
the
way
that
we
sort
of
design
the
ideal
tree
with
workspaces
is
pretty
naive.
Essentially,
everything
is
always
hoisted
to
the
maximum
extent
that
it
can
be,
and
workspaces
are
the
same
as
linked
apps.
B
We
probably
want
to
do
something
a
little
bit
more
clever
or
a
little
bit
more
thoughtful,
at
least
about
what
is
shared.
What
is
not
shared
like
what
do?
What
do
workspaces
have
access
to,
because
and-
and
I
think
doing
that
is-
is
its
own
kind
of
rfc-
that
that
needs
to
happen
and
get
be
well
specified.
B
I
don't
think
it
needs
to
be
dramatic.
You
know
particularly
or
a
particularly
like
long
and
difficult
rfc.
It's
just.
It
needs
to
be
well
specified
so
that
we
have
it
kind
of
documented
in
very
clear
language
somewhere
with
you
know,
a
pretty
good
comb
through
of
edge
cases,
okay,
yeah
and
I
think.
E
It's
a
that.
I
think
it
is
also
important
to
mention
for
jordan's
question
initially,
like,
I
think,
the
way
we
handle
workspaces
today
in
this
tall
tree.
It
makes
it
impossible
to
have
that
that
affirmation
you
just
did
like
running
a
top
level
command
like
npm.
The
workspaces
run
script,
something
where
the
category
starts,
stop
test
right,
the
same
as
cd
into
that
workspace.
E
Right
now,
with
the
install
tree
we
have
today
that's
not
possible
right,
because
everything
is
hoisted
to
the
top
level.
So
adding
npm
workspaces
test
is
going
to
be
a
a
big
win
for
enabling
users
to
run
the
test
script
within
any
of
the
workspaces.
But
it's
not
going
to
be
the
same
as
sitting
into
that
folder
and
running
it
right.
It's
an
important
distinction
to
make
their
with
the
install
tree.
We
have
today
it's
what
isaac
say
like
that's
a
totally
different
conversation
that
we
need
to
have.
E
We
need
to
have
that
soon,
but
yeah.
I
think
it's
important
to
highlight
that,
and
also
maybe
just
together.
The
I
think,
was
kind
of
important
from
my
point
of
view
and
this
from
this
call
kind
of
gather
a
sentiment
of
whether,
if
we
decide
to
just
put
all
the
commands
behind
the
the
top
level
workspaces
command
like.
E
Is
that
some
something
that
someone
has
a
very
strong
feelings
against?
Or
is
it
fine
from
the
group
point
of
view?
E
Yeah
yeah
yeah,
so
basically
the
way
the
the
rfc
today
is
describing
running.
The
commands
is
basically
like
you
would
always
type
npm
fund
w
or
dash
dash
workspace
and
the
name
of
the
workspace
right,
but
we're
proposing
changing
that
syntax
to
always
enforce
you
to
have
ws
after
npm,
so
npm
ws
fund
and
then
the
workspaces
you
want
to
run.
B
C
Well,
yeah,
I
think
that's
my
question
right.
I
have
npm
ws
fund.
Let's
say
that's
fine
to
me:
I
I
don't
care
if
it's
npmws,
fun
or
npm
fun,
dash,
ws
or
whatever,
but
by
default.
I
would
expect
as
isaac's
asking
that
it
would
run
in
every
workspace
and
then
how
do
I
then
specify?
How
do
I
like
narrow
that
down.
E
Other
the
other
story
with
npm
config
that
you'll
be
brought
up
to
jordan.
B
Yeah
so
in
in
terms
of,
like
you
know,
big
big
rocks
coming
up
in
our
in
our
rfc
process.
It's
probably
worth
mentioning
at
this
point.
There
is
the.
B
How
do
we
lay
out
workspaces
on
disk
this,
this
api
bike,
shutting
which
I
think
is
pretty
important-
the
lifecycle
script
stuff
that
gar
is
working
on,
which
I
alluded
to
before,
and
also
just
in
general,
like
a
kind
of
a
an
overhaul
of
how
we
do
config,
which
will
probably
will
most
likely
be
a
breaking
change
in
v8,
even
if
it's
just
to
deprecate
certain
things
like
that
deprecation
is
itself
a
breaking
change
in
a
lot
of
cases.
B
In
the
meantime,
though,
I'm
very
I
very
much
do
not
want
to
get
us
into
another
case
or
add
another
config
that,
like
only
is
relevant
if
it's
specified
on
the
cly,
because,
like
adding
any
any
tiny
grain
of
complexity
to
our
config
system,
which
is
already
super,
complicated
and
elaborate,
is,
is
pretty
kind
of
takes
us
in
the
wrong
direction.
I
think,
until
we
have
a
very
clear
idea
of
what
the
future
looks
like.
F
B
B
Right
right,
I
may
I
may
want
to-
I
may
want
to
have
some
of
my
workspaces
be
looking
at
my
private
registry,
and
some
of
them
are
looking
at
the
public
registry.
I.
F
Mean
I
can
also
say
that,
like
at
least
like
I
can
very
easily
imagine
like
a
team
in
microsoft
having
two
different
apps
that
point
to
two
different
registries,
because
they
publish
to
do
two
different
registries
internally
and
like
we.
We
just
want
these
two
projects
in
the
same
workspace
or
these
two
workspaces
in
this
project
to
point
to
these
different
ones.
Yeah.
A
Thanks
cool
okay,
so
if
we
there's
no
other
comments
on
the
rc
itself,
right
did
we.
I
just
want
to
double
check.
Have
we
updated
this
again
with
the
latest
feedback,
or
are
we
going
to.
A
E
I
cleaned
it
up
and
I'm
gonna
be
pushing
right
after
the
call.
I
was
hoping
yeah
with
this.
This
feedback,
I'm
hoping
to
finish
the
cleaning
up
there
and
I'm
gonna
push
new
revision.
A
Yeah,
the
one,
the
one
big
thing
to
note
again
is
we're
basically
doing
a
bit
of
d
scoping
with
the
removing
the
aliases
slash
group
support
by
out
of
the
box,
but
that
can
be
reintroduced
and
brought
back
a
layered
date
right.
So
I
think
that's
that's
a
good
thing
to
note
and
something
that's
going
to
change
in
the
rfc,
so
we
can
essentially
parse
that
out
and
make
it
separate
cool.
Moving
on.
We
have
two
the
two
open
rc's
by
gar.
A
I
I
know
saw
that
he
had
gone
off
line
for
a
second,
but
potentially
I'm.
G
I'm
back,
I
don't
know
that
there's
anything
new
to
discuss
on
those.
A
I
think
there
was
an
action
item
for
us
to
go
and
potentially
talk
with
our
registry
partners
about
what
this
looks
like
on
their
end,
to
support
right,
at
least
for
the
public
registry,
was
that
one
of
the
items
that
we
yeah
we
took
away,
I
think
last
week.
Okay,
maybe
we'll
just
make
a
note,
then,
but
that's
still
something
we
need
to
do.
A
Roy
are
you
gubbin?
Okay,
thanks
see
you
grabbing
issues
and
making
notes
cool.
So
if
there's
no
did
anybody
have
any
other
feedback
I
saw.
Wes
did
note.
I
give
some
feedback
within
the
last
week
as
well
as
div
flow,
to
at
least
be
adding
multiple
disk
tags.
The.
A
A
But
if
folks
don't
have
any
comments
right
now,
we
can
leave
this
open
and
essentially
keep
that
conversation
made
sync
for
now.
B
Yeah,
I
I
don't
think
there
was
much
controversy
over
like
the
the
dis
tags
thing.
There
was
a
little
bit
of
back
and
forth
internally
about
what
it
would
mean:
implementation
wise
as
far
as
like
how
we
define
the
the
tag
config
or
if
we
need
to
split
that
into
two
separate
tags
or
two
separate
configs,
the,
since
we're
kind
of
blocked
on
doing
some
follow-up
with
the
registry
side,
we
might
want
to
take
the
agenda
label
off
of
this.
Take
it
off
the
agenda
until
we
kind
of
check
that
box.
A
We
actually
might
not
be
blocked
right.
I
think
that
was
another
thing
we
noted
last
last
week
was
actually
we
can
go
ahead
and
actually
introduce
this
into
apply,
and
any
other
registry
that
obviously
supported
multiple
disk
tags
could
support
this
before
the
public
registry
so
like
today.
What
like
what
would
happen.
A
Sure
a
registry
time
yeah
yeah,
I
I
yeah-
I
mean
I
don't
know
if
we
would
call
it
bug,
but
we
could
say
that
this
is
essentially
like
a
feature
of
passing
along
this
config
to
a
registry.
A
You
know
any
registry
that
would
support
yeah,
setting
multiple
this
tags
out
at
once
that
publish
them
and
would
get
this
benefit,
so
we
don't
have
to
necessarily
block
our
work
on
it.
A
G
G
That's
with
publishing
not
set
disc
tag
right
because
set
dis
tag.
As
far
as
I
knew
not
that's
a
an
atomic
endpoint
and
we'd
have
to
just
call
that
multiple
times
and
and
that's
noted
in
the
rfc
about
how
that's
we
can't
make
it
atomic
and
that's
one
of
the
things
to
consider
when
we
ratify
this.
A
Yeah,
so
I
would
say,
maybe
leave
it
up
open
for
one
more
week
and
leave
the
agenda
tag
our
label
on
it.
For
now
that
tag
leave
me
a
label
on
it
for
now
and
then
next
week.
If
we
there
isn't
any
like,
like,
like
staunch
reasons
why
we
can't
implement
you
know
this,
as
is
then
we
can
ratify
it
and
then
queue
up
the
backlog.
The
work.
A
Moving
on
then
to
the
pr
nrc317
this
is
for
so
this
is
similar.
This
is
p,
publish
and
set
the
this
tag
accordingly
december
version
number,
I'm
not
sure
I
see
weston
and
jordan.
You
had
given
feedback
to
us,
I'm
not
sure
if
we
actually
got
to
it,
it
might
be
essentially
what
spawned
this
these
other
rc's
by
car.
B
B
This
is
going
to
be
tricky
like
if
we
start
not
publishing
to
the
latest
like
this
is
a.
This
is
a
much
bigger
change
than
it
looks
like.
A
I
just
pasted
the
rendered
version
for
effects.
B
Yeah
I
mean
I
get,
I
get
very
concerned
when,
when
the
rationale
is
well
currently,
we
do
this
thing
and
that
doesn't
make
sense
to
me
and
it's
like
yeah,
but
we've
been
doing
that
current
thing
for
12
years
and
I'm
willing
to
bet
somebody's
depending
on
that
and
doesn't
maybe
doesn't
even
realize,
they're
depending
on
it.
So
we
should
be
extremely
careful
about
changing
it
and
really
look
at
like
what
are
the
ramifications
of
changing
it.
What
are
the
ramifications
of
not
changing
it?
D
The
problem
that
they're
saying
it's
causing
is
that
people
accidentally
publish
on
latest
all
the
time,
and
I
I
know
I
do
so.
I
assume
that
I've
heard
the
other
people
complain
about
that
and
it
obviously
it's
fixable
and
we
have
a
way
to
not
do
that,
but
that
doesn't
make
it
the
right
user
experience
either.
D
So
if
we
can
make
it
easier
for
people
to
do
the
right
thing
on,
you
know,
yeah.
B
B
C
Yes,
so
I
think
there's
a
few
things
so
as
it
is,
there's
a
whole
bunch
of
problems
with
the
way
npm
publish
works
with
automatically
publishing
the
latest.
As
wes
has
mentioned,
I
have
made
a
project,
a
package
called
safe,
published
latest
that
I
use
in
my
pre-published
script
on
hundreds
of
projects,
because
I
have
accidentally
screwed
this
up
multiple
times
and
basically,
what
this
does
is.
It
doesn't
allow
me
to
ever
publish
a
version
number
older,
like
sember
wise
than
the
current
latest,
unless
I
explicitly
indicate
that
that's
what
I
want.
C
It's
caught
me
a
number
of
times
that
doesn't
even
like
so
so
that
might
be
a
nice
published
prompt
also
for
npm
itself,
like
I
would
love
for
that
package
to
be
obsolete
and
framingham
just
do
this
separately,
adding
the
ability
like
if
we
can
make
no
no
dash
tag,
actually
publish
without
a
tag
that
would
be
glorious
because
then,
like
any
time,
I
have
any
concern
about
it.
C
I
can
just
I
mean
I
could
even
set
that
as
the
default
and
I
could
just
never
publish
with
a
tag
and
then
I
can
always
add
my
leisure
publish
to
latest.
That
would
even
make
it
like.
You
know
anyway,
yeah
I'll
just
stop
there
with
that.
But
the
like.
The
the
other
use
case
that
I
have
is.
If
I'm
publishing
a
pre-release,
I
only
really
want
that
to
be
latest
and
it
would
be
really
nice
to
just
kind
of
automatically.
C
Warn
me
just
like
you're,
just
like
you're
trying
to
publish
an
older
version
are,
you
sure,
are
you're
trying
to
publish
a
pre-release.
Are
you
sure,
and
I
think
that
it
would
be
nice
if,
like
in
v8,
let's
say
in
in
a
non-tty
it
just
errored
out,
so
that
in
in
other
words,
so
that,
instead
of
just
saying
it
silently,
does
the
wrong
thing
if
you're
in
ci,
if
you
know,
there's
a
different
way
to
bypass
it
like
the
safe,
published
latest
uses,
you
either
change
the
tag
or
you
use
an
environment
variable.
C
C
A
Yeah
just
be
mindful
of
time
we
have
about
four
minutes
left,
and
so
I
think
that
the
action
item
here
is
to
potentially
again
reference
published,
runs,
probably
in
the
rfc
itself,
and
then
I
wanted
to
give
some
time
for
the
last
there's,
like
three
sort
of
I
would
say
pretty
like
meaty
items
here
at
the
end,
which
I
think
we
should
probably
either
start
with
next
week.
A
If,
if
we
can't
get
at
least
the
the
next
one,
which
is
the
rfc
314
for
the
registry
protocol
isaac,
I
know
you've
proposed
and
that
there's
been
some
conversation
from
like
zoltan
and
and
mile
giving
feedback
here.
I'm
wondering,
like
we've,
been
waiting
to
essentially
ratify
this
for
a
while.
B
Yeah
so
there's
an
open
question
to
dig
into
on
this
rfc,
which
is,
I
depend
on
foo
at
registry,
colon,
blah,
blah
blah,
and
that
depends
on
bar
at
one
dot
x.
B
So
I
think
something
that
needs
to
be
fleshed
out
more
in
more
detail
in
that
rfc
is
to
say,
if
we,
when
we
are
building
the
ideal
tree,
when
we're
resolving
packages
effectively,
that
registry
specifier
all
of
its
dependencies
that
are
not
all
of
its
dependencies,
that
are
a
version
or
tag
or
alias,
need
to
effectively
be
converted
to
a
red.
You
know
a
dependency
on
that
same
registry.
D
B
D
C
F
B
So
either
either
they
have
mapped
a
scope
and
I'm
using
it's
in
the
same
scope
or
they
have
not
mapped
a
scope
and
they've
set
the
top
level
registry
config,
in
which
case
that's
how
you're
getting
it.
But
the
only
way
to
get
this
foo
thing,
which
might
be
a
namespace
package
or
a
nominee
or
a
global
package.
D
D
B
Really
quick,
you
set
your
and
I'll
flush
this
out
in
the
rfc
as
well,
but,
let's
say
you're
in
a
corporate
environment
you're
pointing
at
the
internal
registry,
but
now
new
project
you
want
to
use
express.
B
B
But
now,
if
we
try
to
fetch,
you
know
all
of
express's
dependencies
from
your
corporate
registry,
which
is
your
top
level
registry
config,
it's
going
to
fail,
so
I
think
it's
more
like
when
you're
fetching
something
from
a
registry.
The
person
who
published
into
that
registry
presumably
assumed
that
all
of
their
dependencies
would
also
be
found
from
that
registry,
or
else
it's
not
installable
anyway.
A
A
A
A
Okay,
great
yeah,
we'll
we'll
pull
these
three
up,
so
they
get
get
some
time
next
week.
I
appreciate
everybody
jumping
on
again
and
thank
you
so
much
for
for
giving
us
some
of
your
time
and
yeah
we'll
be
back
same
time
same
place
next
week.
Cheers
sounds
good.
Thank.