►
From YouTube: SES-mtg: cjs vs resm vs esm
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
C
Excellent,
thank
you.
The
I'm
trying
to
come
up
I'm
trying
to
create
a
release
of
s.
Yes,
that
is
usable
for
common
Jay
s,
ESM
with
the
native
support,
node,
and
also
the
r
es
m
in
node,
which
is
apparently
a
subtly
different
dialect.
I
got
around
I
got
around
the
worst
of
the
problems
on
the
the
difference
in
the
dialect
is.
Is
this
there's
this
distinction
between
import
star,
as
name
and
just
import
name
and
resume?
C
D
This
is
the
only
overlap
of
all
those
systems
state
the
overlap
again,
if
you
generate
a
common
test
module
for
your
package,
whatever
it
is
generally
importable
everywhere,
except
through
native
browsers
support.
But
if
you
use
a
bundler
for
a
browser,
it
is
supported
mm-hmm,
because
bundlers
can
kind
of
fiddle
with
stuff.
D
From
there
you
have
now
generated
a
common
test,
build
these
different
things
will
create
a
ESM
facade
around
the
common
J's
build,
and
as
long
as
there
does
not
exist,
a
underscore
underscore
es
capital,
iam
module
filled
with
a
truthy
value.
They
will
generate
a
default
named
export.
For
that
facade.
They
may
generate
more
things
than
that
when
you
say
well,.
E
We
decide
that
our
translation
of
modules
to
become
secure
modules
within
the
locker
service.
We
decided
we're
not
going
to
do
any
special
formatting
we're
only
going
to
compile
from
ESM
to
ESM
and
let
other
tools
that
exist
today
that
are
pretty
good
at
producing
different
outputs
for
that
module.
Do
the
the
other
work
so
I
wonder
why
you
have
a
tool
that
produced
multiple
outputs?
If
that's,
what
I
understanding
that
you're
doing
yeah
the.
D
E
D
E
Feel
that
that
might
not
be
I
mean
for
for
us.
Certainly
it's
just
that
the
system
that
we're
creating
is
to
compile
es
is
more
chose
not
to
compile
common
des
or
any
anything
else.
It's
just
for.
Yes,
yes,
module
itself,
and
our
assumption
is
that
if
we
go
get
the
SM
transpiler
into
another
ESM,
that
does
the
secure
aspect
of
it,
but
preserve
the
shape
of
the
things
that
you
import.
The
thing
that
you
export
or
the
shape
of
it
and
then
let
order
tools
to
do
the
work.
E
Obviously,
to
get
to
that
point
to
use
that
translation,
you
have
to
remove
the
type
of
script
annotations
that
becomes
a
yes
module
anyways
and
then
you
transpire
into
another
es
module,
and
then
you
transfer
that
into
whatever
you
system
needs
which
is
community
s
or
or
yes,
M
or
bundle
all
together
in
one
thing
or
a
year,
if
he
or
what
what
whatever
you
want
and
that
works
pretty
well
for
us.
E
C
E
E
It
depends
like,
in
our
case,
most
of
the
time
we
use
a
rollup
configuration
in
the
app,
and
so
we
compile
the
code
from
ESM
to
ASM,
with
the
security
guarantees
that
we
are
into
that
new
module,
and
then
we
fit
that
into
the
pipeline,
and
the
pipeline
will
get
bundle
everything
together
if
there
is
a
dependency
that
I'm
importing
that
happens
to
be
a
common.
Yes,
the
role
of
would
do
the
dance
of
belong
to
the
package.
Is
it
really
a
thing
that
was
compiled
a
has
they?
E
What
I
would
probably
was
saying
in
the
capital
was
the
name,
the
yes
module
tag,
it
does
all
the
dance
for
that
and
then
it
at
the
end
of
the
day,
these
down
down
the
road
tools
will
take
care
of
that
part
of
the
conversation
we
just
don't
care.
We
only
focus
on
getting
the
module
and
producing
the
module.
That
is
secure.
A
A
So
the
two
sets
of
constraints
together
mean
you
have
to
fix
all
of
the
codes
simultaneously
anatomically
in
order
to
get
to
a
new
working
state
and
do
does
anybody
here
and
particularly
the
people
work
with
Brian
on
that
Michael
or
chip
or
Calbert
understand
what
those
constraints
are
and
why
we
ran
into
difficulties
there.
Oh.
C
C
There
are
a
great
number
of
import
forms
above
and
below
that
that
any
of
your
third-party
modules
might
be
using
on
any
of
our
in
any
of
our
own
modules
that
might
be
using,
but
which
is
probably
where
that
is
was
it,
which
is
probably
why
Brian
ran
into
that
problem,
but
I
will
listen
to
chip
and
Mike
Michael.
At
this
point,
I
mean
I,
don't
know.
G
Yeah
there
were
a
couple
of
things:
the
one
well
I
started
going
down
this
road
and
then
I
just
okay.
This
is
not
on
my
critical
path
and
head
it
off
to
Brian,
but
there's
this
on
some
piddly
stuff
like
when
you
do
an
import,
whether
you
have
to
have
the
dot
J
S
on
the
end
of
the
name
of
the
thing
you're
importing,
Bruce's
you're
not
allowed
to
have
the
dot
JSON
the
end
of
the
thing
you're
importing,
but
the
main
issue,
as
I
recall,
was
that
you
just
couldn't.
G
Uses
ESM,
that's
fine,
but
if
it's
coated
in
ESM
syntax,
but
it's
being
actually
realized
using
resin,
then
you
cannot.
If
it
is
coded
using
requiring
a
CGS,
you
can
you
can
you
can
import
it,
but
but
then
you
can't
use
resin
with
it,
and
so
we
have
to
either.
Basically,
you
have
to
either
go
all
in
for
for
ESM
or
go
all
in
for
resum
or
go
all
in
for
CGS
and
it
just
in
a
single
repo.
G
It's
it's
kind
of
an
all-or-nothing
kind
of
deal,
and
that
makes
it
a
sort
of
not
exactly
a
boil
the
ocean
problem,
but
it
makes
it
a
something
where
you
have
to
do
a
large
global
change.
Rather
than
simply
you
know,
I
will
I'll
fix
this
module
and
then
I'll
fix
this
module
and
then
I'll
fix
this
module.
Yeah.
G
C
B
C
Okay,
I
think
that
I
can
close
this
topic
out
then
for
now
perhaps
I'll
follow
up
with
the
ESM
project
to
see
where
they
are
on
that
feature.
This
may
be.
This
may
not
be
an
existential
problem
for
a
migration
and
might
be
that
we
can
do
an
es
em
to
our
resin
DSM
migration.
At
some
point,
I
still
don't
know
about
I.
C
D
There's
one
thing
you
probably
also
want.
We
have
unflagged
and
removed
all
the
warnings
for
what
are
called
conditional
export.
So
you
can
ship
both
builds
tooling.
For
that
isn't
great,
but
I
mean
a
lot
of
the
stuff
that
nodes
done
has
been
over
years
and
tooling
adopted
their
own
solutions.
In
the
meantime,
they
don't
overlap.
What.
D
D
Node
sets
essentially
a
bunch
of
boolean
flags.
It's
roughly
making
a
state
machine
where,
in
your
package,
you
can
define
what
paths
get
resolved
to
specifiers
within
a
package,
so
it's
kind
of
the
corollary
to
an
import
map.
So
if
you
import
something,
for
example,
the
import
condition
becomes
active.
D
If
you
require
something
the
require
condition
becomes
active
and
then
in
your
listed
mappings
in
your
package
JSON,
it
will
go
and
resolve
against
those
specifiers.
So
if
I
import,
let's
say
ses,
slash,
internals
and
it's
not
in
the
mapping,
it
will
fail
or
if
I
were
to
import
ses,
slash
common
jeaious.
It
could
see
in
earth
just
SES
if
I
import,
just
SES,
you
can
inside
your
package,
JSON
have
the
route
for
import
map
to
es
mas
or
MJS,
and
you
could
have
the
route
for
require
a
map
to
common
JSC,
jsr
jeaious.
D
C
F
Assuming
that
the
synchronous
import
is
successful,
the
when
the
asynchronous
import
completes
when
it
resolves,
which
may
be
around
the
same
time,
if,
depending
on
the
implementation
of
the
host
the
because
of
the
way
that
it
specified
whatever
it
results
to,
will
not
actually
be
used,
it
will
use
the
synchronous
import,
the
memorized
version.
That's
my
understanding
from
the
specification
open.
A
F
A
As
the
answer
it
becomes.
The
answer
that's
used
for
the
asynchronous
question
and
it
gets
memorized
so
that,
after
that
happens,
it's
also
used
to
answer
synchronous
questions,
but
basically
the
the
the
thing
that
resolved
that
you
serve
resolves.
That
drama
for
me
is
that
the
synchronous
lat,
the
synchronous
absence
of
an
answer
is
itself
memorized,
so
that
the
so
that,
if
the
that
says
no
synchronous
answer
from
the
hook
that
that
the
synchronous
hook
is
never
asked
that
question
again.
C
C
My
notion
is
that
every
synchronous,
import,
monotonically
advances
the
set
of
instantiated
modules
right
and
because
it's
synchronous
that
this
is
guaranteed
to
occur
in
a
single
event
right.
So
every
time
you
call
import
now
or
whatever
it's
called,
or
even
if
it's
not
even
exposed
in
the
public
API,
there's
the
possibility
of
instantiating
more
module,
namespaces,
which
you
will
only
do
months
once
for
each
for
each
module
identifier.
C
B
A
C
A
C
C
F
A
The
hope
from
the
right,
ok
so
right,
if
the,
if
in
the
the
in
order
to
be
able
to
answer
some
questions,
cyclists,
I'm
I'm,
assuming
that
there's
an
exposed,
synchronous,
API,
which
is
itself
controversial,
but
assuming
that
then
for
the
synchronous,
one,
the
relevant
hook,
would
be
the
synchronous
hook
and
the
relevant
memo
entries
will
be
the
entries
that
go
directly
to
a
module
static
record,
not
to
a
promise.
That's.
F
What
do
we
expect
the
behavior
to
be
in
the
case
where
module
is
not
available?
Synchronously
if
you
perform
or
in
this
hypothetical
design
of
the
API?
If
you
perform
an
asynchronous
import
and
it
triggers
the
synchronous
hook,
which
then
fails
well,
that
does
not
find
a
module
and
then
the
asynchronous
hook
is
fired
and
we
have
a
promise,
that's
painting,
and
then
before
that
promise
is
resolved.
We
have
the
code
not
perform
another
synchronous
import.
What
what
is
the?
A
D
Observability
of
the
state
of
a
promise
has
been
regarded
as
something
that
we
wish
to
protect
and
prevent
synchronous
access
to.
In
particular,
if
you
do
an
asynchronous
import
and
you
attach
handlers,
they
should
be
executed
before
anything
else
is
able
to
access
that
value.
There's
been
discussed
a
few
times
as
being
quite
important.
D
The
ability
to
attach
a
function
that
has
right
of
first
access
to
a
value
so
I
I'm,
going
to
say
it
would
be
impossible
to
get
a
semantics
where
it
doesn't
fail,
because
the
if
the
synchronous
import
is
going
to
expose
some
state
by
nature
of
reifying
the
value
before
the
promise
handlers
are
able
to
have
right
of
first
access.
Okay,.
A
F
That
makes
sense.
What
is
the
does?
Anyone
know
when
this
interacts
with
what,
with
when
imports
interact
with
top-level
await
what
they
expected
semantics
of
a
a
static
import
of
a
module
that
essentially
the
exports
of
that
module
are
not
known
until
where
are
they
top-level
await?
No,
you
know
the
module
static
records
synchronously
with
top-level
away.
It's
as
a
dread,
yeah.
D
D
Change
it
to
so
there's
an
old
document
that
has
been
brought
up
a
few
times
on
host
implementations
called
the
ASAP
evaluation
versus
out
of
order
evaluation.
Optimizations
I
can
probably
dig
up
links
to
it.
It's
from
chrome.
Essentially,
the
idea
is
the
way
that
yes,
modules
are
specified.
Currently
they
can
never
be
faster
than
a
bundler
because
they
cannot
execute
chunks
as
they
come
in.
They
must
wait
for
the
entire
graph
to
come
in.
There
are
a
few
different
ways
you
could
try
to
work
around
this
by
changing
the
act.
D
My
scripts
specification
I'll
put
this
in
the
chat,
so
there's
a
doc,
but
it
is
proven
not
compatible
with
polyfills
in
particular,
so
they
are
they're
still
working
on
this.
It's
been
years
trying
to
find
a
way
to
get
this
to
work,
but
they
do
want
it
to
change.
There's
just
no
semantics
that
are
remotely
compatible
with
use
cases.
So.
D
D
Let's
go
with
unless
you
do
something
weird:
it's
okay!
There
is
a
lot
of
time
spent
on
this
first
tick,
whatever
you
want
to
call
it
the
first
time
your
module
begins,
will
always
be
the
first
time
of
any
of
its
siblings
have
begun
and
they
will
execute
in
a
pre
in
order
traversal,
yes,
correct,
as
they
exist
in
source
text.
So
essentially
the
expected
order.
C
D
C
C
Which
is
not
a
problem
for
the
import
function
right
because
then
it's
just
your
execution
phase
is
going
to
be
spread
over
multiple
turns
and
that
promise
will
resolve
or
full
will
settle
after
your
entire
transitive
import
graph
is
as
executed.
That's
fine.
Does
this
mean
that
import
statements
are
implicitly
possibly
asynchronous,
that
is
to
say
that
they
implicitly
like
the
import?
The
import
statement
is
effectively
an
awake
implied
underneath
it,
because
any
other
items
might
await.
C
D
Strictly
tracked,
so
there
there
was
a
need
to
be
able
to
statically
verify.
If
your
graph
does
cause
a
synchrony
mm-hmm.
Oh,
you
can
actually
check
a
field
and
engines
really
really
needed
to
expose
that
field
to
hosts.
So
you
can
basically
check
if
your
graph
is
able
to
evaluate
synchronously
I,
see.
F
B
F
A
A
Michael
thing:
the
translation
that
that
you
and
I
worked
on
from
the
script
modules
into
the
well.
You
know
the
the
representation
we're
using
for
the
Shum
no
I
know.
I
know
that
when
we're
working
together,
I
just
completely
blew
off
top
level
away,
I
just
said:
I
can't
think
about
that
at
the
same
time
and
I
ignored
it.
Do
you
have
thought
and
I
don't
have
any
thoughts
now
about
how
to
upgrade
that
to
deal
with
top
level
away?
Do
you
have
thoughts
on
yeah
so.
B
After
knocking
a
little
bit
with
Saleh
about
this
and
the
experiment
that
he
did
for
top
level
away,
basically
said
the
top
level.
Functor
is
a
nascent
generator
and
then
you
use
yield
in
certain
places
at
the
top
level
and
like
that,
gives
you
enough
flexibility
to
be
able
to
import
implement
what
top
level
weight
is
like.
But
if
you
just
made
it
a
regular
async
function,
then
subs
tooting,
if
you
left
the
away
cause
intact
and
you
don't
get
the
right
semantics.
Okay,.
B
A
C
B
A
There
was
when,
as
we're
talking
about
semantics
top-level
awake,
one
of
the
proposals
was
that
it's
basically
syntactic
sugar
for
turning
your
your
module
as
a
whole
into
an
async
function.
The
weights
just
being
awaits
inside
the
function
and
that
semantics
was
rejected
and
the
semantics
that
was
adopted
was
ones
that
cannot
be
translated
into
that
which.
A
B
So
covered
I
think
that
the
idea
would
be
if
we
made
our
top
level
functor
and
a
generator,
then
that
would
give
us
the
flexibility
in
the
future.
Translating
the
awake
calls
into
yields
by
guys,
we
can
talk
about
that
offline,
we'll
bring
it
up
in
an
issue.
What.
C
D
A
F
And
if
I
could
go
back
to
the
compartment
hubs
for
a
moment,
I
was
proposing
another
possible
solution
and
I'm
jumping
into
this
a
little
bit
blind.
So
this
may
not
make.
This
may
not
be
a
good
idea,
but
the
idea
was
to
combine
the
new
synchronous
and
synchronous
hooks
and
just
say
that
the
hook
can
return
either
a
promise
or
or
immediate
module
static
record,
depending
on
the
availability
of
that
resource
and
I.
Don't
think
that's
incompatible
with
me
with
the
with
the
behaviors
that
we've
described
so
far
with
two
hooks.
F
F
C
C
A
C
A
A
Frizzle
all
requests
check
the
memo
first,
but
if
the
memo
misses
then
the
import
now
Qwest
only
goes
to
the
import
now
hook,
because
you
know
whatever.
Whatever
it's
answer
is
that's
the
only
answer
you
can
give
now
mm-hmm,
but
that
the
import
request
would
first
check
the
memo.
If
that
misses
then
check
the
synchronous
hook
and
then
only
if
that
misses
go
to
the
asynchronous
hook
and
as
I'm
talking
us
through
I
think
what
Michael
hunter
just
proposed
gives
us
all
the
flexibility
and
and
expressiveness
of
the
semantics,
always
Clinton
in
terms
of
which.
A
A
There's
one
difference
in
external
behavior
that
I
can
see
and
I
don't
know
which
way
it
argues,
which
is,
since
the
hook
can't
tell
whether
a
synchronous
or
asynchronous
request
was
made
in
Michael
hunters
proposal,
even
if
a
synchronous
request
was
made
the
asynchronous
activity
to
eventually
yes,.
C
A
F
Okay,
so
that
that
kind
of
resolves
that
that
question
about
the
the
separation
of
the
hooks
and
I
had
one
other
question
that
came
up
with
me
on
the
discretion
on
this
issue
on
the
on
262
github
repository,
which
is
just
goes
a
bit
tangentially
related
to
the
issue
I
raised.
But
it's
a
question
of
where
these
module
static
records
actually
come
from,
so
we've
been
implementing
a
hook.
What
is
a,
what
does
the
module
static,
correct
would
look
like,
and
how
does
the
implementation
get
that
right.
A
There
needs
to
be
an
additional,
primitive
somewhere
and
we
haven't
really
talked
yet
about
what
the
primitive
looks
like
or
what
it's
attached
to,
but
basically
something
that
takes
in
module
source
text
and
produces
a
module,
static
record
and
because
migrants,
static
records
are
self-contained
that
doesn't
do
any
import
walking
or
you
know
it's
good.
It's
a
completely
isolated
analysis
doesn't
involve
any
I/o
and
and
then
the
module
static
record
then
becomes
the
data
type
that's
feeding
into
this
other
stuff.
A
But
that's
that
there
needs
to
be
such
a
primitive
to
from
first
text
to
this
module
static
record
and
in
one
of
cádiz
api's.
He
had
something
he
had
a
data
type
called
cursed,
module
and
I
think
that
the
role
of
the
first
module
data
type
in
Purdue's
api's
and
the
role
of
what
I'm
calling
a
module
static
record
is
the
same.
A
Contains
too
much
information
in
that
it
also
contains
the
source
text,
so,
in
particular,
in
a
you
know,
in
an
embedded
context
where
you
just
want
to
during
development,
pre-compile
things
and
static
records
and
then
throw
away
the
source
text.
You
don't
want
to
imply
that
the
source
text
is
available
at
runtime.
F
A
A
Maybe
the
let
me
start
with
that
story,
because
then
it's
a
simpler
story
if
it
works
out
and
if
it
doesn't
work
out
to
find
out
so
we've
already
talked
about
these
import
hooks.
So
the
import
hooks
have
to
provide
a
module
static
record
on
demand,
but
how
they
provided
is
up
to
the
import
hook.
So
the
compartment
hook
can
cause
the
import
hook
to
load
and
to
load
source
text
and
person
and
produce
a
module
static
record
and
in
order
to
take
source
text
and
produce
a
module
static
record
from
it.
A
F
A
F
A
F
A
A
A
A
C
A
Oh,
the
the
the
web
browser
context,
I
think
actually
helps
answer
this,
which
is
the
code
that
starts
running,
is
running
in
a
start
compartment
and
the
start
compartment
is
set
up
according
to
the
host,
so
the
start
compartment
might
have
in
its
global
global
variables
that
hold
on
to
host
objects
like
document
or
file
system
now,
and
it
also
has
a
import
environment.
So
the
start
compartment
is
already
a
working
compartment
that
was
somehow
provided
by
the
host,
and
that
would
happen
in
the
browser
with
the
realm
API.
C
A
F
For
example,
to
provide
as
some
kind
of
membrane
interface
between
the
the
compartments,
the
the
code
running
in
the
compartment
and
some
other
module
and
I
membrane,
maybe
implements
of
the
proxies
or
something
like
that,
then
I
wouldn't
am
I
correct
that
you
wouldn't
be
using
the
import
hooks
at
all.
In
that
case,
you
would
be
using
the
module
map
that
provides
module
instances
and,
in
other
words,
I,
don't
wanna,
okay,
okay,
okay,
that's
good!
Then
my
understanding
is
clear.
Yeah.
F
B
C
That
I
think
that
having
an
import
now
is
going
to
be
regrettable,
especially
because
of
the
top
level
of
weight,
and
my
reasoning
for
that
is
that
there
it
introduced
in
port
now
introduces
a
hazard.
We're
working
code
can
be
transformed
into
not
working
code
when
any
transitive
dependency
introduces
a
top
level
of
weight.
A.
C
C
A
A
A
F
I,
my
understanding
from
my
limits
of
knowledge
on
top
level
wait
is
that
that's
not
the
case
that
an
import,
if
you
have
a
module,
it
has
no
awaits
in
it
and
it
imports
a
module
which
does
have
a
weights
in
it.
There's
an
implicit
points
in
which
the
the
importing
module
is
awaiting
the
completion
of
execution
of
the
imported
module,
and
my
knowledge
is
not
strong
on
it.
So,
yes,
so.
A
C
There
are
two
possibilities
over
the
semantics
of
top-level
ro8
are
for
module
authors.
On
the
one
hand,
it
could
be
that
you
are
required
to
satisfy
your
public
API
before
your
first
await,
in
which
case
it
would
be
safe
for
and
that's
not
the
case,
and
that
is
not
the
case
yeah,
which
means
that
which
means
that
that
we
do
need
to
stinker
is
always
possibly
awaited
implicitly.
C
A
B
B
Module
food
imports
a
and
B
and
C,
then
top-level
await,
says
if
a
B
and
C
are
all
using
top-level,
oh
wait,
then
they
get
evaluated
in
their
first
tick,
all
the
siblings
do
and
then
they
proceed
to
evaluate,
and
only
after
they're
done.
All
their
top-level
awaits
is
their
module,
namespace
accessible,
in
which
case
it
can
be
used
for
module
food.
As.
A
C
B
B
A
Clearly,
we
all
need
to
go
off
and
understand
this
document,
but
having
the
start,
module
not
begin
execution
until
it
can
run
to
completion
is
consistent
with
the
with
the
constraint
that
I
am
but
I.
Think
I
understand,
which
is
the
only
textual,
awaits,
are
interrelated
points.
It
says
that
that
you
know
all
in.