►
From YouTube: Node.js Foundation Modules Team Meeting - June 6 2018
Description
B
C
A
So
we
have
several
items
here:
I
kind
of
want
to
get
through
the
quicker
ones
or
the
the
ones
that
were
marked
for
mentioned,
but
I
don't
know
if
there's
necessarily
time
to
discuss,
because
I
think
that
some
of
this
stuff
could
be
better
done
in
the
time
between
meetings.
So
one
of
the
first
ones
I'd
like
to
look
at
is
developer
survey
number
85
there
is
may
have
been
mentioned.
B
A
Okay,
right
now
it
looks
like
there
there
hasn't
been
any
real
real
activity
on
that
thread,
so
I
would
encourage
you
to
participate.
If,
if
you
have
questions
that
you
want
to
see
like
what
what
users
think
of
XYZ
and
so
feel
free
to
pop
in
there
and
and
start
discussing
that
all
right,
the
next
one.
A
A
Let's
see
I
think
we
might
have
one
of
the
speakers
here.
We
have
anyone
raising
their
hands,
nope,
okay,
well,
I
would
say,
go
and
if
you
want
to
help
on
that
effort,
they
are.
There
is
a
lot
of
activity
on
that.
At
least.
There
was
seven
days
ago
and
there's
another
draft
thread
being
produced
in
a
document
so
that
work
is
ongoing
to
I.
Don't
know
if
there's
anything
really
to
discuss
there.
It
says
an
agenda
item,
but
that
was
14
days
ago.
A
A
A
Issued
209,
51
I
think
this
might
just
be
from
visibility.
I
don't
know
if
we
actually
have
to
vote
on
this
one,
because
it's
the
existing
thing.
We
we
have
a
rule
where
we
were
not
adding
new
features,
but
this
is
like
a
debug
enhancement,
so
I'm
not
quite
sure
how
deep
this
goes,
but
I
would
say
if
you're
not
familiar
with
it,
please
pop
in
and
give
your
opinions
on
the
thread.
A
If
you
think
this
is
something
that
we
should
do
and
not
if
you
think
this,
the
sniff
were
inference
for
it
needs
to
be
tweaked.
Please
plop
in
I've
reviewed
it
I'm
I'm
for
the
change
I
I
was
I
was
hoping
it
would
have
made
more
progress
in
the
tc39,
and
so
when,
when
it
didn't
the
tooling
is
the
natural
fit
for
the
the
natural
fall
back
for
it,
so
either
in
browsers
or
in
node.
It's
a
good
way
to
let
people
know
that
there's
there's
something
that
they
they
could
be
stumbling
on.
A
If
you're
not
familiar
with
the
issue,
is
that
if
you
have
a
dynamic
import
and
the
namespace
that
you
are
importing
has
a
binding
for
then
a
dynamic
import
will
defer
to
the
and
pass
through
and
lots
of
times.
If
you,
if
that
then
wasn't
intended
to
be
a
promise
resolved,
it
could
just
be
a
silent
execution,
and
so
that's
probably
not
what
you
want,
and
so
that's
why
this
pull
request
would
shoot
off
a
warning
and
let
you
know
that
you
have
potentially
done
something
you
did
not
want
to
do
so.
B
E
Yeah
so
some
added
context
to
this
I
made
a
PR
tes
Lent
last
year.
They
didn't
see
this
behavior
as
problematic
and
tc39
also
doesn't
see
the
behaviors
problematic.
So
if
you
have
use
cases
or
counter
examples
for
why
dynamic,
import
and
export
function
then
should
work
without
warnings.
Please
post
those
in
the
issue,
don't
feel
that
do
you
have
to
succumb
to
people,
thinking
that
it's
odd
behavior,
if
you
have
valid
use
cases,
please
list
them.
So
we
can
discuss
yeah.
A
F
Yeah
I,
just
if
you
follow
the
the
discussion
on
on
the
Reaper,
there
was
a
bit
of
back
and
around
some
of
these
things
and
there
was
a
revision
halfway
through
that.
It's
will
own
one.
If
the
in
function
has
no
arguments
and
I
believe
that's
what's
implemented
at
the
moment
in
the
PR,
so
I
write
an
function
which
attempted
to
resolve
and
it's
kind
of
trying
to
avoid
that
hosing,
baby
I
think.
But
there's
a
lot
of
discussion
around.
A
E
H
I'm
not
sure
what
happened.
Sorry
about
that,
so
yeah,
basically
just
I
appreciate
that
this,
the
narrowing
down
it
I
think
avoids
the
warning
in
all
the
legitimate
use
cases,
the
only
edge
cases
that
are
left,
which
we
may
decide
we're.
Okay
with
our
rest
arguments
or
the
arguments
key
word.
So
there
are
still
ways
that
someone
could
use
a
then
export
function
and
not
declare
any
required
arguments,
but
still
accept
one
and
resolve
appropriately.
H
Also,
true,
that's
right,
so
any
defaulted
or
rest
or
implicit
through
the
argument.
Keyword
arguments
would
be
the
edge
cases
and
we
can
decide
if
that's
okay,
maybe
it
is
because
it
is
kind
of
weird
to
do
and
then
function
anyway,
and
the
simple
solution
would
be
just
make
a
required
argument
and
you
won't
get.
You
know,
cause
the
warning
to
happen.
I
just
wanted
to
call
that
out.
So.
A
I
A
I
H
And
Gus
wrote
up
a
proposal
that
I've
presented
at
tc39
last
month.
The
into
the
hope
was
to
have
a
symbol,
dot,
Venable
or
symbol,
dot,
unbendable
or
something
basically,
a
kind
of
non
magic
way
to
exempt
module,
name,
space
records
from
ever
being
considered
Venable,
and
the
committee
reaction
was
a
combination
of
acknowledging
the
web
reality
that
people
are
already
having
Venable
modules
and
then
also
acknowledging
that
there
are
some
legitimate
use
cases
for
them,
and
you
know
the
it
kind
of
seems
like
it
that
we
might
have
banned
the
name.
H
J
H
H
Well,
so
that's
that's
kind
of
the
other
question
about
this.
The
warning
is
late,
but
the
so
the
valid
use.
Cases,
though,
are
are
largely
like.
If
you
want
your,
if
you
want
to
export
a
promise
from
your
synchronous
module,
you
know
the
from
the
regular
import
of
your
module,
but
you
don't
want
to
have
to
do
that
from
the
asynchronous
one
or
it's
if
you
like.
H
One
of
the
common
patterns
with
import
paren
is
that
you
then
have
to
do
dot,
then
X
or
X
dot
default,
because
you
want
to
kind
of
abstract
over
the
babble
Interop
that
sometimes
leaks
out
through
packages.
You
could
make
a
vent
on
your
module.
That
would
do
that
for
you
or
for
the
consumer.
It's
like
that's
one
possible
use
case
right.
I
H
And
the
current
state
of
the
the
warning,
which
is
only
worn
when
the
then
function,
has
a
dot
length
of
zero
that
addresses
all
like
that,
exempts
all
the
valid
use
cases
from
warning,
except
for
the
edge
case
as
I
mentioned
earlier,
which
is
rest,
arguments
default
arguments
or
someone
who
uses
the
arguments.
You
know
arguments
bracket
zero,
but.
I
H
G
A
A
So
it
sounds
like
there
is
still
some
clarification.
Oh
also
join.
The
call
to
Benjamin
did
great
sounds
like
there
may
need
to
be
some
clarification.
Can
we
promote
bin
Benjamin
yep?
Let
me
do
that
done.
Are
you
all
want
real
comfortable
on
voting,
not
the
living
but
agreeing
to
this
today,
or
would
you
like
more
time
to
review
I
I.
F
Yeah,
just
to
maybe
clarify
a
little
bit,
I
think
the
behavior
that
Gus
was
trying
to
warn
about
here
was
the
fact
that
node
would
just
hang
and
then
quit
or
that
he
didn't
like
the
way
that
it
was
exiting
process
or
hanging
up
on
that
promise.
So
just
to
make
sure
if
there's
some
kind
of
warning
about
how
that
completion
came
to
be.
A
A
H
It
occurs
to
me
actually
after
I
just
heard
that
explanation
that
I
remembered
a
thought
I'd
had
about
this
warning.
Is
that
the
behavior
of
note
just
hanging
when
you
do
import
parens?
That's
what
already
happens
if
you
have
an
ever
resolving
promise
like
things
just
hang
there
so
like
I
kind
of
also
do
feel
like.
Maybe
if
we're
going
to
warn
on
forever
pending
promises,
then
we
should
on
one
case
of
it.
H
Then
we
should
either
one
on
all
of
them
or
none
of
them
and
it
seems
kind
of
weird
to
treat
import
perennis
special
there.
Okay,
I,
might
feel
differently
if
we
had
top-level
await,
perhaps
because
that's
slightly
different
depending
on
what
blocking
semantics
it
ends
up
shipping
with,
but
the
the
general
case
of
import
paren
is
just
any
any
async
function.
Any
function
that
produces
a
promise
could
produce
one
that
never
resolves,
and
that's
just
the
way
it
works.
A
H
And
then
the
consumer
who
wants
to
handle
that
can
already
do
so
and
is
encouraged
to
by
doing
using
promise,
trace
and
racing
the
one
that
never
resolves
against
the
timeout.
You
know
like
a
set
timeout
promise
that
resolves
after
10
seconds
or
a
minute
or,
however
long
they
feel
like
waiting
like
that's
like
the
established
pattern
for
dealing
with
a
promise
that
might
never
resolve.
A
C
C
Very
on
a
constructive
example,
and
and
solved
it
based
on
spread
constructed
example.
So
I
don't
see
any
mentioning
of
a
real-world
application
where
this
happened,
and
then
this
solution
solve
the
problems
for
a
real-world
application
in
a
way
that
made
sense
for
that
application.
And
so
that's
why
the
current
solution
so
coming
back
to
what
was
just
said
about
whether
this
is
a
problem
with
the
node
is
just
hanging
because
of
a
pending
promise
like
if
we
would
have
a
real
example
of
a
real
app
where
this
is
an
issue.
C
K
Yeah
as
I
was
just
turning,
the
call
it
sounded
like
Jordan
was
explaining
such
a
use
case,
but
maybe
it
was
two
unconnected
to
like
an
actual
concrete
example
of
an
app
I.
Can
I
can
say
what
I
said
in
the
tc39
meeting
about
such
a
use
case,
which
is
just
that
it
is
like
you
know,
fairly
on
air
dynamic,
to
have
to
use
dynamic
import
and
then
then,
and
then
access
a
property
of
the
module
name.
K
Space
objects
probably
like
default
and
then
have
another
than
and
do
something
with
that
when
the
corresponding
static
import
syntax
is
just
you
know,
import
identifiers
without
curly
braces
from
module,
specifier,
so
I
don't
know
this.
This
behavior
has
been
shipped
and
like
works
in
several
browsers,
and
it
would
be
strange
to
pull
it
back,
but
I
will
grant
that
it
does
seem
like
if
we
were
going
to
warn
about
it.
K
My
other
thought
was
this
just
sort
of
feels
it's
very
truly
similar
to
unhandled
promise,
rejection
warnings,
which
is
something
that
you
know
node
was
able
to
ship
and
it
was
really
helpful
and
it
didn't
have
to
like
it
didn't
really
impact
people
negatively.
It
was
just
like
some
some
thoughtful
well
scoped
debugging
information
that
node
was
able
to
implement
unilaterally
without
violating
any
of
the
the
spec.
So
although
I
guess
there
was
definitely
some
spec
discussion
of
how
to
kind
of
support
that.
K
A
All
right,
I
am
so
based
on
the
feedback.
I
think
we
might
go
to
the
thread
and
suggest
that
if
you
need
more
generic
similar
to
the
immortal,
promise
objection
and
then
if
it
exists
at
all
and
then
that
that
way,
it's
actually
out
of
the
module
realm
and
more
into
promises
in
general
and
the
way
promises
in
general
are
handled.
If
they're
non
resolvable,
Wes.
L
So
I'm,
using
this
new
tool,
called
big
PS
query,
which
allows
you
to
just
query
type
of
search.
Pause
on
github
I
know
that
it's
not
a
you
know:
it's
not
all
JavaScript
files,
but
up
the
function,
declarations
that
are
exported
named
that
in
ES
modules,
none
of
them
see
like
we
seem
to
have
found
four
and
only
two
out
of
four.
Then
actually,
you
seem
to
hate
callbacks
as
their
first
parameters.
So
I
don't
think
this
is
a
very
common
thing.
M
A
So
this
sounds
like
we
should,
if
you
could
follow
up
on
that
thread
with
your
findings,
it
sounds
like
we're
not
going
to
be
able
to
make
a
call
today,
but
I
think
that
participation
in
the
thread
would
be
helpful,
especially
if
we
can
make
it
more
generic
or
less
apply
to
more
areas
than
just
an
import.
Let's
see,
Ben
with
your
hand
ever
released,
or
did
you
have
a
new
comment?
A
No
I
should
have
lowered
my
hand.
Sorry,
okay,
okay,
well,
I
think
we
can
move
on
from
there.
Please
feel
free
to
go
into
the
V
issue
and
provide
the
feedback
that
we've
just
done
here
and
we'll
see
if
we
can
move
that
along,
maybe
in
a
less
targeted
area
way
and
a
more
broadly
applicable
promised
way.
Okay.
So
the
next
item
is.
A
All
right,
we
have
points
of
discussion
for
transparent,
inter
up
or
non
transparent,
inter
up
or
use
cases
I
think
there's
a
couple
of
new
use
cases
that
we
might
want
to
go
through
before
we
get
to
the
the
other
discussions
so
I.
If
what
what
are
you
also
thought
saan
on
doing
that
to
the
use
cases?
A
A
A
H
H
I
kind
of
threw
these
use
cases
on
there
to
attempt
to
cover
that
you
see
where
I
can
jump
to
it.
There
we
go
yeah,
so
the
first
one
I
was
about
somebody
wants
to
initialize
shared
state,
let's
say
a
database
connection
or
a
cache
or
an
auto
incrementing,
unique
identifier,
and
that
module
is
in
CJ
s.
H
So
there
are
many
examples
of
this
in
the
ecosystem
in
people's
apps,
the
state
must
be
initialized
prior
to
all
the
other
JavaScript
code
running
like
the
database
needs
to
be
connected
or
the
you
know,
auto
incrementing
ID
needs
to
be
set
to
zero
or
whatever.
So
the
current
entry
points
all
require
this
kind
of
initializer
at
the
top
line
of
the
file,
and
they
have
the
current
guarantee,
which
is
that
that
code
will
evaluate
before
line
two
of
the
file,
and
so
they
want
to
migrate.
H
One
of
the
entry
points
to
ES
modules
which,
and
they
want
to
change
that
required
to
an
import,
and
they
also
don't
want
to.
They
don't
want
to
have
to
modify
the
other
entry
points,
so
they,
the
other
entry
points,
should
continue
to
be
able
to
using
require
in
it
and
they
don't
want
to
have
to
modify
the
init
module.
H
So
this
does
vaguely
override
with
or
overlap
with
the
transparent
Interop,
but
only
in
the
sense
that
when
you
migrate,
the
entry
point
to
ESM
you'd
have
to
migrate
that
require
to
import
because
of
the
ordering
of
import
statements,
but
the
the
general
gist
of
that
is
a
module
there.
There
should
be
a
way
to
have
a
singleton
shared
between
CJ
s
and
es
m,
and
the
initialization
order
of
that
singleton
needs
to
be
guarantee
able,
by
the
person,
writing
the
consuming
module.
H
H
H
H
So
it
it
may
be
itself,
but
that's
kind
of
irrelevant,
because
the
singleton
could
be
a
promise
for
the
database
right
like
it's
more
that
we
don't
want
to
initiate
more
than
one
database
connection.
So
some
single
module
has
to
manage
like
manage
that
and
know
that
there's
already
a
current
async
task
to
initiate
the
data
you
know,
and
you
could
do
that
by
having
it
export
a
promise.
You
could
do
that
by
having
it
keep
track
of.
When
you
call
a
function,
it
knows
if
the
database
is
ready
or
not
and
queues
it
up.
I
E
It's
not
always
a
promise
in
the
existing
ecosystem,
so
yeah
like
redundant
connections,
often
don't
export
promises.
I
set
up
a
database
connection
that
just
cubes
until
you
establish
a
good
connection
to
your
database.
It
handles
retry
logic
and
all
that
so
we're
not
talking
about
things
that
are
always
async.
Sometimes
you
get
access
to
a
real
class
instance.
E
H
H
H
A
H
A
I
H
So
I'm
gonna,
actually
even
in
the
database
example,
it
still
matters
because
you
still
want
to
start
that
asynchronous
request
immediately,
so
that
it
might
have
a
performance
impact.
So,
for
example,
even
if
you're
initiating
like,
if
you,
if
you're
the
thing
that
starts
your
node
servers,
your
node
server.
If
the
first
thing
it
does
is
tries
to
start
connecting
to
the
database,
that's
gonna
make
your
app
start
a
lot
faster
than
if
other
code
JavaScript
code
runs
before
you've
even
fired
off.
That
request,
so
I
think
even
in
the
async
case.
H
It
still
makes
sense
because,
like
in
the
same
way
as
it's
really
critical
to
be
able
to
stick
a
script
tag
at
the
top
of
your
HTML
page
and
defer
it
so
that
the
browser
kicks
off
the
network
request.
But
doesn't
you
know
block
the
rest
of
your
page
on
it?
I
think?
In
the
same
way,
the
order
is
significant,
even
if
it's
not
synchronous.
E
E
To
wander
a
bit
well,
I,
don't
I,
don't
think
that's
bad
necessarily,
but
I
just
want
to
state
that
even
with
database
connection,
if
you
have
these
asynchronous
objects,
you
may
wish
to
configure
them
synchronously
so
that
anybody,
depending
upon
you,
gets
that
configuration
down
the
line,
so
ordering
is
still
significant.
Even
if
we
have
these
asynchronous
operations,
anything
that
has
stateful
changes
that
require
some
sort
of
ordering,
such
as
configuring.
Your
database
connection
not
actually
making
the
connection
itself
still
needs
to
be
done
in
order.
C
It's
technically
Yun
yeah,
but
all
variant
work
for
me
yeah,
so
before
Bradley
spoke,
I
actually
was
going
to
propose
to
put
it
upon
her.
The
two
different
questions,
the
auto
dependence
and
the
shared
state
between
the
two
different
module
graphs
but
yeah
I-
think
that
the
the
call
to
the
database
in
it
functions
are
calling
into
this
shared
module.
Calling
an
init
function
for
the
database
connection,
because
both
because
the
init
function
needs
to
have
an
impact
on
both
module
grab
States
and
it
and
you
need
to
needed
to
happen.
C
A
Okay,
I
I
want
to
move
on
to
now
that
I
look
at
ties
this
use
case
and
we've
heard
these
case
two.
We
have
a
you,
have
a
little
less
than
twenty
minutes
left
and
we
we
have
meetings
every
two
weeks,
but
we
should
start
thinking
about
deadlines,
and
so
that
brings
us
to
the
item
of
issue
123
raised
by
Miles,
and
that
is
just
so.
We
can
start
do
roadmap
and
and
have
goals
towards
thoughts
and
dates
to
work
towards.
A
E
I
didn't
raise
my
hand
I'm
sorry,
but
my
main
concern
with
these
deadlines
is.
It
feels
like
we're
trying
to
solve
all
the
use
cases
then
we're
getting
in
before
we
ship
anything
I'm
wondering
if
we
can
take
a
more
incremental
approach
and
ship
things
unplugged.
While
we
haven't
shipped
all
the
solutions
to
all
use
cases,
because
it
seems
like
the
deadline,
stuff
I
wasn't
there
out
last
week,
I
don't
know
the
whole
context,
but
there's
a
desire
to
ship
something
on
and
I'm,
not
really
comfortable
with
those
deadline
dates.
E
If
we're
trying
to
solve
all
the
use
cases
we
have,
because
we
have
a
lot
of
them
and
we
haven't
really
even
fully
fleshed
out
all
features
and
we
haven't
associated
features
with
implementation
concerns.
We
haven't
had
time
to
fully
you
know,
with
the
implementation
out
there
in
tested
against
people,
so
shipping
and
on
flag
seems
unrealistic
at
the
scale
we're
talking
about
in
this
group.
Currently
to
me,
it.
B
G
G
D
I
agree
with
Bradley
that
I
think
the
deadlines
are
awfully
ambitious,
I
mean
I,
think
we
can
maybe
treat
them
as,
like.
You
know,
reach
goals,
perhaps
like
not
that,
like
we're
gonna
ship,
whatever
we've
got
by
this
deadline,
no
matter
how
ready
or
not
it
is
I
certainly
would
disagree
or
that
but
like
this
might
incur
to
be
like
well.
Maybe
we
need
to
meet
more
often
or
meet
longer,
or
you
know,
designate
subcommittees
for
certain
issues
or
you
know
think
about
ways
to
start
accelerating
this
process
might
be,
might
be
worthwhile
I.
B
Would
encourage
us
the
like,
if
we
think
those
dates
are
just
completely
unrealistic.
It's
probably
better
to
spend
a
little
bit
of
effort
to
you
know
refine
into
something:
that's
like
potentially
doable
just
to
set
the
proper
expectations
right
because
if
we
just
say
yeah
we'll
treat
those
as
a
reach
expectation
and
then
some
people
may
say:
well:
okay,
we're
expecting
something
to
be
ready,
then,
and
if
we,
if
we
really
think
that
that's
just
totally
unfeasible,
it's
probably
better
to
push
it
out
a
bit
and
have
something
that
you
know
might
be
reasonable.
B
G
G
A
F
Yeah
just
to
follow
up
on
that
issue.
That
was
also
tracking
neck
depth
from
use
cases,
and
you
know
focusing
on
prioritization
and
narrowing
the
focus
of
features
to
what
what
could
be
a
minimum
set
of
features
to
release
unflagged-
and
you
know,
maybe
if
we
are
able
to
work
out
which,
which
specific
use
cases
and
features
we
can
really
whittle
down
to
like
a
minimum
set
of
them.
Then
you
know.
Maybe
we
can
then
have
something
that
we
can
assess
and
more
realistically
determine
if
that
can
work
to
the
deadline.
F
But
if
we
can
cut
it
back
in
terms
of
you
know
that
there's
always
extra
features
that
can
be
added
later
that
are
backwards
compatible.
So
then,
then
it
might
be
easy
to
see
what
their
perch
looks
like
right,
like
release
all
sort
of
functionality
and
then
just
just
having
those
discussions
of
going
through
those
use
cases
and
saying
do
we
definitely
need
this
by
that
deadline
and
then
kind
of
trying
to
whittle
down
which
ones
fall
under
that
and
which
ones
don't
and
almost
being
quite
aggressively
again.
C
Do
you
call
me
okay,
what
I
was
going
to
add
was
that
I
if
I
were
correctly,
the
deadlines
that
we
have
in
this
issue
now
were
really
just
a
ballpark
brainstorm
result
of
a
five-minute
discussion
during
during
that
summit
meeting
so
I.
Don't
think
that
the
dates
themselves
are
the
important
thing,
but
I
do
believe
that,
having
dates
at
least
using
these
days
as
a
starting
point
for
working
backwards
of
tape,
if
we
would
want
to
get
it
done
by
node
11.
C
What
would
it
take
like
what
would
need
to
happen
by
when
and
if
we
go
through,
that
exercise
I
think
we
can
either
and
figure
out
if
it
is
or
isn't
realistic
or,
at
the
very
least,
come
up
with
a
expectation
that
we
can
communicate
to
the
outside
world,
because
the
last
known
thing
that
I
know
that
we
talked
about
was
that
modules
would
land
in
no
10,
and
that
is
the
last
thing
that
anybody
said
publicly.
As
far
as
I'm
aware
so
getting
to
an
understanding
and
communicating
out
a
realistic
timeline
would
be
valuable.
A
A
Noise,
okay,
yeah
dates
are
important.
It
gives
us
something
to
aim
for
it
allows
us
to,
like
you
said,
work
backwards
as
well.
I
share
Bradley's
concern
too,
so
I
think
what
what
we
should
do
is
we're
not
going
to
be
able
to
solve
this
in
five
or
ten
minutes,
but
we
should.
We
should
go
into
the
thread
and
discuss
this
to
see
if
we
can
iron
out
that
we
agree
that
dates
or
dates
are
a
good
thing.
A
Unflagging
thing
is:
there's
there's
there's
other
things
we'll
end
up
discussing
as
well,
but
that
goes
around
that
the
details
around
it
so
like,
as
Jeremiah
mentioned,
that
we
have
the
core
functionality,
import,
syntax
and
all
of
that
stuff
in
node.
It's
just
going
to
be
the
dressing
on
top
of
it
like
how
how
its
consumable,
how
its
consumed-
and
that
brings
us
to
transparent
or
not
interrupt
I-
believe
we
started
to
get
into
this
last
week
as
well.
A
There's
also
the
interoperability
with
importing
common
Jas
as
well,
which
are
both
just
both
sides
of
the
two
sides
of
the
coin.
So
we
have
a
non-transparent,
Interop
and
transparent
interrupt
if
you,
if
you
haven't
read
up
on
them,
I
encourage
you
to
do
so
this.
It
will
end
up
being
a
critical
decision
on
the
the
dressing
bits
of
the
ESM
consumption.
So
it's
it's!
It
affects
how
you
consume.
Yes,
that
works
I,
think
we
have
a
Jordan's
hands
up
yeah.
H
So
the
discussions
around
that
on
github
have
been
very
ranging,
so
I
wanted
to
kind
of
distill
it
down
to.
First
of
all,
it
doesn't
seem
like
anyone
objects
to
transparent,
interrupt
being
possible
by
you
know,
custom
loaders
or
something
implementation
details
to
be
figured
out
later.
The
real
contentious
part
seems
to
be
number
one:
should
it
be,
should
Interop
be
transparent
by
default,
meaning
should
you
without
extra
candy
chain,
any
extra
configurations
be
able
to
import
CJ
s
and
require
a
SM
and
then
the
secondary
questions?
H
That
is
it
only
if
yes,
and
until
we
decide
yes,
we
shouldn't
Mike
shed.
It
then
should
you
be
able
to
get
to
import
named
imports
from
CJ
s
files
and
so
I
would
I
would
I
would
be
great
if
we
could
establish
some
consensus
on?
Is
yes
or
no?
Do
we
want
transparent
Interop?
Well,
so
first,
do
we
want
transparent
in
or
out
to
be
possible
at
all
I'm
assuming
the
answer
will
be
yes
and
then
the
second
question
do
we
want
transparent?
H
E
Sure
so
I
just
want
to
bring
up
that
there
is
an
order
of
evaluation
shoe
if
we
don't
have
transparent
inner
Rob.
We
talked
earlier
in
the
meeting
about
order
of
evaluation
matters
for
some
use
cases
we're
setting
up
state
either
globally
or
some
shared
object.
If
you
don't
have
transparent,
interrupt
static,
imports
will
always
execute
before
any
ability
to
require
a
common,
j/s
module,
and
so
my
two
cents
here
are.
E
A
Do
we
want
transparent,
interrupts
to
be
possible
some
way
so
not
not
by
default,
not
by
not
default
Genesis
airily,
okay,
yes,
yeah!
Just
some
way,
I
think
that
I
don't
know
I,
don't
think.
We've
actually
held
call
on
that
and
I
think
that
that
is
a
it's
a
decent
one
so
and
we
do
have
quorum.
So
does
anyone
object
to
having
some
way
to
have
transparent,
interrupt.
A
C
For
me
that
that
question,
as
asked,
implies
that
there
is
a
way
to
require
ESM
using
something
like
a
custom
law
or
loda,
which
for
me
also
means
that
there's
a
way
to
secrecy,
get
a
module
or
the
export
of
a
module,
which
I
think
is
a
pretty
fundamental
constraint
on
our
implementation
and
features
we
can
add
in
the
future.
So
the
question,
as
generally
for
both
directions
should
trend
interrupts,
definitely
be
possible.
I
would
object
to
that.
E
Or
can
I
ask
for
some
clarification?
Well,
just
when
we're
talking
about
a
transparent
Interop?
Are
we
talking
about
requiring
ESN
currently
or
are
we
talking
about
importing
statically
commonjs
currently
because
come?
These
are
two
different
topics
of
transparent
interrupt
and
they
get
bundled
together
under
this,
so
I
just
want
to
know
if
objection
is
on
both
sides
or
just
one
side,
multi.
C
G
C
H
C
Even
don't
use
a
tinkerer
weight,
it
would
still
return
a
promise
like
every
right.
Import
would
return
a
promise.
So
if
you
try
to
require
it,
so
what
you
said
was
that
from
the
20s
side,
if
you
would
require
a
module
and
it
would,
you
would
always
get
a
promise
even
correct
promise
off
the
namespace.
That
would
count
as
promise
of
whatever
yeah.
Yes.
H
G
That
that's
an
implementation
detail,
it's
a
really
big
user
experience
problem.
If,
if,
if
modules
that
aren't
really
intentionally
exporting
premises
as
the
root
object,
start
exporting
premises
because
of
implementation
details
which
in
modules
it
is,
and
then
you
start
requiring
promises,
it's
you
I
want
to
back
up
just
a
little
bit
errors
from
it.
But
it's
not
it's
not
going
to
be
in
a
way
that
users
can
actually
tell
what
that
is
well.
So.
A
We're
getting
into
details
about
possible
at
possible
variations
of
transparent,
interrupt,
but
more
generally
allowing
a
form
of
transparent
Interop.
Do
people
have
like
not
by
default,
but
like
loaders
with
loaders?
You
can
do
anything,
but
do
we
have
an
that
without
how
kidding
into
if
we
require
should
be
able
to
do
this
or
not,
but
just
having
transparent,
interrupt
as
as
a
way
through
a
loader
functionality
or
by
default
not
specifying
either
one
right
now,
but
just
saying
having
it
be
a
possibility,
guilt,
yeah,.
I
A
Think
something
like
that
is
is
is
is
needed,
but
also
we
might
want
to
be
careful
about
scoping,
because
transparent
runner-up
is
a
is
a
pretty
large
umbrella,
and
so
we'll
have
to
be
careful.
How
we
divide
stuff
like
that
out,
but
I
would
say
if
yeah,
that's,
not
a
bad
idea
to
open
an
issue
on
and
propose
for
it
for
next
meeting
that
we
can
discuss
this,
because
the
other
side
of
that
is
non
transparent
or
out
what
which
needs
its
own
level
of
meeting
Jeremiah.
G
A
F
Yeah,
let's
try
and
keep
it
quick
as
much
as
possible
if
we
can
yeah
try
me
super
clear
with
this
terminology
because
it
does
become
a
very
loose
term.
So
maybe
we
should
think
in
terms
of
one-way
or
two-way
interrupt
and
then
also
from
the
commandeer
side.
Are
we
talking
about
requiring
yes
modules?
Are
we
talking
about
other
mechanisms
to
luteus
modules,
because
in
the
current
implementation,
that's
already
possible
to
use
dynamic
imports
with
in
common.
J
F
D
Yeah,
my
other
I'd
love
to
have
a
medium
all
about
this
I'd
also,
you
know
something:
I
was
hoping
to
get
out
of.
This
meeting
was
to
just
unblock
development
in
general
because,
like
I
feel
like
a
lot
of
the
discussions
that
people
are
having
both
from
these
meetings
and
in
github
is
basically
no.
Yes,
that's
not.
Yes,
that's
possible.
No,
that's
not
possible.
Yes,
that's
breaks
back;
no,
it
doesn't,
but
you
never
really
know
until
you
try
it
and
we
need
to
like
get
people
out
there
writing
code
and
I.
D
A
Are
I
did
want
to
mention
that
that
there
was
a
couple
of
places
during
today's
conversation
where
that
could
fit
in
as
well,
but
I
would
say
that
if,
if
you,
if
you
have
a
direction
that
you're
wanting
to
see
where
something
goes,
there
is
nodes
implementation
to
base
your
soxhlet.
If
you
want
a
starting
point
or
in
PM's
proposed
implementation
as
well,
which
has
more
code
for
you
to
like
work
on
as
well
and
I
would
encourage
you
to
start
digging
into
that
and
start
trying
to
write
the
implementation
so
people.
A
A
I
will
say
we
we
have
gone
over,
but
please
continue
this
discussion
inside
an
issue
and
I
think
we
should
open
an
issue
well,
were
we
have
an
issue
for
a
transparent
interrupt,
but
it's
probably
clouded.
We
should
open
one
just
for
the
agenda
item
for
for
next
week
to
discuss
it
weren't
more
thoroughly
and
we
can
start
to
flesh
it
out
there.
So
I'll
say
thank
you
all
for
it
for
coming
and
for
your
input
and
we'll
continue
this
in
the
group
discussions:
cool,
okay,
thanks,
everybody.