►
From YouTube: Node.js Foundation Modules Team Meeting 2018-12-19
Description
A
A
This
is
an
issue
that
was
opened
by
Jeffrey,
who
I
do
not
believe
is
with
us
today,
and
it's
specifically
about
trying
to
figure
out
how
we
can
organize
work
and
structure
work
within
the
group
and
in
fact,
Jeffrey
has
just
joined
us.
So
perhaps
Jeffrey
would
you
like
to
lead
the
discussion
around
number
230,
which
is
discussing
organizing
work,
hey.
B
I'm
sure
this
this
doesn't
need
to
be
that
big
of
a
thing
I
was
just
thinking
that
if
we
had
some
kind
of
scratch
pad
or
wiki
page
or
something
to
say
who
was
working
on
what
I've
been
with
some
wonderful
people
working
on
some
of
the
phase,
2
items
I
think
2-3
and
we
had
it
started
out
as
like
being
kind
of
a
mess
in
Google
Hangouts
and
we've
been
shifting
to
try
to
get
something
set
up
in
slack.
So
that's
something
else
that
we
could
maybe
broaden
out
to
beyond.
A
That
may
be
necessary,
but
is
this
something
we
can
enforce?
Is
it
something
that
it's
like?
If
your
name's
not
on
that
list,
you're
not
allowed
to
work
on
it
or
if
your
names
on
the
list,
you
have
to
include
everyone
who's
on
the
list
to
do
any
work,
I'm,
not
sure
that
that
kind
of
management
style
will
be
very
effective
with
the
way
in
which
people
within
noted
self
work.
That's
kind
of
my
initial
reaction
to
it,
but
you
know
process
involves
over
time
and
we're
a
newer
group
with
different
collaborators.
A
B
We
already
had
that
comment
from
the
phase
two
PR
where
I
just
said,
like
you
know
who
wants
to
work
on
what
you
know
add
a
comment
or
edit
my
comment
and
and
then
it's
just
like
it's
really
that's
all
it
is
it's
just
like
a
statement
of
these.
Are
the
people
interested
not
necessarily
interested
in
working
but
just
interested
in
that
piece
of
the
implementation
and
I
I
think
the
expectation
was
like
you
know.
B
C
B
Are
the
people
interested
in
these
things
to
you
know
if
you,
if
you
like
to
include
them,
you
know
such
as
for
the
purpose
of
going
to
the
next
step
of
trying
to
write
an
implementation.
Then
you
know
who
to
talk
to
about
trying
to
find
people
to
help.
You
write
the
code
people
to
test
it,
etcetera.
D
Yeah
I
don't
have
specific
recommendations
for
how
to
structure
things
any
better,
but
I
am
I
am
having
a
little
bit
of
trouble
understanding
the
directions
that
people
are
working
on.
I
think
the
phase
phases
document
is
a
great
starting
point
for
trying
to
understand
the
work
that
different
people
are
doing
so
that,
before
this
meeting,
I
took
a
look
at
that,
and
that
was
helpful
and
and
kind
of
framing
everything
in
my
mind,
but
I
still
feel
like
people
are,
you
know,
going
off
and
doing
doing
work
and
it's
hard
for
me
to
understand.
D
You
know
what
what
the
goals
of
various
groups
are
and
and
what
you
know
like
what
the
deliverable
is
at
the
end,
like
you
know,
like
we've
figured
out
that
this
is
the
way
we
want
to
do
and
here's
the
implementation
and
that's
that
or
is
it
more
like?
Okay
here,
here's
our
recommendation,
you're
suppose,
here's
the
cons
and
here's
some
other
alternatives
to
be
considered.
You
know
so
that
might
be
something
to
consider
to
you,
but.
B
B
We
could
put
it
on
the
roadmap
document
itself
and
have
some
kind
of
rules
about
what
kind
of
edits
are
allowed
on
that
without
quorum,
like
maybe
adding
and
removing
names
for
the
list
of
people
interested
in
each
thing
could
be
done
without
quorum
or
something,
but
no
other
changes
or
something
like
that.
I.
A
B
A
I
know
that
Salah
had
mentioned
I
think
this
may
not
be
a
bad
idea.
Either
is
a
project
board
because
we
can
use
a
project
board,
we
could
create
kind
of
like
I,
guess
it's
a
column
for
each
of
the
various
phases
or
specific
features
that
we're
working
on.
We
could
create
notes
in
there
to
keep
track
of
progress,
as
well
as
active
participants,
as
well
as
active
issues
that
have
to
do
it.
That
particular
bit
rob
you
of
your
hinder.
E
A
B
A
I
also
think,
like
I,
don't
think
we
really
need
consensus
to
start
documenting
those
things
unless
anyone
objects
on
the
repo,
but
does
anyone
object
to
moving
forward
with
making
a
project
board
to
track
some
of
this
stuff?
More
explicitly
all
right,
cool,
I'd
say
we're
good
to
move
forward
on
that,
then.
Does
anybody
want
to
take
the
action
item.
B
A
B
A
That'd
be
great,
thank
you
very
much
sure.
Okay,
the
next
agenda
item
that
we
have
is
dynamic:
module
development
in
node.
It's
issue
number
two,
four,
eight,
nine,
four
and
I
believe
that
this
is
also
connected
to
dynamic
modules
number
eleven,
which
we
could
see
as
a
reference
within
the
within
the
agenda
here.
I
guess
this
may
be
a
good
thing
for
either
guy
or
brad
to
lead
do
either
do
either
of
you
have
a
preference
well.
F
G
A
F
This
issue
and,
more
importantly,
to
me,
this
PR
came
about
after
we
actually
went
and
implemented
well,
I
should
say:
guy
implemented
this
spec
that
we're
trying
to
produce
four
dynamic
modules.
This
is
not
a
theoretical
thing.
This
is
kind
of
a
response
to
implementation,
and
we
encountered
something
that
was
controversial
to
variety
of
parties,
for
a
variety
of
reasons,
and
so
in
the
past,
the
way
we've
actually
managed
to
make
progress
is
not
by
making
mandates
that
a
feature
must
exist.
F
To
that
end,
this
PR
came
about
as
something
where
we
were
removing
a
feature
that
is
problematic
or
controversial
whatever
you
want
to
call
it,
it
has
overall
effects
on
the
system.
If
we
include
it,
the
this
PR
doesn't
really
prevent
from
happening
in
the
future.
So
it's
basically
just
reserving
future
design
space
by
removing
something
that's
controversial,
and
so
it
seems
like
in
these
discussions
we're
making
mandates
that
we
can't
remove
something
when
quite
the
opposite
of
that.
F
The
ways
we've
actually
managed
to
agree
as
a
group
are
by
removing
things
and
then
working
back
towards
adding
things
that
were
removed,
so
I
really
do
feel
like
we
should
land
this
PR,
even
if
we
end
up
reverting
it
next
month,
if
we
revert
it
next
week,
that's
great.
Nobody
is
arguing
that
we
shouldn't
have
this
export
star
from
syntax.
That's
not
really
what's
being
argued
about
it's
about
hey,
we
got
some
fee,
but
this
is
considered
controversial.
F
We
want
to
keep
momentum,
we're
gonna,
remove
the
controversy
and
put
it
off
into
a
separate
effort.
This
is
what
we've
done
for
a
variety
of
things.
This
is
what
we've
been
doing
with
the
minimal
kernel.
This
is
what
we're
doing,
by
approaching
things
as
separate,
phased
items,
we're
not
trying
to
tackle
everything
at
once,
because
this
entire
module
system
topic
has
so
much
overlap
that
we
are
unable
to
reach
consensus.
F
F
H
Yeah
there's
so
I
the
objection
I'm
seeing
on
the
PR
are
objections
of
the
kind
I've
had
in
the
past,
which
were
basically,
we
should
not
like
I,
find
it
unacceptable
to
ship.
Without
this
support,
and
the
consensus
we
reached
in
the
group
was
that
we
don't
need
to
be
at
that
level,
because
no
one
is
anywhere
close
to
proposing
shipping
and
unflagged
an
augmentation
yet,
and
so
with.
Any
change
is
important
to
note
what
future
work
needs
to
be
done
on
it.
H
So,
as
has
it
been
indicated
in
the
chat
like
clearly,
we
need
to
do
future
work
on
exports,
star
from
as
it
relates
to
CJ
s
in
order
to
answer
questions
about
what
we
do
next,
but
merging
something
that
removes
functionality
or
breaks
people
or
whatever
now
to
me
is
irrelevant,
because
the
purpose
is
to
make
progress,
we're
not
maintaining
an
API
here
and
if
anyone's
depending
on
this
functionality.
My
personal
opinion
is,
they
deserve
to
get
broken.
H
I
mean
I
would
be
fine
with
like
using
the
Shah
of
the
commit
as
the
API
names
so
that
it
breaks
them
every
commit
if
necessary.
Nobody
should
be
to
be
should
be
relying
on
the
stability
of
this
feature
and
then
separately,
like
I.
Think
that
blocking
progress,
because
it's
not
good
enough
yet
to
unflagged,
is
something
that
we
all
as
a
group
already
agreed.
Not
to
do
so.
I
would
really
like
to
see
this
PR
land
with
the
very
obvious
and
already
established
point
that
this
needs
to
be
addressed
long
before
unflagging.
B
All
right,
I,
don't
have
an
opinion
on
the
underlying
issue.
I
was
just
gonna
say.
Reading
this
long
thread
definitely
made
me
think.
Wow
I
really
hope
that
these
folks,
like
scheduled
a
meeting
soon
I,
don't
think
we
have
enough
time
in
this
meeting
to
go
through
all
this,
but
yeah
I'm
I
would
I
understand,
Bradley's
frustration
about
having
to
wait
until
January,
but
it
feels
to
me,
like
everyone
involved,
needs
to
just
have
a
good
long
hour
to
our
meeting
to
hash
out
all
these
issues
when
everyone's
available
to
talk
about
it.
F
Oh
I
have
a
response
to
that
I.
The
topics
being
discussed
in
the
comment
thread
are
not
related
to
actually
the
spec
they're
related
to
a
loss
of
a
feature,
and
the
loss
of
the
feature
is
exactly
because
of
a
controversy.
I,
don't
see
how
having
another
meeting
is
going
to
tie
us
back
to
the
spec
when
we
can't
talk
about
the
spec
in
this
comic
read
at
all.
F
D
You
know
we
show
get
together
and
just
talk
about
our
different
concerns
like
we
don't
have
to.
We
don't
have
to
make
this.
You
know
a
controversial
big.
You
know
big
line
and
the
same
kind
of
thing
right
here
right
now.
It's
just
it's
not
really
a
good
time.
For
that
we
should
just
you
know,
take
a
couple
steps
back
and
then
the
first
week
in
January
we
can
sort
this
out
and
you
know
I'm
confident
that
we
can
so
yeah
I
think
that's
all
I
have
the
same.
C
I
F
I
want
to
loop
back
kind
of
after
hearing
those
comments
once
again,
I
think
this
is
a
procedural
thing.
We've
managed
to
have
momentum
because
we've
been
able
to
separate
out
contra
all
parts,
even
if
we
don't
want
to
ship
up
I,
don't
think
people
want
to
ship
the
minimal
kernel,
but
we
were
able
to
agree
upon
it
and
build
upon
it
and
it's
not
so
controversial
anymore,
and
so
we're
able
to
focus
on
these
phases
and
things
and
I
don't
want
these
pull
requests
to
be
bogged
down
in
the
same
way.
F
I
want
this
pull
requests
in
particular
to
land,
because
it
separates
a
controversial
bit
from
what
we're
actually
having
implemented
right
now,
because
we
don't
know
what
we're
gonna
implement
for
something
and
so
making
a
forwards
path
for
people
to
work
on.
That
is
great.
It's
a
way
for
us
to
talk
about
it,
but
blocking
people
from
actually
making
it
for
its
path,
blocking
them
from
moving
forward
with
their
proposals
because
of
a
controversial
feature
and
refusing
to
let
them
move
that
controversial
feature
into
a
separate
discussion
from
other
parts
of
the
proposal.
F
It's
just
gonna
block
the
whole
proposal,
like
let's
step
back
a
bit.
Jordan
said
he
doesn't
want
to
ship
anything
without
this
syntax,
that's
fine,
but
if
we
take
that
at
its
core,
the
way
we've
approached
all
these
problems
is
to
remove
controversy.
If
dynamic
modules
become
controversial,
such
as
we
find
for
some
reason,
it's
unacceptable
to
ship
exports
start
from
that
doesn't
mean
we
keep
it
with
exports
start
from.
F
That
means
we
removed
the
entire
feature,
and
so,
instead
of
letting
this
feature
evolve
and
have
separate
sub
features
that
were
able
to
work
on
that,
we're
able
to
polish
we're
trying
to
remove
the
entire
feature
by
saying
we
don't
want
to
land
this
PR
in
my
mind,
because
we're
refusing
to
let
us
agree
upon
anything
because
of
absolutes
and
the
absolutes
here
are
basically
that
we
have
to
Neverland
stuff
that
we're
not
gonna
revert,
which
I
totally
want
to
land
stuff
that
we're
allowed
to
revert.
We
can
make
mistakes.
F
F
F
D
A
A
G
Hi,
alright,
so
if
I
cut
out,
then
I
cut
out
so
I
see
much
like
Jordan.
This
feature
is
kind
of
a
a
requirement
for
the
scope
of
of
the
goal
of
transparent
Interop.
It's
it's
one
of
the
driving
forces
of
a
reason
to
have
transparent,
inter
up
in
the
first
place.
So
to
me,
it's
like
it's
cutting
out
critical
functionality,
and
my
concern
is
that
in
in
cases
there
have
been
cases
where
we
can.
G
G
G
Main
concern
is
that,
since
this
is
pretty
critical
to
transparent,
interrupt
in
the
feature
as
it
as
a
whole,
I
don't
think
it's
it's
really.
It
meets
it's.
It's
a
candidate
for
being
cut,
I.
Think
it's
a
candidate
for
being
term
for
being
really
really
worked
on
to
make
sure
we
can.
We
can
solve
this
thing,
because
if
we
can't
solve
that
thing
to
me,
it's
it's
a.
It
really
mixes
the
feature
as
a
whole.
So
that's
why
I
don't
think
this
is
something
that
we
can
just
fluff
off
at
the
top.
A
Jdd
quickly,
we've
hit
our
time
on
on
this
agenda.
Item
I
just
want
to
suggest
something
quickly
and
then
Brad
I
know
you
had
your
hand
up,
but
we
can
extend
the
time
if
people
want.
It
seems
to
me
like
perhaps
like
what
I'm
hearing
is
from
some
individuals
like
hey.
We
need
to
land
this
to
start
working
on
the
solution
for
the
problem
that
people
are
pointing
out.
Other
individuals
are
saying:
hey
like
this.
Entire
thing
may
be
a
non-starter
if
this
doesn't
work
properly.
A
Now,
if
this,
if
this
landed
with
like
the
Express
contract,
that
a
if
another
solution
could
be
brought
that
solves
this
problem,
that
it
would
be
reverted
or,
alternatively,
if
it
cannot
be
solved,
it
would
be
reverted,
is
there
like?
Is
there
any
benefit
to
waiting
two
weeks
versus
landing
it
now,
like
Judy?
Does
that?
Does
that
appease
any
of
your
concern,
if
we
like
make
consensus
right
now
on
that
agreement?
Sorry.
G
I'm
finding
the
button,
so
that's
something
that
wasn't
really
discussed
and
I
I
was
thinking
about
that
too,
like
what,
if
we
add
the
qualifications
to
this
thing,
that
says
like
hey
this,
this
can
be
reverted,
and
this
this
should
be
reverted
or
like
a
solving
this
as
a
requirement
for
the
feature
as
a
whole
puts
puts
a
good,
puts
the
right
level
of
importance
on
it.
Just
because
I
can't
see
the
driving
force
of
transparent
inter
up
here,
making
it
to
where
it
we
lose
transparent.
G
G
A
A
G
A
G
I'm
not
really
picky
on
where
it
lives.
If
it
lives
in
the
actual
dynamic
modules
proposal,
which
is
where
I
guess
it
would
make
sense,
or
if
you
anchor
it
to
another
piece
to
since
it
is
kind
of
critical,
then
then
that
makes
sense
to
us
I'm
loose,
though
so
talk
to
someone
else
with
stronger
opinions.
Okay,.
A
A
B
F
D
G
We
don't
ship
with
transparent
in
around
then
it's
non
transparent
in
Iran
and
that's
you
know
that
to
me
is
a
livable
outcome
as
well,
but
I
rather
have.
If
we
have
transparent
enough,
which
is
my
preference
I
rather
have
it
then
have
just
a
non,
not
a
full,
transparent
interoperate.
You
know.
So
that's
that's
my
my
bit.
It's
the
worst
case.
We
we
have.
We
have
non
transparent,
Interop
and
that's
just
the
the
path
that
we
yeah.
A
G
A
A
That's
there
do
we
have
any
objections
to
landing
guys,
pull
request
now
under
the
assumption
that
we
will
document
in
phase
two
sorry,
can
you
just
clarify
that
mouth
yeah
we
will
document
in
our
roadmap
that
we
will
be
exploring
the
space
of
export
star
and
coming
up
with
a
solution.
Otherwise
we
would
we
would
be
open.
We
would
look
at
reverting
module.
J
J
Is
you
know
if,
if
at
the
end
of
this
process,
it
can
well
turn
out
that
we
don't
go
forward
with
dynamic
modules
because
of
these
concerns,
and
if
that's
the
case,
what
then
concerns
me
is
going
back
on
transparent
intro
and,
if
that's
the
case,
then
the
single
concern
will
successfully
achieve
both
of
those
goals
and
that
to
me
is,
and
not
at
all
ideal
I
think
it's
pretty
much
certain
that
it
will
not
be
possible
to
fix
this
case.
No
one
wants
to
discuss
the
details
with
me.
People
keep
putting
it
off.
J
They
would
need
to
be
produced
into
spec
material
and
it
would
need
to
be
put
into
ECMO
6
we'd
need
to
rewrite
abstract
module
records
in
the
way
they
work.
That'll
only
be
possible
six
months
down
the
line.
This
means
the
modules
land
without
dynamic
module
supports,
and
that's
fine,
if
that's
what
we've
achieved.
But
then,
if
we're
going
to
put
a
prerequisite
on
that
that,
if
this
gets
reverted,
then
we're
gonna
reconsider
transfer
an
interim.
J
Then
all
of
the
directions
that
we've
gone
down
a
basic
needs
and
that's
fine,
if
that's
what
people
are
looking
to
achieve
and
they
will
successfully
achieve
it,
but
the
so
that
the
two
things
is
one
I
would
really
value.
A
single
use
case
example
of
why
this
is
suddenly
so
important
and
could
someone
please
actually
discuss
the
technical
details
at
some
point
and
put
some
thought
and
time
into
it,
because
it
feels
like
people
are
talking
around
the
issue
and
the
ones
actually
diving
into
it.
G
So
I
think
Bradley
did
a
scan
and
showed
usage
in
the
wild.
This
is
native
syntax.
This
is
syntax,
that's
used
by
people
writing
and
assuming
transparent
Interop
today,
which
is
that
that's
the
use
case
it's
out
there
in
the
wild
today,
devs
have
an
expectation
with
their
transparent,
Interop
hat
on
of
this
working.
Without
this
feature,
then,
all
of
a
sudden
they
have
to
care
about
the
parse
Co,
all
of
the
things
that
require
it
or
we
push
work
on
to
the
devs,
which
is
pushing
work
on
millions
of
Deb's
versus.
When
you
explain.
A
G
H
H
A
F
So
since
my
name
was
first
I
just
want
to
say
if
the
scam
I
did
actually
doesn't
really
show
heavy
usage,
also
most
of
the
usage
is
behind
a
transpiler
permanently.
So
I
I
don't
think
it's
a
compelling
argument
to
use
my
scan
about
stuff
unless
we
actually
go
and
discuss
what
the
metrics
mean
and
we
can.
B
K
L
Jeremiah
yeah,
okay,
I
have
two
things
number
one
is
that
I
really
disagree
that
that
is
necessarily
our
audience
for
dynamic
modules.
I
think
a
lot
of
our
audience
for
dynamic
modules
in
the
end
is
people
who
are
unable
to
switch
at
the
current
time
still
and
that
will
come
down
the
line
later
so
I'm
not
sure
if,
judging
by
what's
out
there
and
transpiled
cody's,
isn't
necessarily
the
be-all
and
end-all,
I
think
the
opposite.
L
The
other
thing
is
I,
think
a
road
where,
because
this
ultimately
small
part
of
what
you
can
do
with
importing
things
is
not
able
to
be
implemented,
and
so
maybe
dynamic
modules
are
reverted,
and
then
we
want
to
back
dynamic,
not
dynamic
modules,
as
in
the
spec,
but
dynamic
modules,
as
in
common
J's,
Interop
out
of
node
I
think
is
unacceptable.
Okay,.
A
A
I
believe,
but
I
could
be
wrong,
that
if
we
have
webassembly
modules
doesn't
may
not
be
able
to
be
statically
analyze,
they
might
be
I'm,
not
sure
how
that
works,
but
similar
dynamic
module
records
may
be
necessary
for
those
other
future
roles
that
may
come
in
the
future.
You
may
require
them
as
well,
so
you
know
trying
to
find
a
solution
here
to
the
space
that
solves
it
is
kind
of
a
bigger
problem
than
just
node
guide.
You
have
something
to
say
that
talks
to
that
yeah.
J
You
can
just
clarify
that
so
webassembly
modules
are
implemented
as
their
own
module
records.
Just
like
dynamic
modules
is
its
own
module
record,
and
these
are
all
based
on
the
same
abstract.
Module
record,
respectful,
webassembly
modules
has
currently
been
drafted,
and
it's
we
were
having
discussions
at
one
point
about
seeing
if
there
was
a
shed
base,
but
rather
than
what
we've
gone
gone
ahead
with
is,
is
just
making
these
separate
module
records
and
dynamic
modules
you
can
think
of
them
may
be
as
programmatic
modules
modules,
whose
exports
are
only
known
at
execution
time.
J
They
have
a
kind
of
programmatic
population
and
and
the
key
like
constraints
of
programmatic
exports
population.
Is
you
don't
know
what
it
exports
until
it
executes
its?
So
you
can
do
everything
you
can
do
named
exports
and
all
these
things.
But
if
you
want
to
write
exports
star
from
dynamic
module,
we
can't
do
the
static
validations
of
exports
star
that
happen
at
instantiation
time,
not
execution
time.
J
Well,
you
have
to
do
things
like
check
if
you
have
to
export
star
statements
next
to
each
other
if
they
both
export
the
same
name
they're
supposed
to
be
an
ambiguous
error,
that's
thrown
during
instantiation,
so
there's
a
clash.
We
don't
know
if
it
clashes
until
we
execute
it
so
that
whole
clash
process
has
to
be
done
differently,
and
so
it's
those
kind
of
complexities.
J
A
So
I
think
that
perhaps
based
on
the
conversation
that
we're
having
right
now,
perhaps
we
should
separate
the
discussion
about
transparent,
Interop
and
dynamic
modules
and
perhaps
a
better
way
of
phrasing.
It
then,
if
dynamic
modules
ends
up
not
be
if
we
can't
reach
consensus
on
the
implementation,
that
I
think
that
it's
less
I
think
it's
less,
that
we
wouldn't
be
doing
transparent,
Interop
and
more
dynamic
modules
wouldn't
be
the
way
we
do
transparent
and
drop,
because
we
could
still
explore
other
models.
A
G
No,
your
point
is
exactly
correct
or
I'm
on
the
same
page
as
that
yeah.
Just
because
dynamic
modules
isn't
may
not
be
the
path
for
a
transparent
interim
doesn't
mean,
there's
not
other
ways
to
do
it.
I'm
I'm,
a
big
fan
of
you,
know
trying
it
till
it
works
and
having
it
at
some
possible
some
way.
If
that's,
you
know
out
of
the
speck
space
in
a
loader
in
user
land
with
hooks,
you
know
all
these
different
ways
to
do
it
then
great
then.
A
I
guess
maybe
this
is
an
interesting
question
to
pose
to
the
group
it
doesn't
sound
like
we
are
anywhere
close
to
consensus
in
that
being
able
to
implement
export
star
would
definitely
mean
that
it's
being
removed,
and
if
we
were,
if
that
were
to
be
something
that
ends
up
getting
pushed
to
a
vote
as
I.
Imagine,
eventually,
there
will
be
a
couple
things
that
we
will
have
to
do
like
JD
kind
of
yeah.
G
If
the
goal
is
transparent
in
our
up,
I
haven't
feel
pretty
lousy
about
it.
I
think
it
just
depends
on
how
we
scope
our
our
expected
outcomes
and
our
desired.
Like
result
like
what
do
we
want
to
achieve?
You
know
with
my
with
my
dev
hat
on
I'm
thinking.
You
know,
dynamic
modules
is
a
way
for
me
to
have
as
close
to
the
devil,
spirits
that
I
have
today
with
like
gonna
babble,
transpiler
can
do
named.
Exports
I
can
do
exports.
Star
I
can
interact
with
this
common
J's
file
like
I.
G
G
But
if,
if
we
scope
that
out
and
to
something
else-
and
this
you
know,
dynamic
modules
means
something
else,
then
you
know
we'll
have
to
go
down
that
road
and
discuss
that,
if
discussing
with
the
the
whole
like
meeting
dev
expectations
with
that
to
my
Mike,
you
know
I,
wouldn't
I,
don't
think
it
can
I,
don't
think
it
can
make
it.
But
you
know
if
we
change
what
it
means.
Maybe.
J
I
just
wanted
to
say
one
thing
and
just
in
the
worst
case,
snore
if
dynamic
modules
get
shelved
and
we
don't
get
them
into
the
implementation
in
time.
I
want
to
be
very
clear
that
I'm
still
think
it's
very
important
that
we're
able
to
move
forward
with
transparent,
interrupt
and
I
think
it
would
be
a
bad
outcome
if
this
would
change
attitudes
on
Transat
apparent
interrupt
or
if
it
would
result
in
the
entire
implementation
being
delayed
by
months
and
I.
J
Think
those
are
two
bad
stories
that
we
want
to
avoid
in
terms
of
how
we
approach
dynamic
modules.
So,
ideally,
I
would
like
to
approach
this
from.
If,
if
we're
not
gonna
get
dynamic
modules,
then
can
we
agree
that
we're
gonna
still
be
able
to
consider
transparently
interrupts
equally
and,
secondly,
that
we're
gonna
still
move
forward
with
implementation
work
and
not
allow
this
to
delay
implementation
WordPerfect?
J
A
With
the
caveat
which
we
will
document
that
if
we
cannot
reach,
if
we
cannot
find
a
solution
for
export
star,
then
we
will
revisit
this
conversation
to
reach
consensus
within
the
group
about
whether
or
not
we
want
to
revert
dynamic
modules
and
so
I
think
I
think
that
that's
less
specific
like
specific,
but
it's
just
kind
of
like
hey.
Let's
deal
with
that,
when
we
get
there.
J
A
J
A
G
I
mean
like,
if
you
want
to
have
only
a
tie
into
your
proposal,
I
mean
it's
your
it's
it's
guys
proposal
or
he's
the
champion
of
it.
If
there's
gonna
be
wording
changes,
you
know
that
would
probably
be
a
PR
to
that
proposal.
I'm
not
quite
sure
the
process
for
that.
But
if
it's
mentioned
inside
the
phases
doc
is
that
something
that
we
can
just
do
PRS
I
wouldn't
mind
miles
if
you
said
you're
kind
of
away
from
it
like
you're,
not
in
the
middle
yeah,.
I
A
So
what
I
would
like
to
propose
as
a
plan
because
of
timing
here
I
will
open
a
PR
against
against
the
phases
dock
and
because
we
have
quorum
right
now?
How
about
we
just
reached
consensus
that
if
that
PR
is
open
for
a
week
with
no
objections,
we
just
land
it?
Does
anyone
object
to
that
great
and
does
anyone
object
to
landing
guys
PR
today?
You
know,
under
the
assumption
of
goodwill,
that
we
will
be
documenting
this.
D
A
Time
of
year
it
is
Kevin
that
was
a
week
for
the
PR
against.
Did
the
dock.
You
like
the
documentation
of
this
oh
yeah
super
super,
and
so
the
idea
would
be
that
I'm
proposing
is
I
will
open
that
chain
to
our
dock
in
our
phases.
We
will
leave
it
open
for
a
week
before
landing
it
just
to
make
sure
that
people
who
are
on
aren't
on
the
meeting
have
a
chance
to
see
it,
and
then
we
would
go
ahead
with
landing
guys
PR
today
and
begin
with
that
work
for
our
next
meeting
to
see.
A
Excellent
y'all,
that
was,
that
was
a
tough
one.
Thank
you
all
for
sticking
through
it,
and
you
know.
Thank
you,
everyone
for
putting
in
super
hard
work.
We
have
five
minutes
in
the
meeting
left.
We
have
two
agenda
items
that
we
did
not
get
into
specifically
around
the
specific
import
file,
specify
resolution
proposal
and
the
ad
package
export
proposal,
but
I'd
like
to
suggest
that
we
wrap
the
meeting
early.
Just
because
you
know
we've
settled
all
the
things
and
I
don't
think
we
have
enough
time
to
really
dig
into
either
of
them
are
people?
B
J
J
The
two
specs
that
we
have
against
the
echo
script
modules,
repo,
there's
the
2p
Oz
they're,
basically
just
putting
some
implementation
work
together,
implementing
those
specs
as
written
and
at
least
getting
to
a
place
where
we
can
play
around
with
these
implementations
and
see
how
they
behave
and
and
certainly
not
set
at
the
set
in
stone
on
any
other
stuff.
At
this
point
and
if
anyone's
interested
in
trying
it
out,
please
feel
free
to
clone
clone
that
that
branch
run
it
and
maybe
in
future
meetings.
A
B
A
Would
like
to
request
them
just
for
what
it's
worth
that
around
those
proposals.
I
would
very
much
like
to
be
part
of
the
conversations
where
we
reach
consensus
around
it.
Okay,
so
you
know
like
let's
kick
back
to
the
issue
tracker.
If
we
want
to
reschedule
that
Wednesday's
meeting
as
a
one-off,
we
can
definitely
try
to
do
that
if
you
can
return
around
it.
Otherwise
you
can
run
the
meeting
and
I
mean
genuinely
as
well.
Well.