►
Description
Wherein ZB from MetaMask/Consensys and Peter and Patrick from Moddable meet to discuss options for the timing of the importMetaHook and also how to overload the module descriptor object.
A
A
C
So
that's
that's
one
thing.
I
was
considering
putting
into
the
design
of
any
changes
we
want
to
make
to
the
static
module
record,
so
it's
not
going
to
be
necessary
anymore
to
do
this,
but
this
is
just
a
bunch
of
context
and
I
think
what
we
want
to
focus
on
is
more
about
introducing
stuff
like
import,
meta
and
the
hook.
C
C
Actually
needed
and
there's
this
part
that
analyzes
the
whole
thing
analyzes
the
the
module
being
loaded
and
it
can
already
find
what's
sitting
on
the
import
as
a
keyword,
so
any
member
expression,
so
import
dot,
meta,
dot.
Something
is
going
to
land
in
import
matter
priorities
and
then
I'm
wrapping
it
into
these
temporary
flags
uses
import
meta
and
a
list
of
properties
that
are
actually
being
used,
and
based
on
that,
I
can
know
if
I
want
to
yeah,
let's
find
github
you're
trying
to
be
helpful.
C
D
D
C
A
A
C
A
C
D
C
This
is
the
one
that
we're
doing
for
the
standard
modules,
and
here
I
implemented
the
rewrite
from
import.meta
into
the
hidden
variable
dollar,
h,
underscore,
etc,
and
since
it
was
already
here
and
each
other's
element
had
the
analyze
step,
I
thought
let's
see
how
much
I
could
do
with
the
analyze
step.
So
this
draft
has
an
implementation
of
detecting
some
fields
that
happen
to
be
on
the
meta.
A
C
Not
much
to
be
honest,
but
there's
two
places
where
I
started,
considering
putting
the
use
of
this
information.
So
currently,
if
I'm
using
import
meta,
an
import
meta
hook
is
available,
I'm
trying
to
get
it
either
at
the
time
the
module
is
loaded
because
that's
when
we're
awaiting
things-
and
that
means
invert
meta
hook-
could
be
awaited.
D
D
A
A
B
B
There
is
nothing
inside
meta
the
in
time
we
populate
the
ufi
property
of
import
meta
in
it
for
some
for
some
time
that
that
are
using
it.
But
but
it's
not,
there
is
nothing.
It's
really.
It's
so
platform
specific
that
even
from
access
point
of
view
it
it's
really
depending
on
the
the
us
and
everything
and.
B
C
B
B
B
Time
every
time
you
load
a
module,
you
have
the
possibility
to
provide
an
object.
The
object
is
copied
into
the
import
metal,
with
the
object
assign
semantic
so
going
I
mean
exactly
that,
calling
in
fact
that
and
and
so
the
and
I
mean
that
that
works
well,
and
I
I
think
I
know
I'm
sure
I
commit
several
examples
of
that
in
the
in
the
x-nap
example,
and
yes,.
D
D
D
B
The
size
is
okay,
okay,
so
yeah.
Here
we
have
out,
we
create
two
new
static
module
records
which
allow
us
to
check
if
there
is
to
get
import
with
the
ui,
and
so
the
compartment
is
having
a
module
map.
With
two
envelope
I
mean
descriptor
module
descriptor,
it's
a
record
module
descriptor.
So
it
has
a
recall
this
one
and
it
adds
some
meta
object
with
a
uri
property
which
is
arbitrary.
B
So
if
I
do
a
c
import
of
this
one,
cb.js,
okay,
it
will
load
that
and-
and
so
this
will
import
a
from
dos-
I
mean
dot,
slash
a
dot
js
which
will
get
patrick
and
so
on.
If
and
then,
if
I
print
the
default,
I
will
leave
a
which
is
that
string
plus
that
string,
which
is
bit
of
js.
So
it's
completely
it's
completely
open.
B
B
B
B
B
B
D
B
C
C
C
C
A
A
I
think
that
the
only
reasonable
top
the
most
obvious
reasonable
time
to
do
that
would
be
immediately
after
calling
the
load
hook
right
and
if
it
happens
at
that
time,
then
there's
no
reason
to
not
do
the
same
behavior
within
the
load
hook,
provided
that
the
static
module
record
constructor
provides
the
metadata
that
it
needs
in
order
to
perform
the
operation
and
then
just
include
it
on
the
meta
property
of
the
property
of
the
module
descriptor.
Is
that
about
right,
yep,
good
question:
go
ahead,
mark.
A
A
Yeah,
though,
in
order
for
that
to
be
true,
the
static
module
record
would
need
to
return
an
object
that
tells
you
whether
the
import
meta
is
needed,
and
I
think
that
that's
also
reasonable
to
allow
the
static
module
record
constructor
to
do
some
additional
static
analysis
and
add
a
property
so
that
the
load
hook
could
use
it.
Okay,.
D
Memory
from
a
first
evaluation
to
other
evaluations,
either
the
expression
evaluates
to
something
that
already
exists
and
in
which
the
whatever
side
effects
that
might
have
been
caused
by
it's
already
existing
have
already
happened,
or
it's
evaluated
afresh
every
time
with.
No,
so
the
the
you
know,
the
kind
of
reinferency
attack
issue
right.
D
Each
time
it's
evaluated
means
that
the
that
you
know
the
the
about
that
the
expression
is
effectively
a
procedure
call
to
whatever
those
things
are,
but
having
the
side
effects
happen,
the
first
time
and
then
memoized,
so
it
doesn't
happen
later
times
for
an
expression
seems
weird
like
I
said
it's
not
disqualifying,
but
it
seems
weird
so
having
it
hap
having
it
happen
up
front
before
module
evaluation
happens
and
having
it
happen.
There
therefore,
based
on
static
appearance
rather
than
evaluation,
does
seem
cleaner
to
me.
D
A
Okay,
let's
so
just
to
summarize
where
we
are
so
far
in
the
conversation,
I
think
that
we
are
going
to
narrow
the
conversation
to
the
distinctions
between
options.
A
and
b
option
c
is
off
the
table,
except
for
possibly
coming
back
and
having
another
conversation
about
revealing
whether
import.meta
is
uttered
in
the
source
as
a
property
of
the
static
module
record
constructed
by
that
constructor
and
we'll
just
table
that
issue.
For
now,
the
distinction
between
a
and
b,
I
believe,
the
biggest
distinction
between
options.
B
B
A
Yeah,
so
to
be
concrete
option
b.
My
understanding
of
option
b
is
that
the
import
meta
hook
would
be
called
at
the
beginning
of
the
synchronous
execution
of
the
initialization
of
that
module
in
which
is
to
say
the
first
turn
of
its
initialization.
If
you
take
into
account
the
top
level
of
weight,
and
so
if
an
error
were
thrown
at
that
time,
it
would
foul
the
promise
for
that
module
and
any
module
that
depends
upon
it.
A
Before
any
of
the
code
in
that
module
has
an
opportunity
to
execute
there,
let's,
there
might
be
an
even
more
defensive
position
to
stand,
which
would
be
to
say,
let's
call
it
option
d,
which
is
an
option
b
variant
that
all
of
the
import
meta
hooks
for
the
working
set
that
are
about
to
be
executed.
Synchronously
would
be
collectively.
A
That
would
be
synchronous
with
initialization,
but
call
all
of
the
import
meta
hooks
for
all
of
the
modules
in
the
working
set
that
uttered
import
meta
before
any
of
them
have
an
opportunity
to
execute,
in
which
case,
in
which
case
a
a
a
dependency
would
have
an
opportunity
to
follow
the
module
record
for
things
that
depend
upon
it,
which
I
think
is
disqualifying.
So,
let's
drop
option
d
entirely.
B
A
Yeah,
this
is
a
requirement.
That's
coming
from
our
friends
who
work
on
node.js
and
node.js.
They
introduced
import
meta
resolve
as
a
property
that
they
embellish
their
import.
Meta
with
and
import
meta
resolve
by
necessity,
is
a
closure
because
it
has
to
close
close
over
the
refer
url
in
order
to
do
its
job
and
because
creating
that
closure
is
expensive.
It's
a
huge
overhead
for
large
module
graphs
that
mostly
do
not
take
advantage
of
that
feature.
Okay,.
A
D
B
A
The
same
way
would
be
to
say
that
it
that
option
a
is
an
optimization
of
another
behavior,
essentially
equivalent
to
option
c
right
that
that
the
only
way
to
make
it
to
phrase
this
to
the
standard
such
that
it
is
an
optimization
that
does
not
need
to
be
implemented
by
every
host
would
be
to
say
that
hosts
have
the
option
of
implementing
options
c
or
a
oh.
I.
A
B
Okay,
you
load
a
module
and
if
we,
if
we
choose
option
b,
it
means
that
the
import
meta
hook
is
called
it's
synchronous
and
it's
called
before
the
execution
of
the
module.
Yes,
okay,
so
the
question
is:
can
us
always
call
the
import
method,
or
does
the
us
ask
to
check
if
the
module
mention
import
meta.
D
I
would
I
would
recommend
I
I
would
strongly
recommend
that
it's,
if
that
we
specify
if
the
module
mentions
import
meta
because
the
to
to
leave
it
at
you
know
to
to
leave
this
as
a
choice.
It's
an
observable
choice.
It's
not
it's
not
a
unobservable
optimization,
and
that
makes
the
platform
more
non-deterministic
if
there
was
a
strong
reason
for
it.
I
mean
if
this
is
an
important
optimization
to
enable
this
to
be
a
choice.
D
B
You
you
remember
that
I
mean
some
of
the
modules
we
are
importing
in
access
are
already
compiled,
okay,
so
detecting
if
input-
and
we
don't
have
the
source
so
in
time,
so
in
detecting.
If
import
meta
is
mentioned,
it's
of
course
possible,
but
hater
requires
to
flag
the
the
module
which
is
not
currently
planned
or
to
go
through
the
bike
code
to
check
if
import
meta
is
mentioned
somewhere
in
the
background.
B
B
A
B
C
So
this
could
bring
us
back
to
putting
hints
about
meta
being
there
on
the
static
module
record
and
even
the
compiled
modules
would
then
have
those
hints
available.
So
we
put
it
in
that
stage
of
the
process
and
your
compilation
produces
the
the
white
code
and
the
meta
information
about
it
being
uttered
or
not.
A
C
C
B
Yes,
something
like
that,
but
yes,
the
the
I
have
to.
I
have
to
check
how
complicated
it
is
to
flag
modules
that
they
mentioned
in
port
meta,
because
if
it
is
not
complicated,
then
option
b
is
way
way
simpler.
Like
I
mean
I
can
call
the
import
method
synchronously
before
the
execution
of
the
module,
and
that's
that's
simple
enough.
C
I
don't
know
much
about
how
access
goes
through
contents
of
modules,
but
in
in
endo
it's
part
of
an
existing
step.
It
was
just
a
matter
of
taking
a
note
of
detecting
import
meta
in
a
pass
that
was
already
happening
over
the
source
code,
so
it's
possible
that,
for
the
sake
of
replacing
all
imports
with
something
else
or
for
the
sake
of
transforms
in
cess
or
the
compartment
that
detect
stuff
like
imports
or
html
comments,
you're
already
making
that
pass
over
the
source
code.
B
You
know
for
sure
I
mean
compiles
everything
into
bytecode
and
it
detects
import
meta
it
just
just
that
that
flag
is
not.
Currently,
I
mean
there's
no
flag
for
that.
It
just
generates
the
white
bicone,
but
okay,
I
will.
I
will
investigate
that.
But
if
we,
if
we
agree
on
the
synchronous
execution
of
the
input
meter
hook,
then
I
can.
I
can
do
the
work
on
that.
I
was
afraid
of
the
extra
steps,
but
but
more
than
about
detecting
the
import,
meta
presence.
C
A
C
A
A
Yes,
there
are
more
topics:
okay,
okay,
but
it's,
but
I'm
really
grateful
that
we've
come
to
what
appears
to
be
a
decision
on
option
b
and
we'll
we'll
we'll
go
co-implement
that
and
see
how
it
works
same
for
me.
I
will
tell
you
yeah
the
I'd
like
in
future
meetings
to
talk
about
the
shape
of
the
module
descriptor.
A
A
A
We
could
probably
simplify
it
to
simply
being
that
all
of
those
have
a
module,
descriptor
object
that
can
and
we
switch
on
its
shape,
which
means
that
there's
a
possibility
of
having
a
shape.
That's
dedicated
to
threading
a
module
namespace
object
without
a
power,
a
module,
namespace
object
that
carries
powers
in
that
position,
and-
and
we
we
can
have
a
conversation
about
that-
perhaps
next
week
or
in
a
subsequent
week,
depending
on
the
availability
of
the
people
who
need
to
participate
and
I'll
take
care
of
that
out
of
band.
B
That
would
be
great.
I
I
think
it's
a
it's
a
very
important
thing
to
agree
on,
because
it
it
really.
It
really
helps
both
implementation
and
the
usage
I
add
of
combatment
to
if
that
descriptor
thing
being,
I
mean,
switch
based
on
this
shape
and
not
having
like
multiple
dives
and
so
on,
and
I
think
I
think
it
makes
sense.
A
Yeah,
which
means
that
we
could
have
an
orthogonal
conversation
about
whether
the
static
module
record
constructor
continues
to
be
useful.
I
think
it
does,
but
for
purposes
of
static
analysis
and
not
for
the
purposes
of
linkage.
It
looks
like
we
have
a
different
solution
to
that
problem:
that's
simpler
and
probably
easier
to
get
through
standards.