►
From YouTube: Node.js Foundation Modules Team Meeting 2018-03-14
Description
A
B
A
In
there
for
a
second,
so
we
are
live
on
YouTube
and
we're
getting
started.
We
have
a
short
agenda
of
items
today,
but
a
lot
of
stuff
to
dig
into
the
first
thing
that
I
would
like
to
bring
up
is
approving
PRS
pr8,
which
is
adding
meeting
notes.
I
would
like
to
make
a
motion
to
land
this.
Does
anyone
object?
A
No
objection
that
is
quorum.
Thank
you.
We
can
move
on
to
the
next
one.
We
have
three
items
each
with
a
three-minute
time
box,
mostly
around
bringing
awareness.
The
first
one
is
issue
number
45,
which
is
ad
manifesto.
This
was
an
attempt
that
I
made
to
try
to
make
some
core
values
that
we
can
align
by.
We
have
had
a
number
of
people
sign
up,
but
not
everyone
has
signed
it.
Yet
that
is
in
no
way
me
telling
you
you
have
to
just
an
update
of
the
current
state
of
affairs.
A
I
think
that
I
may
remove
the
stuff
that
has
to
do
with
implementation,
because
that
seems
to
be
the
place
where
we're
not
all
on
board,
and
everyone
else
is
agreeing
about
everything
else.
I
will
update
that
later
today.
I
think
we
can
move
on
to
the
next
item
unless
anyone
has
anything
to
add
great.
So
if
people
have
not
seen
that
document,
if
you
could
take
a
look
and
try,
then
that
would
be
great.
The
next
one
that
we
have
is
issue
number
41,
which
is
a
use
cases
meeting.
A
C
I
am
so
there's
been
a
pattern,
at
least
in
the
github
discussions
and
in
meetings
that
we
need
to
go
over
use
cases
in
depth.
I
made
an
issue
in
the
issue,
I
also
kind
of
mentioned,
or
alluded
to
that
I
think
it
might
be
better
suited
for
somebody
else
to
run
that
I
don't
know
if
anybody
really
wants
to
take
that
up,
but
they
should
feel
free
to
do
so.
I
did
make
a
Google
Form
if
people
want
to
submit
just
use
cases
randomly
so
feel
free
to
do
that
as
well.
C
A
Great
Brad
now
for
everyone
who
hasn't
seen
the
agenda,
yet
we
actually
had
half
an
hour
plan
to
work
on
that
today.
So
after
we
work
on
it
today,
maybe
we
can
make
a
call
to
the
group
and
see
if
anyone
in
particular
wants
to
take
up
running
that
initiative.
The
next
one
that
we
have
on
here
is
the
online
module
summit.
That's
number
nine,
that's
also
Brad
Brad
can
take
the
floor.
C
Sure
so
we
issue
open
about
having
an
online
module
summit.
We
had
a
doodle
open
for
a
couple
weeks
and
we
ended
up
deciding
it's
going
to
be
on
the
third
I
haven't
posted
it
scheduled
or
anything.
Yet
we
have
a
few
people
I.
Think
five
people
have
suggested
various
topics
that
they
want
to
be
sure
are
discussed.
C
We
will
probably
have
the
schedule
out
by
I
would
say
Wednesday
next
week,
I'm
going
to
be
contacting
people
starting
tomorrow
who
have
posted
topics
or
people
who
I
think
are
interested
in
the
topics
that
are
mentioned
via
email.
So
that's
basically
what's
going
on
and
hopefully
we'll
have
the
schedule
ironed
out
two
weeks
in
advance
and
then
we'll
pass
it
off
to
people,
so
they
can
present
or
prepare
as
needed.
A
Awesome,
thank
you
very
much
Brad.
So
that
ends
the
just
kind
of
awareness
topics
which
brings
us
into
our
discussion
topics.
We
have
two
topics
right
now:
the
first
topic
that
we
have
has
a
ten
minute
time
box
and
the
second
one
has
a
30
minute
time
box,
and
we
can
move
back
to
the
issue
tracker
for
these
if
we're
not
able
to
handle
it
in
that
amount
of
time.
The
first
topic
is
issue
number
42
upstream
changes
ESM
in
nodejs,
/
node.
A
This
is
a
continuation
of
a
conversation
that
we
had
last
week
specifically
around.
What
changes
should
we
allow
or
not
allow
into
core?
There
have
been
a
handful
of
different
opinions
on
this
from
we
shouldn't
land
anything
we
should
land
everything
I
proposed.
Maybe
we
should
land
all
patches
but
not
stem
for
minors
I
also
proposed.
Perhaps
we
should
land
anything
that
doesn't
introduce
new
mechanisms,
which
I
think
is
a
little
bit
more
to
the
spirit
of
what
we're
thinking
I'd
like
to
just
leave
it
to
the
floor.
A
C
Sure
so
I
would
just
like
to
see
if
there's
anything
controversial,
about
landing
things,
4vm
dot
module
which
I
don't
think
has
really
had
any
controversy
around
it.
So
far,
it's
mostly
trying
to
give
an
API
with
direct
integration
against
speck
mechanics,
so
maybe
I
am
more
on
the
we
need
to
vote
per
feature
set
side
of
things.
C
E
B
A
Excellent
to
be
really
explicit,
I
think
that
the
two
things
that
are
really
moving
forward
right
now
in
core
that
people
would
like
to
see
continue
to
move
forward.
One
is
named
exports
and
I.
Don't
think
that
that's
controversial
I
think
that
being
able
to
do
named
exports
from
a
core
module
is
something
we're
just
going
to
want
to
do
so.
Just
quickly.
Does
anyone
object
to
named
exports
Brad,
you
have
your
hand
up
yeah,.
C
F
That's
why
it's
probably
fine
until
it
named
exports
go
through,
but
there
be
philosophical
problems
with
how
the
implementation
is
done
and
the
fact
that,
if
we
do
merge,
it
potentially
is
used
as
a
reason
to
not
bother
to
do
other
things
that
make
life
better
for
people
who
aren't
node
core.
Okay,.
G
G
Don't
think
it's
certain,
at
least
within
along
the
core
collaborators
right
now,
if
we
can
actually
go
forward
with
it,
as
is
because
it
if,
unless
I'm
out
of
date
on
it,
it
will
make
our
deprecations
not
work
when
using
it
so
or
or
we
can't
actually
like
export
those,
because
we
can't
run
a
function.
In
that
case,
it
can't
be
like
a
getter
anymore.
It
has
to
be
the
actual
variable
value
which
causes
problems
for
a
lot
stuff.
We've
been
doing
so.
We
need
to
find
a
way
around
that
so.
A
A
H
Yeah
I
just
wanted
to
address
what
Brad
had
to
say,
which
was
in
these
cases
where
I
think
it's
fine
for
us
to
as
a
group
go,
we
don't
have
any
there's.
No,
you
know
if
there's
no
objections
from
the
modules
working
group.
We
can.
You
know,
move
on
from
that
like
this.
This
is
one
of
those
cases
very
I,
it's
user
visible,
but
it's
uncontroversial
and
we'll
have
to
just
address
those
on
a
case-by-case
basis.
I
think
what
I
just.
I
I
think
I
I
just
wanted
to
kind
of
respond
to
Rebecca's
comment.
I
think
that
that
absolutely
we
should
be
able
to
as
a
group
decide
that
a
specific
change
is
fine
to
go
forward,
even
if
it
goes
against
the
overarching,
like,
let's
avoid
user,
visible
changes
for
the
moment.
Kind
of
philosophy
where
I
am
very
concerned,
is
going
forward
with
anything
that
could
kind
of
leak
out
into
the
packaged
ecosystem.
I
I
have
like,
for
example,
a
node
binary
flag
that
can
only
affect
really
people
who
are,
you
know
like
running
them
things
themselves,
but
something
that
goes
in
package.json
that,
like
you
know,
if
that's
a
good
thing
that
goes
out
in
the
ecosystem
and
it's
fine.
But
if
that's
a
bad
thing,
then
that's
something.
That's
polluted
the
ecosystem
for
potentially
ever
so
I
think
we
should
have
a
lot
of
caution
around
those
sorts
of
things.
Ok,.
J
Think
there's
just
other
option
instead
of
figuring
out
the
rules
by
which
we
want
or
not
want
to
define
what
enters,
what
we
approve
of
or
not,
maybe
just
have
a
rule
which
says
if
anybody
disapproves.
If
this,
if
this
working
group
disapproves
of
one
of
the
boat
requests,
then
that
does
not
land
instead
of
trying
to
figure
out
what
rule
it
is
we
don't
like
ESM
mode,
we
can
say
that
this
working
group
disapproves
of
it.
We,
like
the
other
one,
that's
fine,
I,
think
trying
to
define
a
rule.
A
The
only
thing
stated
that
Gil
would
be
that
I
think
that
we
want
something
that's
push
rather
than
pull
like
if
we
have
to
have
whole
group
constantly
on
top
of
everything,
and
we
don't
have
a
set
rule,
it
makes
it
really
hard
to
make
sure
that
we're
keeping
to
the
spirit
of
it.
So
perhaps
a
compromise
to
what
we're
all
talking
about
right
now
would
be
thunder
patches
can
land.
G
So
I,
okay,
so
that
might
work
for
now.
I
just
want
everyone
to
keep
in
mind
that
this
group's
probably
not
going
to
exist
forever,
and
that
probably
will
be
a
point
in
time
at
which
you
know
things
do
do
land
that
are
that
are
I,
guess
less
in
our
control
and
they
may
change
things
in
in
ways
that
or
may
add
things
that
you
know
worst
not
so
fond
of.
But
at
some
point
we'll
have
to
accept
that.
That's.
A
Fair
that
makes
a
ton
of
sense.
We.
This
is
a
one
minute
warning
on
the
time
box.
Gus,
you
had
your
hand
up.
Did
you
still
want
to
talk?
Are
you
good?
I'll
assume,
no
hand
means
are
good,
so
so
we
were
gonna,
also
bring
up
the
VM
module
and
being
able
to
use
ESM
in
the
VM
module
so
like
quickly
to
the
group.
Does
anyone
have
a
problem
with
implementing
features
that
the
VM
module
can
execute
ESM
code,
but
it
does
not
change
at
all
any
of
the
mechanisms
of
esm
at
the
moment.
I
It
feels
like
the
larger
controversies,
or
you
know,
lack
of
clarity
that
we
have
are
around
specifically
the
disambiguation
mechanism,
or
you
know,
ESM
versus
CGAs
or
script
versus
module
and
I.
Think
that
anywhere,
where
the
ambigú
a
ssin
or
where
the
parsing
goal
is
explicit
and
non-controversial
is
likely
to
be
okay
and
I.
A
Okay,
so
I
think
that
since
we're
now
at
a
time,
we
can
kick
that
back
to
the
issue.
Tracker
I'll,
open
an
issue
so
that
we
can
start
drafting
a
recommendation
to
the
technical
steering
committee
and
then
hopefully,
in
the
next
meeting,
we
can
reach
consensus
on
that
recommendation,
which
we
can
send
to
the
TSE
or,
alternatively,
I
can
present
it
next
week
if
we
can
reach
consensus
in
the
issue.
A
The
last
item
that
we
have
on
the
agenda
today
is
use
cases
for
ESM
in
node.
I
would
like
to
maybe
suggest
that
either
CJ
or
Rebecca
start
this
off,
because
they
were
both
very
passionate
and
had
some
ideas.
So
I'm
gonna,
you
know
hand
the
floor
off
to
whoever
wants
to
kind
of
lead.
This
discussion
Oh
kick.
B
It
off
first
as
someone
who's
noisy
last
week
about
wanting
use
cases
I'm
gonna,
about
to
paste
a
list
to
a
link
to
adjust
in
the
chat.
This
was
my
first
whack
at
describing
things
that
our
users
do
with
modules
now
and
might
reasonably
be
expected
to
do
in
the
future.
I'm,
not
gonna.
B
This
list
is
not
comprehensive,
but
I
wanted
to
get
us
thinking
about
the
kinds
of
things
we
wanted
to
describe
in
a
use
case,
a
couple
of
sentences
at
a
very
high
level,
not
dipping
into
implementation
that
talks
about
things
developers
using
node
will
want
to
do
things
that
they
can
do
now
things
that
they
will
want
to
continue
doing
in
the
future
as
well
as
starting
to
get
into
interoperability.
Use
cases
these
once
we
have
an
agreement
about
like
what
the
use
cases
are
we
want
to
support.
B
B
Bob
is
updating
a
module
for
his
work
and
he
needs
to
export
existing
comma
J
s
using
code
bases,
as
well
as
a
new
project
that
wants
to
use
es6
for
static
analysis
reasons.
He
publishes
a
packages
that
exports
both
kinds
of
interfaces
carol
is
updating
her
popular
code
coverage
reporting
tool
for
the
new
world.
She
uses
ESM
loader
hooks
to
instrument
test
code
as
it
is
imported,
so
she.
B
Yes,
David
is
writing
a
transpiler
here,
it's
a
custom
hook
the
transpile
source,
as
it's
loaded
from
his
language
to
JavaScript
Eugenia,
wants
to
abandon
the
common
jsapi
entirely
for
her
existing
name
PM
package
and
moved
to
new
ESM.
Only
api
hermione
wants
to
load
modules
from
a
database,
not
from
the
file
system.
She
writes
a
custom
loader
hook
to
do
it.
Ian
wants
to
replace
the
dependency
of
a
module
with
mocks
while
testing.
He
writes
a
custom
hook
to
do
so,
and
this
I
think
is
a
good
start,
but
by
no
means
complete.
B
C
I,
like
the
list,
my
dogs
squeaking,
a
toy
I
like
the
list,
but
I'm
a
bit
concerned
that
it
focuses
a
bit
too
much
on
how
these
use
cases
are
filled.
I
mean
we're
avoiding
implementation,
talk
on
purpose,
but
some
of
these
seem
a
little
less
flexible
than
I'd
hope,
for
example,
on
the
third
one.
Carol
is
making
a
code
coverage
tool
and
she's
using
ESM
loader
hooks,
but
there
are
also
alternatives.
We
could
look
into.
These
use
cases
seem
very
biased
towards
preserving
existing
behavior.
You.
B
C
K
B
Cases
for
that
as
well,
I
wanted
to
kick
the
discussion
off
by
starting
with
bread
and
butter.
No
two
use
cases,
because
you
know
we
are
primarily
focusing
on
node
and
what
people
are
doing
with
node
but
and
then
let's
go
on
from
here
and
think
about
the
other
things.
People
are
doing
that
I
that
I
didn't
that
I
didn't
get
to.
Let's
expand
the
list.
Okay,.
L
Just
wanted
to
mention,
you
know,
I,
think
that
the
point
about
you
know
how
long
is
this
light
was
potentially
getting
I
would
like
to.
You
know
not
be
too
afraid
of
just
you
know
imagining
the
scenarios-
and
you
know
as
time
goes
on,
we
can
be
more
prescriptive
about
what
we
feel
as
possible,
not
possible,
but
let's
not
let
that
demotivate
us
from
you
know
trying
to
just
hear
out
what
our
users
are
have
in
mind.
M
It's
a
common
of
the
repression
of
there
Carol
and
the
code
covers
thing
because,
for
example,
for
me,
I
would
see
the
chrome
inspect
built
in
full
coverage
that
is
now
rolling
out
as
a
really
good,
an
attorney
to
putting
anything
into
the
bundle
system.
As
long
as
a
chrome,
dev
tools,
foot
coverage
works
as
expected.
M
A
B
A
Guy
your
hand
is
up
next,
but
a
couple
hands
got
raised
during
this
session.
Is
yours
a
direct
comments?
What
we
were
just
talking
about.
A
C
N
Yes,
so
just
to
say,
first,
the
list
of
use
cases
looks
great
to
me.
The
only
one
I
wanted
to
mention
briefly
and
it's
kind
of
aside
points,
but
just
maybe
just
worth
thinking
about
a
little
bit
and
I
know
that
a
lot
of
the
other
points
will
probably
create
a
hook
like,
for
example,
being
able
to
mock
modules
or
being
able
to
add
coverage
will
probably
end
up
being
a
translate
or
a
load
hook.
N
But
having
a
transpiler
is
a
first-class
use
case.
As
someone
who
has
spent
a
lot
of
time,
writing
transpilers
and
loaders
that
do
transpiling,
it
is
still
something
that
I
wonder
whether
it
should
really
be
treated
as
a
first-class
use
case,
because
it's
sort
of
the
experience
that
I
find
is
that
if
we
support
transpilers
is
first-class
in
many
cases
they
can
become
slow
for
the
ecosystem
and
in
many
cases
they
might
not.
They
might
want
more
functionality
than
just
a
hook
that
can
do
translations
of
sources.
N
K
Yes,
yeah
I
mean
I,
don't
know
if
we
want
to
drill
to
deeper
here
and
normally
I
wouldn't
say
that
you
want
to
kind
of
like
eliminate
a
use
case,
because
somebody
might
consider
that
a
use
case
that's
important
to
them
and
especially
because
the
feature
is
useful
across
multiple
use
cases.
But
in
this
case
the
you
did
touch
on
a
concern
I've
had
about
her
package.
K
Loader
hooks
is
that
if
they're
used
for
transpiling
and
people
start
publishing,
say
to
NPM,
you
know
pre
transpiled
code,
you
kind
of
have
a
possibility
of
a
contagion
effect
where
what
you're
getting
published
requires
the
motor
hooks
to
work
at
all,
and
so
this
kind
of
isn't.
You
know,
I,
don't
know
if
this
is
kind
of
a
a
use
case
to
be
discouraged
or
if
there
should
be
such
a
category
of
things.
But
that
kind
of
compatibility
concern
is
something
that
I've
been
thinking
of
in
relation
to
this
here.
A
Thank
you.
One
thing
I
would
like
to
add
really
quickly
before
we
continue,
as
I
would
like
to
encourage
people
to
focus
more
on
user
stories
and
usability
of
their
like
the
developer
experience
of
modules,
rather
than
lower
level
implementation
details
for
right
now.
If
we
can,
although
I
don't
want
to
stop
people,
you
know
from
exploring
topics
that
they
want.
As
a
quick
heads
up
this,
we
have
about
seventeen
and
a
half
minutes
left
Chris.
You
would
raise
your
hand
Wes
your
hand
was
raised.
Next.
L
Okay,
there
you
go
yeah
just
Daniel
here,
just
wanted
to
kind
of
I
guess.
Second,
second,
the
point
right
like
I'm,
not
necessarily
big
on
people
running
tight
rips,
clearly
like
just
as
a
as
a
tool,
but
you
know
it
I,
don't
think
it's
necessarily
something
where
we
want
to
remove
these
scenarios
right
like
if,
if
we
believe
this
is
something
that
no
users
you
do
today
like,
we
definitely
want
to
consider
continue
considering
whether
it's
something
that
should
be
done
tomorrow
as
well
right,
yeah,
I,
know.
F
And
playing
off
of
what
Daniels
saying
seeing
the
ESM
upgrade
as
a
chance
to
like
start
fresh
and
clean
is
just
feels
completely
incorrect,
like
is
in
addition
like,
you,
can
have
a
deprecation
path
for
these
things,
but
that
should
be
the
standard,
deprecation
path
where
you
say
this
is
a
bad
thing.
We
want
to
remove
it.
The
ESM
is
not
an
opportunity
to
just
stop
doing
them.
It
should
be
seen
as
an
extension
of
what's
already
here,
not
a
greenfield
project.
O
A
P
So
my
mo
here
with
the
user
stories
just
it
might
be
useful
to
start
by
listing
all
the
things
that
people
are
doing
now
with
comma
J
s
without
ascribing
value
to
them.
It's
gonna
be
really
tempting
to
bring
our
expertise,
our
individual
experiences
with
the
module
system
and
to
try
to
editorialize
first
but
I,
think
it
would
be
useful
to
list
them
all
and
then
find
out,
what's
possible
and
easy
to
do
and
easy
to
address
with
implementation.
And
what
like?
P
At
that
point,
that's
where
we
have
the
discussion
like
okay,
these
are
the
things
that
we
want
to
support.
These
are
the
things
that
we
can't
support
for
whatever
reason,
and
we
want
to
take
that
to
save
this
body
or
someone
else.
Or
can
you
want
to
drop
these,
but
we
make
the
explicit
decisions
after
we
kind
of
have
the
the
beast
here,
and
these
are
stories
they
numerated.
M
M
M
So
one
thing
that
I
was
wondering
was:
we
have
a
lot
of
use
cases
that
are
based
on
what
people
are
doing
right
now
and
what
people
are
successful
in
doing
when
they
use
come.
Jess
I,
think
one
interesting
source
for
use
case
might
also
be
what
are
people
interest
in
doing
that
they're
currently
unable
to
do,
or
that
is
currently
bad
to
do
in
college.
M
M
Think
it's
also
interesting
music
these
days
and
to
that
effect,
I
entered
for
possible
discovery
questions
as
a
comment
to
the
gist,
which
is
what
we're
doing
on
the
accommodation
note
already,
then
also
what
are
people
doing
in
other
multimedia
systems
outside
of
node,
but
a
use
case
that
exists
that
I'm,
possibly
just
impossible
and
now
I
know
what
people
like
about
using
the
proper
uses
to
know
that,
but
people
would
dislike
for
existing
is
I.
Think
at
least
could
discover
some
use
case
that.
C
A
Okay,
great
so
at
the
moment
we
don't
have
any
hands
up
and
I
think
that
we've
done
a
good
job
of
kind
of
going
through
this
document.
I
don't
know
that
it's
the
best
use
of
our
meeting
time
to
iterate
on
specific
use
cases,
but
I
think
we've
identified
a
handful
of
different
places
where
we
want
to
build
more
use
cases
and
more
user
stories.
So
we
have
like
kind
of
the
straight
node
user
stories.
We
have
the
node
browser
Interop
user
stories.
A
We
have
the
forward-thinking
future
greenfield
ESM
user
stories
in
the
issue
John
David
Dalton
had
raised
in
the
issue
that
they
would
be
willing
to
help
kind
of
lead
this
future
meeting.
So
what
I
think
might
make
a
mint
a
lot
of
sense
from
a
time
perspective
is,
if
all
of
us
asynchronously
start
filling
out
that
Google
form
that
Brad
has
made
to
start
adding
more
use
cases
to
the
list
and
then
John
can
make
a
meeting
specifically
for
the
use
cases
or.
A
Alternatively,
if
you
know
the
timing
makes
sense,
maybe
we
can
iterate
on
that
list
in
the
issues
and
bring
it
back
to
the
next
meeting
and
in
fact,
I
think
that
would
actually
be
a
really
good
thing
for
us
to
use.
We
have
about
10
minutes
left
on
this
topic.
We
don't
need
to
use
all
that
time,
but
just
kind
of
a
question
to
everyone.
P
A
With
that
being
said,
I
know
that
we
have
kind
of
like
a
forum
set
up
for
collecting
them.
Do
you
think
perhaps
a
shared
Google
Doc
that
we
could
comment
in
and
kind
of,
have
the
conversation
in
make
sense
as
a
way
to
iterate
on
this
yeah
github
issues
are
great,
but
one
of
the
things
I
like
about
Google
thoughts,
in
particular
I,
know:
I'm
an
employee
I'm
not
trying
to
push
it,
but
it's
just
the
ability
to
offer
suggestions
and
to
comment
on
them.
A
A
A
So
if
anyone
is
interested
in
doing
this
kind
of
moderation,
work
I'm
more
than
happy
to
you
know
not
do
it,
because
it's
a
little
harder
to
participate
in
the
conversation
when
I'm
the
one
who's
organizing
it
I've
been
kind
of
like
shutting
in
a
few
ideas,
but
the
balance
of
what's
ethical.
There
is
an
interesting
challenge.
Jeremiah
your
hands.
Still
up
did
I
forget
to
lower
it,
or
do
you
still
have
something
to
add?
Okay,.
A
Q
Q
So
this
was
a
presentation.
I
gave
last
week
to
the
webassembly
community
group
we're
starting
an
effort
to
have
web
assembly,
yes,
module
integration,
and
so
I'll
start
with
the
goal
of
the
proposal.
Today
in
web
assembly,
we
have
an
imperative
JavaScript
API
for
creating
module
instances.
So,
let's
use
a
function
from
a
module.
You
have
to
set
up
the
request
to
fetch
the
module
file.
Then
manually
set
up
the
imports
manually
trigger
instantiation,
and
then
at
that
point
you
can
finally
call
a
function.
Q
So
this
proposal
is
to
add
a
declarative
API,
in
particular
the
es
module
API.
So
with
this
API,
the
request
for
the
file
setting
up
the
imports
and
instantiation
would
all
happen
implicitly,
so
that
should
make
web
simply
modules
easier
to
instantiate,
but
the
bigger
benefit
is
that,
with
this
web,
some
blame
artisinal
graphs
with
JavaScript
modules,
so
this
will
make
it
easy
for
web
developers
to
combine
functionality
from
web
assembly
modules
and
JavaScript
modules
from
a
use
perspective.
That
is
why
we
want
es
module
support
from
an
engine
level
perspective.
Q
What
do
we
as
modules
do-
and
this
may
be
a
little
bit
of
review
for
some
of
the
folks
in
this
group,
but
I
just
wanted
to
make
sure
it
was
there
for
the
web
assembly
folks,
and
if
anyone
in
this
group
has
comments
on
how
I've
described
the
stuff
here,
please
do
feel
free
to
shoot
me
a
message.
So
what
do
they
do
from
an
intial
engine
level
perspective?
They
provide
a
lexical
environment
for
the
outer
scope
of
the
module,
and
so
the
way
that
this
lexical
environment
is
different
from
function.
Q
Lexical
environments
is
that
the
boundaries
are
semipermeable
with
other
lexical
scopes
in
jail,
such
as
function
scopes.
You
can't
have
sibling
scopes
accessing
each
other's
variables,
but
with
modules
you
can
say
which
variables
should
be
accessible
by
other
modules,
using
the
export
statement
and
then
other
modules
can
import
them.
So
this
provides
a
link
between
them
and
makes
it
so
that
the
importing
module
can
access
the
variable
from
another
scope.
Q
So,
yes,
modules
do
this
in
a
different
way
from
other
module
systems.
It's
different
from
both
commonjs
and
from
web
assemblies
jsapi,
which
both
copy
values
instead
ESM
uses
live
bindings,
so
both
the
exporting
module
environment
record
and
the
importing
module
environment
record
point
to
the
same
memory,
location
and
I
know
this,
because
it
has
implications
for
how
web
assembly
ESM
should
work
before
I
talk
about
that,
though,
I
want
to
do
a
short
walkthrough
of
how
es
modules
work
for
JavaScript.
Q
So,
let's
see
with
es
modules,
you
can
import
and
export
things.
So
we
have
this
whole
graph
of
modules
that
are
exporting
values
and
references
and
other
modules
that
are
importing
those
values
and
references.
So
how
does
this
get
loaded?
Well,
the
work
happens
in
three
phases:
there's
construction,
instantiation
and
evaluation,
and
people
talk
about
es
modules
being
async,
and
you
can
think
of
it
as
such,
because
execution
yields
the
event
loop
after
each
phase,
but
the
phases
themselves
are
not
necessarily
asynchronous.
They
can
actually
be
done
synchronously.
Q
Q
So
we
start
with
an
entry
point
to
this
graph,
for
example
the
source
of
the
script
tag,
and
we
fetch
that
file,
and
then
we
parse
it
to
figure
out
the
next
set
of
files
that
we
need
to
fetch,
which
is
the
requested
modules
property
on
the
module
record.
And
then
we
continue
fetching
and
parsing
until
all
of
the
requests
and
module
properties
are
empty
and
all
of
our
leaf
module
records.
So
half
of
this
work,
the
loading,
the
fetching
of
files,
those
are
specified
in
the
loader
spec,
at
least
for
the
browser.
Q
The
parsing
part
of
the
stage
is
in
these
modules.
Back
while
we'll
need
to
change
some
language
in
the
loader
spec,
we
shouldn't
actually
need
to
make
any
major
changes
for
web
assembly
support.
So
at
the
end
of
the
construction
stage,
you've
downloaded
all
these
module
files,
files
and
parse
them
into
module
records,
and
some
implementations,
such
as
spider,
mock
monkey
or
JSC,
we'll
also
create
the
module
environment
record
here
and
wire
up
the
exports
to
their
memory
locations.
But
per
the
spec,
this
isn't
necessary
until
the
instantiate
phase
is
completed.
Q
Q
If
it
hasn't
already
been
created,
the
module
environment
record
needs
to
be
created
here
and
have
its
exports
wired
up,
but
we
already
did
that
imports
need
to
be
wired
up
to
those
exports,
so
this
happens
as
a
depth-first
postorder
traversal.
So
we
go
down
to
the
leaf
note
that
has
no
imports
and
then
come
back
one
level
up
to
hook
up
the
imports
from
the
module
that
depends
on
that
leaf
to
the
exports
from
that
leaf.
Node,
as
I
mentioned
before
these
are
live
bindings.
The
important
export
are
pointing
to
the
same
memory
address.
Q
The
one
exception
to
this
is
functions
which
are
initialized
at
this
point
and
the
reason
to
have
live
bindings
in
for
instantiation
to
be
separated
from
evaluation
so
that
we
can
handle
cyclic
dependencies.
So,
for
example,
if
you
have
a
cyclic
dependency
and
common
chasse
between
a
and
B,
where
a
exports
of
value
which
B
then
imports
using
destructuring
assignment
when
P
imports
it
a
hasn't
yet
finished
evaluating
the
variable,
it
hasn't
yet
finished
evaluating
the
code.
Rather
so
the
value
is
still
undefined
for
that
variable.
Q
So
yes,
modules
get
around
this.
By
doing
this
linking
step,
all
of
the
imports
are
going
to
be
undefined
throughout
instantiation.
At
this
point,
you're
just
wiring
them
up
to
the
memory
addresses
no
values
are
expected.
Yet
the
next
step
is
evaluation
which
goes
through
and
fills
in
all
of
the
variable
values,
and
it
does
this
by
running
the
top
level
code
and
there
can
also
be
side
effects
like
requests
sent
out
to
servers.
Q
So
evaluation
is
only
allowed
to
run
once
for
every
module
and
then
the
instance
is
cached
and
the
catch
holds
one
instance
per
module
per
document
or
worker,
at
least
for
JavaScript,
yes,
modules,
and
these
are
cash
based
on
their
canonicalized
URL.
So
how
does
this
work
for
web
assembly?
Well?
The
first
phase
is
pretty
easy.
That's
the
loading
and
parsing.
So
during
this
face
we
would
let
the
loader
fetch
web
assembly
files,
and
then
we
would,
when
parse
module
is
called
on
each
file.
Q
After
that,
during
the
evaluation
phase,
we
would
run
the
start
function.
So
the
start
function
is
something
that
web
simply
gives
you
that's
equivalent
to
the
top-level
module
code
in
a
JavaScript
module,
so
an
engine
wouldn't
actually
have
to
implement
things.
This
way,
though,
it
could
just
do
a
light
decoding
phase
in
the
construction
just
to
pull
out
the
imports,
and
then
it
might
do
compile
an
instantiation
during
the
instantiation
phase
once
it
has
all
of
the
imports.
Q
So
that's
how
es
modules
could
actually
work
for
web
assembly
in
a
pretty
straightforward
way,
but
what
are
some
of
the
problems
here?
One
of
the
problem
spots
for
web
simply
is
live
bindings,
so
they
enable
the
cyclical
dependencies
that
we
want
to
have
between
Wazza
modules
and
also
between
Jas
and
Wisel
modules.
But
what
does
it
mean
to
have
a
live
binding
between
a
JavaScript
value,
we're
from
web
some
to
a
JavaScript
value?
Q
For
example,
if
you
have
an
export
and
that
experts
going
to
be
a
numerical
value
currently,
it
will
be
copied
when
it's
imported,
so
for
now
in
the
short
term,
live
findings
between
Jay
s
and
webassembly.
Aren't
going
to
work
because
at
the
time
that
webassembly
is
going
to
be
reading
the
live
binding,
the
value
is
undefined.
Q
One
thing
to
note:
if
a
web
assembly
module
exports
a
function
memory
table
are
global,
we
may
be
able
to
make
this
work
and
functions.
We
may
be
able
to
make
this
work.
We
may
be
able
to
initialize
those
during
the
instantiation
phase,
but
that's
currently
a
point
of
contention
in
the
web
assembly
community
group
in
the
future.
Q
So
on
the
topic
of
cyclic
imports,
currently
the
es
module
spec.
This
allows
cyclic
imports
for
any
module,
which
is
not
a
JavaScript
module.
We're
going
to
need
to
work
with
tc39
to
change
that
wording
in
the
spec.
It
should
just
mean
factoring
out
some
of
the
cycle
handling
code
from
the
source
text,
module
record
into
a
common
base
class.
Q
Q
Even
once
we
have
native
support,
brow
and
browsers.
Bundlers
are
still
likely
to
be
used
by
a
lot
of
projects
because
they
reduce
the
number
of
HTTP
requests
and
they
do
this
by
combining
a
bunch
of
modules
into
a
single
file
and
adding
a
little
bit
of
runtime
to
load
them.
So
because
of
this,
they're,
probably
still
going
to
need
to
rely
on
the
JavaScript
API,
at
least
at
least
until
you
can
have
multi
module
files.
Q
But
they
want
to
emulate
the
es
module
API,
because
that's
what
authors
are
authoring
so
with
the
current
jsapi
that
we
have
for
web
assembly
much
it's
difficult
for
bundlers
to
emulate
yes,
modules,
while
still
using
instantiate
streaming,
which
is
the
most
efficient
way
to
instantiate
a
web
assembly
module.
And
that's
because
instantiate
streaming
requires
that
you
have
a
fully
initialized
import
object
so
that
all
of
your
imports
are
already
initialized.
But
if
you're
only
importing
functions.
Even
if
you're
only
importing
functions,
this
is
only
if
available
after
the
dependencies
instantiate.
Q
Q
A
C
L
Q
L
A
A
Awesome,
so
thank
you.
Everyone
for
for
coming
today,
just
going
over
kind
of
like
some
of
the
high-level
follow-ups
I'll
follow
up
with
making
an
issue
to
make.
So
we
can
come
up
with
the
text
to
give
a
recommendation
to
the
technical
steering
committee.
John
is
going
to
follow
up
with
starting
to
collect
all
of
the
use
cases
and
make
the
Google
Doc.
So
we
can
start
iterating
and.
A
The
last
bit
that
I'm
thinking
about
here
I
thought
this
presentation
at
the
end
was
actually
a
really
great
way
to
kind
of
wrap
up
the
meeting
and
us
all
I
guess
respecting
the
fact
that
we
wanted
to
give
this
stage
to
someone
at
the
end
helped
us
kind
of
like
keep
the
conversation
really
tight.
So
maybe
this
is
something
that
we
should
explore
for
future
meetings,
that
if
people
have
presentation
topics
that
did
like
to
present
to
the
group,
maybe
that's
something
we
could
do
at
the
end.
A
So
if
anyone
has
ideas
for
other
presentations
that
they'd
like
to
make
in
a
future
meeting,
maybe
open
an
issue
about
that,
we
could
discuss
whether
or
not
you
know
like
that
makes
sense,
and
it's
appropriate,
because
I
thought
this
was
a
really
great
way
to
round
it
out.
I
think!
That's
it!
So.
Thank
you.
Everyone
for
joining
us
to
the
handful
of
people
who
are
online.