►
From YouTube: Node.js Foundation Modules Team Meeting 2019-01-30
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).
A
A
A
And
yet
don't
forget
to
add
your
name
to
the
attendance
as
well.
I'll
drop
a
link
in
the
chat
okay.
So
the
next
thing
that
we
have
on
the
agenda
is
a
five-minute
time
box
to
talk
about
the
slack
channel.
Perhaps
we
can
get
this
done
in
less
time
and
daniel
has
just
joined
me
over
here.
Maybe
I
could
turn
on
the
video
and
you
can
see
as.
A
A
B
A
So
just
double
checking
the
current
state
of
it
because
I
think
from
injections
on
it
were
myself
and
Gus.
So
the
text
now
says
there
are
several
public
places
where
the
modules
group
has
been
discussing
their
work.
The
issues
the
nodejs
slack
channel
so
I
mean
this
still
makes
it
sound
like
it's
an
official
place
for
discussions
in
the
group,
which
is
what
my
initial
objections
were
to
having
it.
There.
B
D
Current
topic
and
because
we
are
so
much
like
it's
actually
related
to
the
slack
I'll,
come
to
that
in
a
sec
I
think
we
can
avoid
trying
to
organize
everything
on
a
board
if
we
have
an
official
place
where
people
conduct
these
discussions
so
that,
if
somebody's
coming
in-
and
they
want
to
talk
about
a
particular
topic-
we
can
have
a
dedicated
place
where
these
discussions
take
place.
They
can
just
go
there
that
will
negate
the
need
for
a
board
altogether,
because
you
know
yeah,
that's
what
it
is.
Okay,.
A
Let's
just
move
this
offline
then
and
get
to
the
next
agenda
item
unless
anyone
has
anything
else
to
add
okay.
So
the
next
item
that
we
have
is
dynamic
module
development
in
nodejs
and,
if
followed
by,
that,
is
also
the
minimum
to
release
I
think
these
are
kind
of
interspersed.
Does
anyone
have
an
opinion
on
the
order
of
these
to
stick
with
the
order?
We
currently
have
okay,
cool,
so
dynamic
modules?
Guy.
Do
you
want
to
give
us
an
update
on
the
discussion
that
happened
earlier
this
morning
in
tc39
since
you're
there
live
from.
A
E
Sure
I
think
yeah,
it's
a
shame.
We
don't
have
a
bradley
here
as
well
or
an
official
reference
on
the
notes
but
and
I
I
guess
we
present
presents
at
the
the
current
layering
proposal,
with
the
restriction
of
removing
and
basically
throwing
in
the
export
star
from
communist
or
export
star
from
dynamic
module
case,
which
was
discussed
at
the
last
tc39.
So,
oh,
there
is
okay.
A
E
The
fact
that
we're
allowing
this
this
kind
of
loosening
of
one
of
the
embarrass
in
modules
and
and
then
there
was
also
some
resistance
to
having
the
export
star
restriction.
So
in
general
there
was
quite
a
lot
of
resistance,
and
this
was
a
meeting
where
the
goal
for
us
as
a
group
would
have
been
to
have.
You
know
it's
the
first
time
it's
represented
to
tc39
since
es2015.
E
In
this
exact
topic
has
been
discussed
many
times
over
the
years
there
have
been
promises
from
tc39
in
the
past
to
develop
specifications
along
these
directions.
Originally
caridy
worked
on
a
proposal
homely
that
did
exactly
something
similar
when
it
was
agreed
at
a
previous
meeting
that
piece
of
direction
should
be
sued,
and
so
the
general
feeling
is
that
there
isn't
necessarily
anything
further
that
we
can
do
to
present
it.
E
There's
no
implementation
feedback,
I
mean
there's
potentially
a
way
that
we
could
guard
the
spec
to
say
this
only
happens
for
comment,
yes
and
and
not
for
other
other
types
of
module
systems,
and
it's
not
going
to
be
poisoning
other
things,
but
there
was
a
degree
of
resistance
there,
and
you
know
we
didn't
get
the
a
nice
clean.
Yes,
that
that
would
have
been
ideal
for
us
to
then
say:
that's
move
forward
with
implementation.
E
F
F
F
Did
not
actually
object
due
to
lack
of
attendance,
but
they
they
do
have
concerns
raised
on
github
I
think
the
forbids
clause
was
a
way
for
us
to
explicitly
remove
some
discussion
that
was
being
had
on
it
leaking
to
other
locations,
and
that's
something
we
can
do
to
alleviate
that.
However,
Ellen's
concern
is
more
general
with
modifying
source
ex-model
record
it
all
and.
F
A
A
So
I
mean
might
take
away
from
like
a
really
really
high
level.
Was
it
just
feels
like
this
isn't
happening
today?
It
isn't
happening
quickly.
If
it
ever
did
happen.
You
know,
individuals
were
definitely
like
supportive
of
findings
been
doing
breakouts
to
try
to
do
it,
but
I
think
that
this
is
like
you
know
us.
A
We
went
in
November
and
like
we've
gone
before
and
I
as
foot
has
been
presented
multiple
times,
and
it
is
controversial
with
different
parties
for
different
reasons
and
at
least
to
myself
and
for
those
who
were
on
the
call,
please
interject.
If
you
think
that
I'm
being
too
harsh
here,
it
does
not
feel
like
it
will
happen.
A
C
I
actually
agree
on
that
point.
The
way
I
think
I
took
around
took
from
that
meeting
was.
There
are
concerns
about
people
different
implementers
using
it
for
different
browser
implementations,
but
that's
not
necessarily
as
long
as
as
long
as
that
can
be
prevented.
They
feel
okay
with
it.
That's
how
I
took
that,
and
so
it
sound
like
people
responded
fairly
positively
to
some
sort
of
restricted
like
nxb
sort
of
thing,
maybe
I,
don't
necessarily
know
it's
like
some
sort
of
single
tight
one-time
exception
to
it,
but
that's
that's
how
I
read
into
it
as
well.
A
C
I
mean
I
think
that
was
sort
of
this
dual,
maybe
conversation
that
was
happening
as
well
like
there
was
a
focus
on
that
for
a
day,
but
it
sounded
like
people
were
basically
thinking
that
there
is
a
way
forward,
like
people
wanted
to
somehow
support
node.
They
didn't
necessarily
know
whether
or
not
this
was
the
approach,
maybe,
but
they
were
certain
like
if
we
need
to
make
a
change
like
we'd,
be
willing
to
make
an
exception
just
for
know
what.
E
A
F
A
To
him
offline
about
it
and
it
seemed
more
flexible
on
it,
but
it's
just
like
it
seems
like
there's
at
least
three
or
four
different
objections
that
we
need
to
follow
up
with
to
get
this
through
and
I.
Guess,
like
the
flip
side
of
it
and
I'm,
not
trying
to
be
unreasonably
negative
and
I'm
not
giving
up,
but
it's
just
like
I,
don't
know
how
we
feasibly
do
this
in
a
time
frame
that
has
a
shipping
any
time
in
the
near
future.
A
I
guess
in
theory,
we
could
decide-
and
maybe
this
is
something
that
we
could
talk
about
today,
but
maybe
we
could
just
decide
to
move
forward
with
the
assumption
that
we
can
have
some
sort
of
solution
in
this
space
before
April,
because
there's
another
meeting
in
March,
and
we
have
time
to
do
it
with,
like
the
caveat
that,
if
we're
unable
to
get
consensus
by
March
meeting
that
we
are
all
on
the
same
page
about
what
the
alternative
path
would
be,
I
think
that
seems
potentially
the
best
path
to
go.
That
doesn't
block
progress
today.
D
Yeah
I
was
actually
going
to
say
exactly
that
like
I'm
wondering
if
we
should
explore
a
way
to
accomplish
this
parallel
with
pure
JavaScript
I
know
it's
not
gonna
be
clean,
but
but
to
have
a
parallel
approach
where
we
can
use
the
same
API
to
use
the
dynamic
module
when
it
lands
or
to
defer
to
a
JavaScript
polyfill.
If
you
like,
that
would
do
the
same.
E
I
can
chose
white,
consider
another
option,
which
was
you
know
if
we
could
possibly
light
a
patch
in
node
that
added
the
support
for
it
effectively.
Like
a
you
know,
a
patch
to
be
eight
and
I
did
discuss
that
briefly
with
Michael,
but
from
from
what
it
sounds
like.
That's
not
something
that's
been
done
before,
or
that
has
much
kind
of
you
know.
Node
doesn't
typically
add
its
own
functionality
to
b8,
and
especially
when
this
witness
so
much
activity
happening
on
v8.
E
B
Just
gonna
say
in
regards
to
the
import
file
specifier
proposal,
if,
if
we
think
that
there's
a
chance
that
we
might
get
named,
exports
from
common,
J's
and
or
comma
J
s
Interop
in
some
form
that
we
would
be
willing
to
ship
at
in
the
future
at
all,
then
we
kind
of
have
to
design.
For
that
like
we
can't
just
decide.
Oh
we're
never
going
to
have
interrupts
so,
therefore
we
don't
need
all
the
complexity
of
like
managing
different
types
of
packages,
blah
blah
blah.
B
A
A
Before
the
node
twelve
cut,
we've
come
back
and
forth
multiple
times
and
each
time
there's
people
giving
push
back.
So
I
think
that
if
we
can't
in
two
months
alleviate
concerns
that
committee
members
have
I
think
we
need
to
move
forward.
Assuming
that
this
is
not
going
to
happen,
but
I'm
happy
for
other.
F
To
clarify
a
little
bit
for
Jeff's
point:
if,
if
we
do
want
to
seek
this
after
we
ship
something,
we
still
do
need
to
carve
out
the
design
space
for
it.
So
a
good
example
of
this
is,
if
we
ship
some
form
of
common
J's
Interop,
we
are
locking
ourselves
into
a
design
space,
so
like
just
being
able
to
import
common
Jas
would
also
be
a
way
to
shut
down
this
potential
path
board.
F
A
So
kind
of
like
following
up
on
that,
they
can
theory.
We
can
do
something
from
the
hierarchy
proposal
that
allows
you
to
specify
the
type
of
the
module,
but
not
use
that
to
to
change
how
the
loader
itself
works.
So
we
would
carve
out
the
design
space
that,
like
that
mechanism,
is
there
and
then
not
have
interrupt
but
work
towards
Interop.
If
we
eventually
were
able
to
fix
the
dynamic
module
stuff
right.
B
A
G
A
I
This
is
probably
gonna,
be
punched
into
the
next
topic,
but
I
just
I
don't
want
to
make
I
think
it
would
be
a
big
mistake
to
make
any
shipping
decisions
whatsoever
based
on
any
form
of
timeline
or
desire
to
go
quickly.
I
think
we
should
ship
the
right
thing
or
nothing,
and
what
that
is
is
still
undetermined,
but
I.
Think
iteratively
working
on
things
is
a
good
approach
for
api's,
but
for
things
like
this,
that
affect
the
ecosystem,
I
don't
think
there.
A
Let's
jump
right
into
the
next
agenda
item.
Thank
you,
everyone
for
digging
into
this
and
then
just
so
I
see
where
we're
at
for
time.
We
have
two
more
things
or
we
have
three
more
items
and
I.
Guess
it's
the
minimum
to
release
the
IRP
type
dynamic
modules
in
the
specifier
proposal
should
have
just
enough
time
to
hopefully
get
into
most
of
them.
A
What
I
would
love
to
see
us
happens,
a
timeline
independent
of
anything
else
is
we
have
the
minimal
kernel
and
we're
starting
to
expand
it
with
different
things.
I
would
love
us
to
at
our
next-gen
our
next
iteration
of
the
implementation
behind
a
flag
with
12,
with
the
intention
of
removing
that
flag
before
October,
1
and
12
goes
to
LTS
for
what
it's
worth.
We
also
have
prior
art
of
shipping
things
and
removing
the
flag
during
yeah
LTS.
We
did
that
with
HTTP
2.
A
We
also
did
that
with
napi,
and
we
even
did
that
late
in
LCS
when
necessary,
but
the
more
turn
that
there
is
the
more
things
that
it
touches.
The
more
changes
that
there
are
the
harder
that
that
becomes
to
do
so,
something
like
HTTP
2
or
an
API
that
had
the
flags
removed.
You
know.
Yes,
it
was
more
of
a
stability
thing
than
a
design
space
thing
like
HTTP
2
was
mostly
designed
and
mostly
done.
It
just
wasn't
agreed
to
be
stable.
A
Yet
so
you
know
these
are
kind
of
some
of
the
things
that
are
coming
in
and
the
timelines
that
I
think
are
worth
considering
and
to
the
point
that
Jordan
had
raised
before
that
we
punted
on
about
design
space
and
about
you
know,
timing
on
all
this
I'm
kind
of
of
the
opinion
at
this
point
that
we
need
to
ship
something
and
I
understand,
Jordan
that,
where
you're
coming
from
on,
we
need
to
design
this.
We
need
to
design
this
right
and
take
the
time
to
do
it
right.
A
We
said
that
a
year
ago
we
said
that
two
years
ago
is
that
three
years
ago
and
I
think
that
we
are
in
decision
paralysis
and
that
we
will
prepare
I
truly
be
indecision
paralysis,
because
we
have
a
group
with
different
ideals,
goals
and
goals,
which
is
fine,
we'll
all
find
a
way
to
sort
that
out.
But
you
know
the
joke
I've
been
making
lately
is
you
know
we
wanted
to
avoid
a
Python
to
Python
3
situation
and
in
the
time
that
we
haven't
made
a
decision?
A
Python
2,
the
Python
has
almost
fixed
their
ecosystem,
and
so
we
can
debate
the
semantics
of
that.
But
what
I
mean
is
yes?
Making
the
wrong
decision
can
be
disastrous
for
our
ecosystem.
I
think
her
indecision
has
been
just
as
disastrous
and
continuing
to
be
stuck
in
this
mode
of
not
making
decisions.
I
actually
think
is
potentially
worse
for
node
than
making
a
decision.
That's
not
perfect
and
I.
A
Decisions
on
and
as
a
group
decide
that
we'll
vote
on
them
under
the
you
know,
respectful
decision
that
all
of
us
understand
that
we
won't
probably
be
able
to
reach
consensus
on
these,
that
they
are
hard
decisions
and
based
on
philosophical
differences
and
that
we
as
a
group
need
to
just
maybe
vote
on
them
and
then
always
a
group
accept
the
results
of
those
votes
and
work
towards
a
solution.
So
so
one
example
of
this
could
be
as
a
straw
would
be.
A
We
work
towards
shipping
transparent,
Interop
in
April
with
named
exports,
but
if
we
cannot
get
named
exports,
we
do
not
ship
transparent
Interop,
and
we
do
it
in
such
a
way
that
throws
so
that
the
design
space
is
still
able
to
be
explored
so
that
we
can
land
it
later.
If
dynamic
modules
can
ever
happen.
According
to
the
spec
and
I.
A
Think,
like
these
kinds
of
approaches,
are
nice
because
it's
saying
hey
like
the
people
who
don't
like
who
don't
want
transparent,
interoperate
concede,
if
we're
able
to
do
it
really
really
well,
but
if
we
have
to
make
concessions
than
the
people
who
want
transparent,
Interop
are
willing
to
concede
to
allow
us
to
move
forward
in
a
way
that
can
ship
and
have
the
design
space
over
I
think
the
other
ones
that
we'd
have
to
explore.
There
would
definitely
be
file.
A
Extensions
would
be
a
big
one
and
the
IRP
type
proposal
I
think
we're
close
to
like
consensus
on
that
I
think
we
could
strip
some
of
the
like.
We
could
have
kind
of
two
different
paths
that
could
go:
anyways,
I'm,
blabbing
I
will
stop
and
I'll
concede
to
the
to
the
other
people
with
their
hands
up.
But
if
people
don't
object,
I
almost
feel
like
at
this
point.
A
D
So
I
think
we're
all
a
lot
of
what
you
said
and
I
guess
what
I'm
trying
to
say
at
this
point
or
my
concern
at
this
point
sorry,
is
that
we
are.
We
are
trying
to
ship.
You
know
a
couple
months
from
now
or
so,
and
it's
going
to
be
not
not
the
full
implementation,
so
so
my
concern
as
someone
who
is
using
notes,
experimental
modules
to
grow
with
note
as
note
implements
modules
is
midway
through
I'd
like
yes,
new
features
to
come
in,
but
I
would
like
to
also
find
a
way
to
transition.
D
Everything
I've
been
working
on
to
explore
modules,
as
note
is
actually
releasing
the
experimentals
like
it's
a
concern.
It's
not
it's,
not
a
make-or-break,
but
it
would
be
nice
if
we
can
keep
in
mind
that
if
we're
still
really
at
releasing
something
that
is
flagged,
it
should
not
really
be
reset
to
anyone
who's
experimenting
with
the
flagged
implementation
that
exists
in
the
wild.
It
could
be
very
different,
but
at
least
it
shouldn't
take
away
features
that
they
might
have
built
some
experimental
projects
on
I
guess:
that's
it.
G
Experimental
is
no
warranty,
no
guarantee
we
can't
be
held
to
that
like
if
there's
so
many
every
time
I
see
someone
say
like
they
want
to
use
experimental
modules
and
productions,
I
kept
them
up
to
paragraph
long
disclaimer
of
text.
That
says
like
not
a
good
idea,
we're
not
going
to
support
that.
It's
not
part
of
the
servicing
as
far
as
I
know
for
experimental
features
cool.
That's
it.
It.
A
A
D
I
don't
mind
if
it's
breaking
very
breaking
as
long
as
it
doesn't
take
away.
You
know
the
full
support
of
CJ
ass.
All
of
a
sudden.
That's
what
I'm
not
saying
that
experimental
is.
You
know
somebody
experimenting
in
production
or
all
these
cases
that
we
know
have
come
with
no
warranty
but
I'm
just
talking
about
like
if
you
take
away
a
lot
of
features
that
that
that
is
a
concern.
It's
not
it's
not
being
you
know
a
blocking
thing
at
the
moment,
just
the
concern
I'm
raising
Jordan.
I
Yeah,
so
I
was
responding
to
still
Oz
point,
but
also
mounts
to
what
you
were
saying.
What
are
the
actual
breaking
changes,
because
anything
under
experimental,
as
we
were
just
saying,
I
think,
is
not
considered.
I
do
not
consider
that
breaking
I
actually
think
we
do
want
to
break
people
relying
on
it
because
they
need
to
learn
the
lesson
not
to
do
so
I.
I
It's
not
that
I
want
to
impose
pain
and
suffering
on
people,
but
like
I,
don't
I
see
it
as
a
good
thing.
If
there
is
breakage
and
like
people,
you
know
it's
there's
a
lot
of
people
who
learned
a
lesson
that
harmony
should
not
be
relied
upon
and
that
was
really
healthy
for
the
ecosystem,
because
people
stopped
relying
on
it
as
much.
I
Similarly,
like
I
think
that
if
there's
breaking
changes,
non-experimental
things
then
that's
something
we
may
need
just
consider
trying
to
get
in
by
OTS,
but
we
can
break
experimental
modules
in
LTS
anytime.
We
want
it's
experimental
and
I
think
we
should
feel
free
and
empowered
to
do
that,
and
we
should
actually
see
when
that
is
necessary.
We
should
see
that
necessity
is
a
good
thing,
because
it
reminds
everyone
of
the
experimental
nature
of
it.
So
so
I
guess
that
I
was
hoping
for
clarity
from
miles
about
like
what.
E
E
E
You've
got
people
experimenting
with
things,
and
they
can
do
it
through
the
experimental
loader
which
we
reverse
it
on
the
middle
implementation,
and
you
know
so,
if
we
shift
modules
without
that,
that's
kind
of
a
tricky
one
for
me,
because
it's
like
we're
taking
away
all
those
use
cases
and
and
and
my
project
specifically
you
know,
I've
used
these
hooks
and
I
want
to
be
able
to
hook
into
the
resolver
and
then
do
this
stuff.
So
it
would
be
kind
of
a
loss
if
the
experiments
with
implementation
doesn't
have
a
resolver
Kirk,
but
yeah.
A
Thank
you
for
taking
notes
on
this,
because
this
will
be
the
important
notes
to
have
I
think
the
things
that
we
do
not
have
consensus
on
right
now
that
we
need
to
figure
out
for
shipping
is
explicitly
like
our
Interop
story
and
how
we're
going
to
handle
that
I
think
from
a
feature
standpoint
and
then
file
extension
resolution
is
another
one
that
we
have
from
kind
of
the
specifier
stuff.
That's
one!
That's
the
other
one
from
missing
features.
A
I
think
the
two
largest
missing
features
that
we
have
right
now
are
loaders
and
VM
and
I
know.
Gus
has
done
a
bunch
of
work
on
the
VM
modules
in
the
past,
but
we
haven't
really
had
the
bandwidth
to
re-explore
that
space.
So
I
guess
this
is
just
a
very
very
pointed
ask:
do
we
need
to
have
VM
modules
reimplemented
in
order
to
replace
the
implementation
inside
of
core
right
now?
Would
people
block
on
that,
or
is
that
an
incremental
change
that
we
could
add
before?
A
Can
you
repeat
the
question
we
have
a
currently
node
core?
Has
a
VM
implementation
for
VM
spitting
up
modules
in
a
VM
module?
If
we
copied
over
the
minimal
kernel
as
it
exists
today,
we
would
be
losing
that
functionality.
Is
this
a
blocker
to
replacing
the
implementation,
or
is
this
something
that
we
could
replace
the
implementation
and
iterates
add
vm
modules
as
their
own
line
of
work,
because
currently
it's
phase,
two
gus
you've
got
your
hand
up
any.
H
There's
been
a
lot
of
not
a
lot
of
a
bit
of
iteration
on
vm
modules
in
core,
just
with
regard
to
like
a
lot
of
other
stuff,
we're
doing
with
like
speeding
up
node
start
times,
and
you
know,
cleaning
up,
bootstrapping
and
all
that
stuff,
and
I
think
it
would
be
counterproductive
to
revert
via
modules
back
to
what
is
currently
in
the
middle
of
implantation.
I
think
they
have
use
I
like
and
I
like
they're
a
separate
feature.
I,
don't
think
it
it
like.
E
J
Yeah,
so
what
I
would
say
is
that,
at
least
from
what
I
remember,
the
vm
source
text
module
leaked
a
lot
of
things
about
how
modules
work
and
how
low
does
work
and
how
low
does
interact
with
modules,
because,
implicitly,
it
has
to
hook
into
the
actual
import
system
that
which
is
different
from
source
text
and
just
to
run
script
thing.
So
I
see
real
risk
that
keeping
sex
mode
you'll
in
in
the
available
implementation
means
that
we
are
restricting
the
design
space
a
lot.
B
Was
just
gonna
say
adding
to
your
list
of
required
features,
I
think
a
entry
points
eval
standard
in
extension
list,
but
also
just
like
the
traditional
node
space
file,
dot
extension
I
think
we
need
a
like
a
unified
way
of
handling.
All
that
and
I
forgot
to
mention
when
we
talked
earlier
about
that
when
I
was
saying
like
asking
for
someone
to
help
with
it,
there's
also
a
pull
request
that
just
adds
that
to
our
faces.
So
if
we
can
find
time
to
hopefully
approve
that
to
okay.
A
So
kind
of
circling
back
on
the
VM
thing,
I
guess
like
one
question,
maybe
to
Brad
I,
know
that
realms
is
something
that's
being
worked
on.
I
know
that
it's
not
something
that's
coming
in
the
necessarily
near
future,
but
I
don't
see
anyone
implying
that
it
will
never
land
in
this
pack
like
it
just
needs
to
be
done
right
and
and
yarn.
Speaking
of
that,
could
we
arguably
say
and
I'm
not
saying
that
this
is
100
percent
accurate,
that
the
truly
perfect
solution
to
this
would
be
realms
to
VM
modules.
F
Youyou
could
not
make
a
module
in
the
main
context
for
node
realms
only
let
you
instrument
contexts
created
through
the
realm
API
and
that's
the
big
difference
with
me
and
module
they're
not
seeking
to
allow
you
to
do
that.
Also,
the
api's
are
very
different
from
what
you
might
expect
given
vm,
but.
A
F
A
So
yon
as
a
quick
question
to
you,
if
we
were
to
shed,
for
example,
VM
modules
and
shift
them
at
in,
like
almost
just
like
an
explicitly
deprecated
state,
almost
like
what
we
do
today
with
zones
are
not
zones
with
domains
under
the
assumption
that
realms
would
become
the
approved
way
of
doing
this,
and
over
time
we
could
deprecated
them.
Would
that
appease
your
concerns.
J
But
it
really
depends
on
it.
It
is.
It
would
be
unknown
unknown
for
me
always
because
whether
that
exact
API
will
stop
us
from
doing
something
in
the
wrong
space
or
whether
it
will
influence
like
it
will
be
always
this
weird
escape
hatch
that
works
slightly
different
and
where
there's
kind
of
a
ill-defined
interrupt
between
how
the
RAM
stuff
works
and
normal
main
model
une
autre
works.
And
then
we
ain't
sauce.
That's
my
own
little
world
that
have
completely
different
semantics.
So
it
just
feels
like
launching
it.
J
Deprecated
I
mean
sure,
but
I
mean
the
only
thing
that
we
really
gain
by.
That
is
maybe
an
evil
ass
module,
and
that
seems
very
narrow,
especially
because
it's
evil
as
a
neutral
module,
not
as
a
rebel
module
where
you
can
append
staff
to
like
its.
It
seems
very
restricted
in
what
it
brings
us
capability
wise
compared
to
the
potential
restrictions
and
puts
or
not
us
design,
space,
wise,
okay
and
then
missing
important
music.
Then.
A
J
A
H
Just
a
few
quick
clarifications:
VM
modules
are
behind
their
own
experimental
flag,
so
we
can
break
those
as
much
as
we
need
to
based
on
the
design
of
our
module
loader
system.
We
can,
you
know,
break
them
every
single
release
if
we
need
to
so
don't
feel
constrained
by
them,
and
the
other
thing
is
that
the
M
source
module
the
design
has
its
own
constraints,
one
of
which
was
in
fact
running
in
the
main
contact.
We
had.
H
A
Splitting
the
difference
there,
though
it
sounds
like
we
could
keep
VM
modules
behind
their
own
flag,
separate
from
the
flag
for
modules.
Would
people
be
ok
with
that
as
its
own
kind
of
branching
thing
and
to
not
allow
via
modules
themselves
to
block
but
not,
but
also
not
to
necessarily
remove
them,
because,
if
they're
behind
their
own
flag
in
theory,
we
can
also
just
remove
them
at
any
time
in
the
future,
it
doesn't
sound
like
a
decision
that
needs
to
block
our
ability
of
replacing
the
implementation.
A
D
So
so
definitely
like
a
second
what
God
said
and
what
you
said
and
I
just
want
to
say
that
p.m.
modules
at
the
very
very
least,
allow
someone
to
if
we
remove
experimental
modules,
no
matter
what
the
use
cases
I'm
not
making
claims.
If
we
remove
that,
with
VM
modules
being
very
very
similar
in
the
API
of
experimental
modules,
you
could
potentially
create
an
experimental
module
loader
that
does
that
through
the
vm
source
text,
module
and
that'd
be
separate
from
our
implementation.
A
E
On
those
actually
the
the
dynamic
modules,
one
of
those
PRS
is
basically
the
first
PR
or
actually
so
that
the
IRP
that
the
IRP
specifier
proposal
is
I.
Think
that
the
main
item
to
if
we
can
address
over
the
next
ten
minutes,
the
dynamic
modules
one
is
basically
the
implementation
of
it
with
dynamic
modules,
which
I
will
close.
Now,
since
we're
basically
haven't
made
progress
on
Democrats.
Well,.
A
I
would
hold
off
on
closing
it.
Yet
let's
follow
up
afterwards
on
that,
because
perhaps
we
should
still
move
forward,
assuming
that
we
can
make
solutions
in
the
next
two
months,
but
Jeff
did
you
have
a
quick
like
like
for
the
imports
file,
specify
our
proposal
that
you
can.
You
can
try
them
in
on
and
also
if
anyone
else
can
pick
up
on
notes
that
would
be
hopefull.
A
B
B
No,
yes,
I
understand
the
concern
about
the
CJ
s
interrupts.
So
if
right
right
now,
this
only
imports
comma
J
as
default
entry
points.
So
I
guess
there's
a
question
of.
If
we
want
to
allow
that,
regardless
of
whatever
happens
with
named
exports
for
CJ
s,
if
we
don't,
we
can
you
know
it
can
come
back
next
meeting
with
that
removed
or
we
could
merge
this
now
and
then
have
another
PR
to
remove
it
or
throw
a
fly
through
a
exception
or
something
for
it.
If.
A
I
can
suggest
something.
We
also
have
a
massive
conflict
that
I'm
trying
to
fix
on
that
branch.
I'd
like
on
modules
LKG
are
right
now,
anyways,
just
as
a
summary
on
this.
One
I
would
like
to
suggest
that
we
don't
push
moving
this
right
now,
because
I
think
it
should
be
reviewed
with
the
context
that
we
have,
but
perhaps
we
can
try
to
land
it
out-of-band
between
meetings.
We
just
have
consensus
that
if
by
next
Wednesday
a
week
from
now,
there's
no
objections
on
that
PR
we
can
land
it
out-of-band
from
the
meetings.
E
Behaviors
are
roughly
in
line
with
what
was
demoed
at
the
previous
meeting
one
there
in
a
few
changes.
One
of
the
changes
was
changing
to
the
the
type
specifier
in
the
package.json.
This
is
still
something
like
that.
Can
you
change?
It's
not.
You
know.
The
final
picture
was
still
kind
of
women
wanting
to
merge
things
in
without
necessarily
saying
that
we
fully
agreed
on
on
that
case,
but
for
now
it's
type
azzam
in
the
package.json.
E
B
If
I
get
to
make
one
other
point
is
just
in
general
for
people
as
we're
trying
to
try
to
make
these
deadlines.
It
really
helps
to
get
feedback
from
people.
You
know
earlier
than
like
the
morning
of
the
meeting
or
the
night
before
the
meeting.
I
understand.
Tc39
is
happening
and
a
lot
of
things
happened
really
suddenly
just
very
recently,
but
you
know
it's
hard
to
respond
to
feedback
right
before
we're
hoping
to
vote
on
things.
B
A
E
A
Okay,
can
you
give
us
I
guess
so
this
is
all
interconnected
with
itself,
then?
Can
you
give
a
high
overview
for
everyone,
one
more
time
about
what
the
semantics
are
of
this
and
then
perhaps
what
could
be
really
helpful
would
be,
since
we
kind
of
need
to
look
at
two
paths
right
now,
maybe
one
path
where
we
have
dynamic
modules
and
interrupts
and
one
path
where
we
don't
have
dynamic
and
modules,
and
perhaps
no
Interop
and
perhaps
a
third
path,
which
is
no
dynamic
modules
but
default.
E
So
the
the
first
PR
implements
what
I
demoed,
basically
with
the
type
field
in
the
package.json
and
common
today.
This
is
just
the
default
export,
so
you
get
the
whole
modular
and
exports
object,
snapshot
at
the
time
of
execution
and
that's
your
default
exports.
The
dynamic
modulus
variation
of
that
PR
adds
in
the
V
a
patched.
E
Implementation
of
dynamic
modules
builds
a
new
version
of
module
wrapper
around
it
and
basically
implements
dynamic
modules
in
node
to
provide
named
exports
for
common
gist
modules,
while
maintaining
the
exact
execution
invariants
of
yes
modules,
and
so
that's
that's
what
that
PR
does,
and
it
shows
the
behaviors
of
how
the
named
exports
work
out
with
that
and
we
get
to
replace
the
internal,
create
dynamic
module
JS
file
that
we
have.
That
kind
of
does
a
custom
wrapper
approach
to
do
this
kind
of
thing.
E
Currently,
so
the
semantics
of
dynamic
modules
I,
don't
want
to
dive
too
deep
into
that
now,
but
yeah,
basically
without
a
clear
green
light
on
dynamic
modules.
I,
don't
think
we
should
emerge,
that's
because
it
would
involve
a
sort
of
a
v8
patch
that,
as
I
mentioned
at
the
beginning
of
this
meeting,
will
then
be
out
of
sync
with
the
it
changes
upstream,
we're
effectively
poking
v8
to
some
degree.
So
it's.
A
Fine
for
us
to
land
on
our
fork
for
what
it's
worth,
I
think
that
it's
more
like
we
shouldn't
land
that,
if,
like
we
shouldn't,
be
up
streaming,
our
implementation
with
that
match.
It
is
more
like
where
I
would
kind
of
land
on
it.
So
I
think
like.
If
we
are.
If
we
are
hedging
on
betting,
that
in
March
we
will
be
able
to
get
something
that
will
be
palpable
to
people
and
we
want
to
move
forward
based
on
that
assumption,
I
think
it's
actually
fine
to
do
that.
A
The
thing
I'm
actually
more
interested
in
is
myself
and
I
will
be.
Very.
You
know
clear.
It's
my
time
to
be
the
bad
guy.
Sorry,
but
I
am
Not
sure
that
we
should
be
shipping
common,
J's,
Interop
supporter
for
only
exporting
the
default.
We
could
drag
that
out
in
a
future
meeting,
but
I
would
love
to
know
guy
what?
What
are
your
thoughts
about
how
this
proposal
exists
in
a
world
without.
A
Necessary
I
know
that
Brad
has
feelings
about
still
wanting
it,
because
it's
a
static
way
to
determine
from
the
package
what
kind
of
package
it
is
and
what
the
file
extension
should
be.
But
do
you
think
that
this
yourself
is
the
person
pushing
it?
Does
this
proposal
still
have
value?
Is
it
still
necessary
with
without
interoperability?
A
E
E
B
B
A
Okay,
excellent
I'll,
take
the
action
item
of
trying
to
collect
the
notes
from
today
and
put
together
like
I'll
review.
Both
are
phases
doc
and
try
to
put
together
some
sort
of
proposal
about
what
it
would
look
like
for
us
to
ship
something,
and
we
can
discuss
that
in
the
next
meeting
and
try
to
reach
consensus
around
it.
Even
if
we
don't
necessarily
know
what
it
is,
I'm
actually
feeling
the
most
confident
and
yeah
it's
kind
of
like
I
know
it.