►
From YouTube: Node.js Foundation Modules Team Meeting 2018-04-11
Description
A
We
are
live.
This
is
the
April
11th
2018
meeting
of
the
noches
modules
team.
Thank
you
to
those
who
are
watching
live
I'm
gonna,
take
a
second
and
just
tweet
the
link.
If
anyone
has
some
business
to
just
bring
up
really
quickly,
that's
not
on
the
agenda.
Please
feel
free
to
take
this
moment
to
bring
it
up.
A
Ok,
so
moving
to
the
agenda
that
we
have,
we
have
13
members
on
the
call
right
now
which
is
not
quorum.
We
would
need
I,
believe
21
people
to
have
quorum.
Perhaps
another
8
people
can
show
up
between
now
and
then
John
I
see
you're
on
the
call.
You
sometimes
are
in
a
room
with
some
other
Microsoft
employees.
Is
it
just
you
today?
Are
you
with
others.
A
Love
it
whatever.
It
is:
ok,
so
moving
forward
on
the
agenda,
the
first
things
that
we
have
right
now
are
approving
PRS.
Unfortunately,
we
do
not
have
quorum
to
approve
these
PRS,
so
the
two
meeting
notes
will
not
be
able
to
land,
but
we
have
a
five-minute
time
box
to
discuss
the
membership
rules.
I'll
present
that
really
quickly
and
then,
if
anyone
has
any
concerns,
this
would
be
a
good
time
to
maybe
bring
it
up.
I
just
did
a
quick
hack
at
trying
to
put
together
some
basic
rules
for
the
team.
A
Essentially,
it
changes
the
definition
we
have.
It
mentioned
his
collaborators
right
now
and
I
change
that
to
be
members
and
then
I
provide
a
more
granular
definition
of
both
active
members
and
observers,
specific
what
the
ability
like
which
each
group
has
so
and
just
well
I'm
doing
this
Michael
I'm,
making
you
a
co-host.
A
So
if
anyone
else
joins
you
to
be
able
to
promote
them,
that
active
members
are
able
are
invited
to
all
meetings
can
participate
in
the
consensus
seeking
process
which
is
itself
divided,
define
lower
down
they're
counted
towards
quorum
in
team
meetings
and
participate
in
votes
observers.
Alternatively,
are
invited
to
all
meetings
can
participate
in
a
consensus
seeking
process,
not
counted
towards
quorum
and
team
meetings
and
cannot
participate
in
voting.
A
This
is
a
very
important
distinction
in
there
in
that.
Unless
a
decision
moves
to
a
vote,
all
members
and
observers
equally
participate
in
the
consensus
seeking
process
and
by
the
definition
of
how
I
put
it
together.
Even
an
observer
would
be
able
to
object
on
something
if
they
didn't
want
it
to
land,
they
just
wouldn't
be
able
to
participate
in
the
actual
vote
so
essentially,
and
due
to
the
fact
that
we
so
rarely
have
votes.
A
The
idea
here
would
be
that
it
would
allow
it
would
allow
observers
to
be
essentially
full
participants,
but
it
would
stop
like
so,
for
example,
right
now
with
only
14
people
on
the
call
we're
not
actually
able
to
approve
and
move
things
forward
that
require
quorum
to
do
so.
So
I
figured
that
this
was
a
good
balance
between
keeping
people
engaged,
empowering
people
to
participate
in
the
process,
but
not
blocking
parts
of
our
governance
that
essentially
require
account
to
move
forward.
A
A
Observers
can
open
a
pull
request
to
make
themselves
full
members
and
that,
at
any
time
a
member
or
an
observer
can
you
know,
move
themselves
to
observers
or
remove
themselves
from
the
team
entirely
and
that
doesn't
require
consensus
seeking.
So
the
short
version
of
this
process
would
be
that,
essentially,
anyone
can
add
themselves
at
any
time,
and
it
just
requires
consensus
of
the
team
to
have
them
added.
A
Someone
can
move
from
being
not
a
member
of
the
group
at
all
to
being
a
full-fledged
member
of
the
group
into
meetings
so
like
that
process
at
minimum
would
take
two
weeks,
but
due
to
the
rules
as
we
have
it
right
now,
like
they
more
or
less,
would
be
able
to
observe
and
participate
in
the
meeting.
They
just
wouldn't
be
part
of
the
vote
and
the
big
kind
of
tweak
on
language.
A
There
is
making
sure
that
anyone
who
is
joining,
who
you
know
if
you
want
to
move
yourself
down
or
move
yourself
out,
that
can't
actually
be
blocked
by
anyone
and
doesn't
require
consensus
seeking.
So
if
anyone
you
know
doesn't
want
to
participate
any
more,
they
should
be
able
to
do
that
themselves.
A
The
the
rest
of
this
pull
request
is
is
mostly
a
refactoring
and
those
are
individual
commits,
but
more
or
less
our
consensus
seeking
process
had
some
language
conflated
throughout
the
governance.
Talk,
especially
in
the
landing
PR,
so
I
just
refactored
that
out
does
anyone
have
any
concerns
or
questions
about
the
PR
in
its
current
state.
B
Please
yes,
so
we
currently
have
a
an
issue
open
for
Jeffrey
of
typescript
to
become
our
sorry
CoffeeScript,
my
bad,
my
bad
CoffeeScript
maintainer
to
become
an
observer,
but
that's
not
a
poor
request
should
that
just
be
transferred
to
a
pull
request.
They
start
delay
the
discussion
till
two
weeks
from
now.
No.
A
A
A
Unfortunately,
everyone
who
signed
off
on
this
aside
from
Mateos
in
this
meaning
of
the
15
people
is
there
anyone
who
has
more
than
one
person
in
there
in
the
room
right
now
yeah,
so
we
don't
a
quorum
so
we'll
have
to
move
forward
if
we
end
up
having
quorum
at
any
point
in
the
meeting,
I'll
stop
and
move
back
to
this,
so
that
we
can.
We
can
dig
in
so
back
to
the
agenda.
We
have
we're
on
to
the
discussion
now,
so
we
did
have
the
can
ID
and
observer.
That
was.
A
That
was
the
issue
that
was
opened
by
Jeffrey,
who
is
asking
if
he
could
join
as
an
observer.
One
thing
that
we
could
potentially
do
and
we
don't
need
quorum
right
now
is
we
could
ask
Jeffrey
to
open
a
pull
request,
adding
themselves
as
an
observer
and
attempt
to
reach
quorum
with
enough
approvals
within
within
that
issue.
Does
anyone
have
see
anything
problematic
with
doing
that?
A
Okay,
so,
let's
I
have
no
objections
to
them
joining
as
an
observer.
It
doesn't
seem
like
anyone
else
does.
We
only
need
a
few
more
people
to
join
the
call
before
the
end.
So
let's
just
move
past
that
he's
actually
watching
the
livestream.
Okay,
awesome
glad
to
hear
that
and
Jeffrey
since
you
are
watching
I
have
my
eyes
on
the
YouTube
chat.
Please
feel
free
to
throw
anything
in
there.
A
C
A
A
The
next
one
that
we
have,
let's
just
make
sure
we're
to
45
minutes
right
now,
so
I'm
gonna,
I'm
gonna
go
ahead
and
I'm
gonna
drop
the
we
may
skip
the
membership
requirements,
but
let's
keep
it
ten-minute
time
box
on
this
cash
system,
mismatch
with
web
Brad?
Do
we
have
you
on
the
call
right
now
I'm
around
yeah?
A
D
So
I'll
just
give
a
brief
summary.
I've
got
a
call,
basically
I
overlooked
something
a
couple
years
ago
and
didn't
realize
that
we
are
caching
our
module
records
using
a
different
model
than
how
the
web
is.
Caching
things
it
doesn't
work,
how
node
does
stuff
in
common
jeaious
babel
does
stuff.
Web
pack
does
stuff
rope,
rollup
does
stuff,
etc.
The
web
specification
it's
different.
D
It
closely
models,
how
CSS
works
with
@import,
but
it's
a
little
different
due
to
having
a
module
map
which
CSS
does
not
have
so
in
that
issue,
I
kind
of
go
over
some
indirection
differences,
it
isn't
just
symlinks,
I
could
probably
dig
up.
A
different
way
is
to
do
this,
but
the
overall
problem
is
the
web
is
creating
entries
in
the
module
map
for
a
module
namespace
upon
request
before
it
gets
the
final
destination
so
before
it
does
redirects
or
any
form
of
indirection.
D
It
creates
the
module
map.
Entry
and
node
doesn't
because
node
wants
to
know
the
final
address,
essentially
the
real
path,
so
after
all
the
indirection
and
that's
what
we're
using
for
the
key.
Instead,
this
means
you
can
have
differences
in
what
it
means
to
load
modules
that
have
a
form
of
indirection,
and
we
just
need
to
discuss
like
do.
We
want
to
match
the
web,
which
has
some
inherent
value
in
it.
D
E
Mean
from
the
discussion
on
github,
like
one
of
the
comments,
was
that
the
purpose
of
import
meta
URL
is
to
give
a
URL
that
relative
requests
should
be
considered
relative
to
and
if
node
wants
to
include
import
meta
URL.
That
seems
like
the
mental
model.
We
should
mimic
and
I
think
that
I,
don't
I,
don't
know
exactly
what
that
conclusion
that
triggers,
but
it
definitely
seems
like
it,
has
an
impact
on
in
direction
and
symlinks
and
package.json
main
resolution
and
stuff
like
that.
E
D
That
is
not
what
it
is
using
for:
import
meta,
URL,
it's
using
the
final
location,
whatever
gets
a
200,
basically
for
the
value
of
import
meta
URL,
unlike
node,
which,
since
we're
going
with
the
destination,
the
important
material
matches
one-to-one
with
a
cache
key
in
the
module
map
so
on
the
web
import
met,
the
URL
is
not
unique
and
does
not
represent
your
module,
namespace
or
record
in
node
webpack
and
other
people
who've
been
using
this
syntax.
It
is
unique
and
represents
a
module
record.
D
B
Think
Dominic
might
be
open
to
allowing
things
like
that
fragment
to
AB,
be
added
to
import
meta
URL.
Now
that
it
was
raised
as
they're
trying
to
allow
the
fragment
to
be
added
to
other
places,
so
it
might
be
more
closely
aligned
with
node
in
Safari
technical
preview
there.
So
there
might
be
like
a
light
or
a
positive
outlook
on
that.
A
F
You,
the
main
thing
that
comes
out
to
me
about
this
is
that.
F
On
no
chance.
If
you
run
NPM
in
an
environment
with
that
configured,
we
will
install
your
dependencies
directly
like
in
your
inside
of
your
in
your
node
modules,
whereas
if
you
use
it
without
that,
we'll
put
it
in
off
inside
of
the
send
link
itself,
because
it's
the
only
part
I
can
see.
I
can't
see
the
rest
of
your
project.
F
What
I'm
concerned
about
is
getting
into
a
situation
where
some
modules
have
this
behavior
enabled
and
other
modules
don't
and
I,
don't
know
how
we
would
resolve
that
in
a
way
that
would
be
consistently
it
like
that.
That
would
be
a
weird
scenario
like
I
guess
we
could
do
that,
and
that
is
a
thing
that
we
could
support.
But
it's
a
weird
place
to
be
so
I
I
would
be
very
cautious
about
following
like
this
may
be
a
place
where
we
need
to
do
purge
from
the
web
behavior
just
because
of
our
own
legacy.
A
B
D
So
we
could
add
a
new
property
and
we
probably
shouldn't
try
to
fill
the
same
use
cases
by
diverging
on
import
meta,
URL,
so
I
would
say
we
probably
do
need
a
new
property
for
some
use
cases,
but
I
would
need
to
go
over
those
just
like
make
a
use
case
document
for
the
things
that
were
expected
and
we
now
should
not
rely
on
import
meta.
Url
for
and
I've
won.
A
second
Rebecca's
concerns
here,
I
I,
don't
think
the
ecosystem
is
well
suited
to
handle
the
legacy
burden
of
changing
how
caching
works.
A
What
so,
just
kind
of
like
I
guess
a
question
to
the
room
like
first
off
I'm
I'm,
a
big
plus
one
on
making
new
import
meta
properties
if
they
fit
our
needs
more
I.
Don't
think
that
there's
a
need
to
like
kind
of
change.
What
meta
import
URL
does
if
it
doesn't
really
fit
our
uses,
would
it
be
useful
to
try
to
set
up
a
call
with
people
from
the
what
working
group
or
from
like
the
stakeholders
that
are
working
on
these
standards?
A
A
Which
I
take
silence
as
a
yes,
yes,
okay,
I'll
refer
to
our
process
and
assume
that
no
objections
in
this
ecstatic.
Yes,
and
we
can.
We
can
move
forward
with
that.
We
have
two
and
a
half
minutes
left
for
right
now,
but
since
those
were
added,
that's
at
a
time
that
we
did
do
we
want
to
just
move
on
to
the
next
agenda
item
at
this
point,
I
will
take
the
lack
of
speaking
as
once
again
ecstatic
support
John,
as
the
person
who
has
been
primarily
taking
lead
on
our
use
cases
discussion.
B
E
Cool
okay,
so
the
first
one
I
put
was
that
a
user
has
a
large
application
and
they
want
to
be
able
to
gradually
migrate
from
their
currency.
Cj
s
usage
to
ESM
and
that
see
it
CJ
s
or
transpiled,
see,
guess
it's
kind
of
the
same
thing
that
one
file
at
a
time,
but
without
having
to
change
the
entire
code
base.
So
that
means
not
having
to
change
every
file
all
at
once,
but
also
it
means
changing
file
from
CJ
s
TSM
and
not
having
to
update
every
consumer
of
that
final
necessarily.
E
Change,
meaning
anything
reasonably
observable
to
the
consumer
and
I'm
only
adding
in
reasonably
there,
because
there's,
obviously
some
like
pretty
extreme
and
saying
things
people
could
do.
But
you
know,
let's
not
count
like
people
looking
at
function,
lengths
and
function
to
string
and
stuff
things
like
that:
okay
and
then
the
next
one.
E
So
you
know,
and
it's
very
easy
to
get
stuck
on
an
older
rails
version.
So
let's
say
that's
the
case
so
in
in
their
rails.
Arb
template
they'll
need
a
way
to
determine
if
a
file
is
a
script
or
script
type
module
without
having
a
JavaScript
parser
available,
because
in
such
a
setup
the
only
JavaScript
parsers
available
are
heavyweight
and
required
compilation
and
don't
really
work
very
well.
E
E
So
there
should
be
some
way
for
them
to
consume
that
package
on
an
older
version
of
node,
as
well
as
a
newer
one
without
yeah
so
like,
in
other
words
the
they
should
not
be
required
to
update
their
node
version
in
order
to
get
it
working
and
upgrading
their
node
version
should
not
break
what
they
already
have
working
there.
You
go
okay,
cool.
B
B
We
also
talked
at
the
same
time
about
packaged
map,
so
there
was
always
a
lot
of
comparisons
going
back
and
forth
between
the
two
is.
Is
there
are
next
steps
now
that
we
have
some
solid
use
cases
and
we
can
start
to
see
where
there
is
very
web-centric.
There's
deb
centric,
there's
Interop
scenarios,
and
things
like
that
that
we
should.
What
are
the
next
steps
for
these
use
cases
that
we
have
so.
G
A
Physically
raised
my
hand,
I
think
that
the
the
the
next
steps
for
us
at
this
point
would
be
translating
these
use
cases
into
explicit
features
or
user
experience
and
then
beginning
to
discuss
those
so
I
mean
what
we
could
do
right
now
would
be
maybe
like
almost
one-to-one
or
in
another
doc.
We
could
go
through
those
use
cases
and
translate
those
to
future
requirements.
A
E
Just
that
does
sound
reasonable
I
think
that
I,
like
the
yes
and
for
now
I'm
concerned
about
the
later
part
of
that
I
think
that
that
we
should
be
very,
very
cautious
at
any
point
in
discarding
or
disregarding
or
marginalizing
anyone's
use
cases.
There
are
plenty
of
use
cases
of
mine
that
I
would
not
want
marginalized,
and
there
are
plenty
of
use
cases
of
other
people
I
might
want
to
marginalize,
but
that
I
would
like
to
treat
as
fairly
as
I
hope
to
be
treated.
A
And
I
think
approaching
this
to
start
as
a
yes
and
making
a
list
of
all
features,
then
from
that
picking
up
the
features
that
we
have
absolute
consensus
on
will
then
allow
us
to
start
discussing
amicably
and
respectfully
the
features
that
aren't
in
agreement
so
that
we
can
sort
it
out
and
I
think
I
think
we
all
know
or
have
an
idea,
the
futures
we'll
get
to
that.
We
don't
have
consensus
on,
but
hopefully
by
following
this
framework,
you
know
we
can
make
that
conversation
a
little
more
guided
and
less
contentious
John.
A
B
A
A
B
It
I
I
noticed
from
just
having
it
sit
in
this
document.
It
kind
of
sat
for
a
while
with
folks
coming
in
very,
very
very
little
to
disturb
the
document.
So
I
don't
know
if
it
needs
to
be
in
a
more
a
place
that
encourages
contribution
better
than
a
document
or
I
know.
Github
is
chatty,
but
that
seems
to
get
a
lot
of
attention.
So
maybe
that
could
be
the
place,
but
we
need
to.
We
start
weird
we're
going
to
need
a
bunch
of
feedback
and
contributions
to
it.
If
it's
gonna
go
forward.
A
So
so
one
reason
I,
think
a
new
document
may
be
good
in
the
first
thing
that
we
can
draft
would
be
kind
of
not
a
manifesto,
but
like
a
list
of
how
we're
approaching
the
document,
because
we
we
don't
have
quorum
right
now.
Not
everyone
in
the
group
is
gonna,
understand
the
process
that
we're
taking
towards
this,
and
so
perhaps
what
we
should
do.
A
What
I
would
suggest
is
a
new
dock,
with
a
link
pointing
to
the
use
cases,
dock
that
we're
building
this
off
of
and
a
paragraph
and
I
can
take
that
as
an
action
item
to
do
after
this.
But
if
the
paragraph
just
kind
of
outline
the
process
that
we're
doing
currently
as
a
wayfinding
exercise
and
that
essentially
we're
not
critiquing
features
right
now.
We're
collecting
features
I
mean
just
making
people
yeah.
F
Just
very
briefly,
we
should
probably
number
the
use
cases,
so
we
can
refer
to
them
and
then
ideally
have
yeah.
People
cite
with
use
case.
Their
solution
is
solving
so
that
it's
always
clear.
You
know,
because
I
didn't
always
be
clear
and
they're
like
some
tight
and
some
mini
you
skip.
Many
solutions
will
solve
many
use
cases.
So
mm-hmm.
B
F
B
A
C
B
B
A
So
so
well
John's
doing
that.
Maybe
we
can
pause
this
discussion
from
for
a
second
and
move
to
what
we
had
next
on
the
agenda
just
so
that
we
can
talk
about
it
and
then
John,
just
you
jump
in
when
you're
ready
to
start
up
again
and
that's
the
discussion
of
membership
requirements,
which
is
issue
number
43.
We've
kind
of
talked
about.
We've
talked
about
this
back
and
forth:
we've
not
really
reached
consensus.
We
tried
to
do
something
earlier
around
this
and
that
was
not
well
met
for
good
reasons.
A
We
did
decide
to
push
the
conversation
last
week
also
because
we
didn't
have
quorum,
but
I
think
that
it's
important
to
have
it
right.
Now,
well,
what
I'm,
thinking
about
doing
and
I'd
like
to
just
you
know,
get
people
to
chime
in
if
they
think
that
it's
not
really
fair
is
I
want
to
go
through
and
take
a
look
at
our
past
meeting
notes.
Take
a
look
at
the
tracker,
identify
people
who
have
not
participated
at
all.
A
People
who
have
not
commented
on
any
issues
who
have
not
commented
underneath
poll
request
and
not
participated
in
any
meetings
and
I
will
individually
message
them
and
request
that
they
move
to
an
observe
themselves
to
an
observer
status.
That's
one
option.
The
other
option
is
that
I
can
open
a
PR,
but
that
may
feel
like
a
call
out.
It
didn't
seem
to
go
over
well
the
last
time.
A
My
concern
with
this
is,
while
it's
more
polite
to
do
it
indirectly.
That
way,
since
people
have
not
been
active,
there
is
the
risk
that
that
lack
of
activity
would
be
a
lack
of
activity
in
a
response
to
an
email.
So
if
anyone
has
any
advice
or
thoughts
on
how
to
approach
this
in,
like
a
kind
and
fair
way,
I'd
really
appreciate
some
thoughts.
I.
C
Mean
oh
I,
think
sending
out
the
the
direct
email.
Privately
first
sounds
good,
and
maybe
we
agree
that
you
know
after
if
there's
no,
if
there's
no
response
after
you
repeat
it
after
a
week
or
something
if
there's
no
response
for
some
period,
is
it
two
weeks
or
three
weeks
I
don't
know,
then
we
consider
that
they're
not
active
anymore
yeah.
A
Well,
maybe
what
I
should
do
is
I
will
I
will
try
to
get
to
this
today
tomorrow,
I'll
yell,
everyone
who
hasn't
been
active
and
what
we
can
do
from
there
is
if
I,
if
I
have
I've
not
heard
from
anyone
by
the
next
meeting,
then
we
can
revisit
this
and
hopefully
we'll
have
quorum
and
be
able
to
make
a
stronger
decision,
and
that
will
just
be
a
little
bit
more
evidence
to
discuss
what
we're
there.
We
can
do
it
without
directly
naming
names.
C
C
A
And
guess
to
your
question
about
attendance
for
meetings,
I'll
just
I
mean
like
I'll,
make
a
couple:
arrays
and
I'll
write
a
little
script.
It
will
be
annoying,
but
it's
a
one-off
if
it
doesn't
exist
and
just
do
this
properly
and
we'll
figure
it
out.
Okay,
cool
Shawna's
posted
a
link
for
a
new
dock,
for
node
module
use
cases
or
for
the
future
rundown.
If
people
can
open
that
up
and
take
a
look,
I
can
see,
we've
got
a
couple.
People
in
there.
I
can
see
that
I
indeed
can
edit
it.
You
can
see.
A
B
Hello,
hello,
hello,
sweet
alright,
so
we
are
I've
opened
a
document
here,
I'm
going
through
and
numbering
the
the
use
cases.
So
then
we
can
start
to
break
out
the
features
of
each
of
those
use
cases.
As
I
mean
you
can
pick.
One
add
them
in
and
I'll
go
through
and
organized
if
I
need
to
the
the
feature
break
out
so
start.
Thinking
of
that
relate
to
the
use
cases.
B
That's
it
for
me:
it's
going
to
be
a
lot
of
document,
editing
right
now
and
digging
through
them.
So
I
don't
know.
If
there's
anything,
we
need
to
discuss
in
chat
about
it.
Unless
someone
has
a
question
about
a
feature
or
wants
to
discuss
a
possible
feature
that
I
was
being
breaking
out
from
the
scenarios
are
use
cases
you
no.
A
Thing
one
thing
that
I
can
we
could
maybe
start
with
and
I
know
this
is
kind
of
backwards
and
maybe
not
the
best
to
the
process
but
I
think
there's
a
couple
of
obvious
features
that
we
already
know
about,
and
maybe
we
can
get
those
down
and
kind
of
work
backwards
to
the
use
cases
that
those
things
is
that
is
that
useful
or
should
we
just
start
from
a
use
case
and
talk
about
the
future?
Well,.
B
It
sounds
like
you
have
a
feature
in
mind,
so
what
is
what
feature
do
you
have
in
mind?
We.
A
A
So
one
that
we
have
here
from
number
two
from
CJ
is
dual
X:
multiple,
multiple,
multiple
format,
modules,
I,
don't
know
how
we
want
to
stage
a
bit
like
the
the
use
case
specifically
says
he
publishes
a
package
that
exports
both
kinds
of
interfaces,
so
the
ability,
the
ability
to
expose
multiple
interfaces
in
a
package.
Okay,.
G
E
A
B
A
B
One
if
I
guess
I
can
be
a
good
analyst.
Next
one
is
transpilers
and
on
the
on-demand
forgiving
language
that
to
me
is
like
Babel
registered,
it's
a
transpiler
on-demand,
so
that
is.
That
is
a
scenario
if
that
is
not
the
one
siege
had
in
mind,
we
can
revisit
that
too,
but
that
is
happens
to
be
a
scenario
which
is
loaders
in
in
real
time.
B
B
A
H
Actually
have
some
overlap
with
our
discussion
of
assemblies
and
redirects
right,
because
in
that
scenario,
presumably
you
know,
the
relative
module
resolution
should
happen.
Relative
to
you
know
whatever
is
in
the
the
parent
module
rather
than
having
to
come
up
with
some
sort
of
URL
for,
like
the
blob
in
the
in
the
database.
Right
there's
like
there
is
no
real
path
there,
so
maybe
yeah.
B
B
B
E
F
F
C
H
C
Guess
the
like
the
non
file
that
that
description
makes
me
think
that
perhaps
you
could
have
other
ways
of
prefixing
it
or
whatever
to
tell
it
where
you
want
to
come
from.
This
sounded
more
like
I
just
want
you
to
request
it
in
the
standard
way,
and
then
you
have
an
opportunity
to
do
whatever
you
want
before
it
actually
gets
loaded
I'm.
A
B
C
A
There's
rewire
is
a
really
great
example
of
that,
where
you
can
use
rewire
to
specify
from
a
module
reach
into
its
internals
and
replace
modules.
So,
like
that's,
really
useful,
if
you
want
to
mock
a
file
system
module
or
if
you
want
to
mock
a
network
request
now,
there's
a
meta
discussion
about
mocking
and
whether
or
not
it's
a
good
testing
practice.
But
that
is
not
really
our
place
to
platform.
B
Oh,
the
bindings
are
still
statically
linked,
okay,
so
we're
in
a
yes
and
mindset.
So
right
now
the
request
is
mocks
for
dependencies
and
there
there
is
a
established
scenario
and
it
like
micro
ecosystem
around
it,
with
tools
to
do
this
or
ways
to
do
this.
Okay,
so
the
next
one
is
back
to
to
Jordan's
needs
to
support
a
way
of
granular
migration.
So
I'm
thinking
the
feature
request,
there
is
granular
migration,
a
file
at
a
time.
A
As
a
yes
and
down
here
and
I
suggested
it
this
way
as
I
think
that
it's
good
to
identify
high-level
ones
that
have
multiple
use
cases
that
they
serve
so
I
would
say
in
the
spirit
of
yes
end.
You're
talking
about
interoperability,
which
is
a
high
level
feature.
And
then
let's
talk
about,
if
it's
as
a
secondary
feature,
because
I
think
if
we
do
that
or
to
notice
patterns
of
like
interoperability,
of
something
that
there's
like
a
hundred
use
cases
for,
but
then
the
specific.
So
that
will
start
to
yeah
I
mean.
H
A
Up
into
four
potential
features
and
tell
me
if
these
seem
verbose
but
module
interoperability,
bi-directional
interoperability,
transparent
interoperability
and
per
module
mode
sounds
great,
sounds
good.
Okay,
cool
and
I
think
that
when
we
start
breaking
it
up,
granular
like
this
I
hope
we'll
see
some
patterns.
So
the
next
one
John
sorry.
B
Yeah,
no,
no
worries
it's
it's
more
on,
interrupts,
I,
believe,
and
that
is
for
how
do
you
support
the
case
where
a
person
is
stuck
on
an
older
node
version
but
but
wants
to
be
able
to
consume
innocent
I
thought.
B
B
E
B
A
B
A
A
Actually
say
that
that
maybe
maybe
this
falls
under
transparent,
Interop,
okay,
like
as
a
requirement
for
transparent,
rot
because
I
think
the
idea
here
would
be
is
if
you're
importing
commonjs,
you
don't
want
to
lose
your
tree
shaking
right,
I
think
Jan
had
to
drop.
But
let's,
let's,
let's
file
this
under
transparent
interoperability.
A
Elimination
dead,
kook,
but
but
I'll
rephrase
it
it's
like
dead
code.
Elimination
really
only
makes
sense
when
we're
talking
about
shipping
assets
to
production
in,
like
a
web
environment
where
you're
grabbing
everything
over
the
wire
for
what
really
care
about
here
is
named
exports,
where
you're
only
executing
the
code.
That's
in
your
path,
like
there's
similar,
maybe.
E
E
A
It
is
just
dawned
on
me
that
we
are
at
4:04
we've
done
over
the
hour.
Yeah
not
found
I.
Think
I
forgot
to
hit
play
on
my
timer.
We
are
on
a
roll
right
now,
I'm,
not
in
a
rush
to
leave
the
meeting,
but
we
should
stick
to
the
time
if
we
have
to
just
quickly
to
the
room.
Does
anyone
think
that
we
should
stop
or
do
people
want
to
keep
going
I.
H
A
B
B
E
C
A
B
All
I'll
defer
to
OS
e
JK
Remsen
on
that.
A
B
Right,
the
the
next
items
here
are
like
questions:
what
are
people
doing
with
commonjs?
What
are
people
doing
in
other
module
systems?
What
are
people
doing
in
the
module
system
and
node?
So
it's
more
like
exploring
trying
to
dig
in
and
find
out
other
use
cases
what
do
people
dislike
or
miss
using
a
module
system
in
node.
So
those
are
more
questions
than
features
Quinn
REE
factors
an
app
and
switches
it
from
existing
common
Jas
to
implement
using
ASM.
B
E
A
A
B
B
H
B
A
So
we
have
a
really
good
set
of
use
cases
that
are
starting
we've
gotten.
You
know
about
halfway
through
the
dock,
and
then
you
know
between
now
and
the
next
meeting.
Let's
ping
people
try
to
get
them
to
add
some
more
use
cases
let's.
Actually
this
is
a
good
question
to
the
group.
Should
we
hold
off
on
these
features
until
the
meeting,
or
should
we
allow
people
to
work
in
like
on
the
way
up
to
the
meeting,
because
I
think
doing
it
in
the
meeting
at
least
has
has
the
benefit
that
everything
that's
on?
C
A
What
I'm,
imagining
we
would
do
Michael
is
like
we
would
collect
all
of
those
specific
features.
Then
the
next
iteration
would
be
grouping
them
into
kind
of
clusters
and
then
compressing
them
into
like
higher-level
features
and
then
from
there
turning
into
actual
implementation.
So,
for
example,
like
the
interrupt
stuff
would
all
just
become
part
of
the
interrupt
story,
and
then
we
could
turn
that
into
like
more
explicit.
So.
A
A
A
Okay,
great,
we
ran
a
little
long.
Does
anyone
have
any
last-minute
business
or
things
to
add
before
we
call
it
a
day
cool?
Well,
thank
you.
Everyone
for
your
time
we're
keeping
up
our
stream
of
hyper
productive
meetings,
and
it's
really
exciting
and
I'm
really
happy
to
see
that
we've
moved
this
a
step
forward.
It
feels
we're
getting
closer
to
to
the
goal.
Thanks
everyone
I'm
gonna,
stop!
The
stream
now
have
a
really
great.