►
From YouTube: Modules Team Meeting - 2019-10-09 - Part 2
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
Some
cooks
that
there's
nothing
to
see,
listen,
see
because
by
the
time
the
user
line
code
runs
and
attaches
the
core
promises
have
already
been
created
and
their
events
emits
it.
So
there's
a
PR
to
do
a
buffering,
but
there's
a
lot
of
questions
on
that
PR,
whether
it's
going
to
be
good
for
performance
or
if
it's
the
right
approach
or
what
the
right
architecture
is
to
make.
Async
hooks
work
with
an
asynchronous
bootstrap.
A
So
yeah
there
are
a
number
of
technical
issues
as
well
as
the
consensus
issues
that
we
need
to
consider
continue
discussing.
We're
very
close,
I
mean
it's
three
failing
tests
and
then
a
few
architectural
clings,
but
it
will
take
a
bit
of
work
to
get
there
I'm
having
a
discussion
with
James
and
Matteo
and
Monday,
and
also
trying
to
chart
with
other
core
people
about
working
towards
that.
But
it's
certainly
not
a
given
and
I
also
have
very
limited
time.
So
I
would
say
we're
about
technically
50/50
before
we
consider
consensus,
Salah.
B
Yeah,
so
definitely
a
string
booth
async
bootstrapping
is
you
know
like
it's
a
quite
a
mu
and
so
I
think
two
questions
are
important:
a
how
critical
like
what
are
the
critical
aspects
of
the
you
know,
implementation
of
Monte
that
required
going
a
sink
in
the
bootstrap.
You
know
I
can't
you
know.
If
we
say
we
don't
have
a
facing
bootstrapping.
B
What
would
break
and
the
other
thing
is
I
guess.
Is
there
other
places
than
module
work
where
a
solute
strapping
had
been
something
they
would
want
to
reach
so
I'm
just
trying
to
understand.
You
know
how
important
going
async
and
bootstrapping
is
or
what
what
caused
it
to
be
of
such
importance
if
there
are
other
important
application,
cord
being
a
thing
other
than
just
modules,
Thanks.
A
Right
in
theory,
there
should
be
other
benefits
to
know
Jer
score
being
in
sync.
Just
traditionally
no
Jess
call
bootstrap
has
always
been
synchronous,
commentaries
to
run
synchronously.
If
there's
an
error,
it's
all
in
a
in
a
synchronous
execution
before
bailing
out
at
the
top
level,
so
making
it
asynchronous.
This
modules
is
the
first
time
that
there's
been
a
driver
need
to
make
note
core
a
synchronous.
In
theory,
modules
could
be
done
synchronously,
but
I
think,
especially
with
top-level
await
and
things
like
that.
The
whole
whole
pipeline
is
an
asynchronous
pipeline.
A
I,
don't
think
it's
the
solution
to
try
on
da
sync,
if
I
it,
although
maybe
there's
things
we
can
do
around
the
code
and
Wesley
I
mean
you
were
looking
into
that
sort
of
stuff.
With
the
event
loops
I
mean,
if
you
have
any
ideas,
how
we
can,
for
example,
ensure
that
the
promise
resolved
queue
is
entirely
cleared
and
that
error
handlers
that
could
come
out
in
a
catch
Damon
don't
shift
their
stack.
It
I
mean
that
there's
like
one
two
of
the
basic
issues
which
in
theory
probably
have
simple
fixes,
but
it's
just
getting.
B
B
A
Right
so
West
was
just
saying
that
you
could
spin
the
event
loop
without
activating
the
micro
task
queue.
It's
may
be
those
kinds
of
tricks
that
we
maybe
need
to
investigate
to
fix
that
one
failure.
If
anyone
is
interested
or
has
people
that
they're
able
to
get
on
this
PR
in
in
their
organizations,
that
would
be
a
huge
help,
because
I'm
personally
can't
put
more
full-time
days
into
this
myself.
Yeah
I
think.
D
A
So
there's
kind
of
a
phase.
We
have
the
point
of
synchronous.
Execution
execution
is
still
synchronous
when
you
reach
that
point,
but
we
just
need
to
make
sure
that
the
task
queue
is
exactly
running
and
node
has
this
custom
task
queue
as
well?
That
maybe
needs
a
bit
of
manipulation
so
that
it
exactly
gets
the
same
timing.
The
problem
is
actually
like
promises
created
in
user
code
are
being
flushed
slightly
earlier
than
they
should
have
relative
to
other
set
immediate
callbacks,
and
then
that's
in
the
test
case.
A
I
can
point
to
the
exact
it's
like
one
test,
but
it
captures
that
task
queue
issue
so
yeah
as
I
say.
If
anyone
knows
anyone
who's
able
to
clone
that
PR
and
and
have
a
look
at
this
timing
stuff
for
this,
this
error
stack
stuff,
I'm
more
than
happy
to
advise
but
yeah.
If
we
can't
get
that,
let
alone
the
ACE
and
cook
stuff,
then
unfortunately,
it's
not
looking
good,
so
I'm
flag
this
month,
in
which
case
I,
think
we're
probably
looking
at
nine
thirteen
at
the
the
rate
of
current.
E
I
asked
miles
about
that
and
technically
we
don't
need
to
necessarily
get
that
merged
in
this
month
in
order
to
unflagging
LTI
and
12.
But
there's
also
not
that
much
precedent
for
unflagging
in
like
a
major
feature
line
after
it's
been
declared
LTS.
So
so
there
might
be
some
wiggle
room,
but
it's
kind
of
up
to
the
the
whims
of
the
core
folks,
I
guess,
whatever
make
that
decision
right.
E
D
Yeah,
so
I
don't
think
we
have
consensus.
I,
think
I
agree
with
Jordan
if
I'm.
If
I
read
between
the
lines,
what
he
said
earlier,
that
moving
things
between
stages
is
fine,
but
using
that
as
a
implicit
consensus
that
oh
yeah
once
the
tests
are
fixed.
We
definitely
know
that
the
version
of
modules
as
it
is
currently
in
core
can
land
in
between
meetings
without
further
discussion.
I
think
we
should
make
a
very
conscious
decision
of
saying.
D
E
Okay,
I
mean
that's
fair
now.
Is
that
saying,
like
you
know
the
current
PR
once
he
gets
the
tests
passing
like
you,
want
to
take
another
look
and
see
like
any
changes
as
a
result
of
getting
those
tests
to
pass.
You
want
like
to
be
able
to
take
a
look
at
another
pass
to
see
like
well.
If
any
of
those
changes
were
meaningful
and
therefore
like,
oh,
maybe
we
should
really
like
consider
this
a
little
bit
more
or
because
I
think
there's
a
difference
between
that
and
saying
like.
E
Oh,
we
can't
in
flag
until
feature
X's
bill
like
loaders
are
built
or
something
like
that
where
it's
like.
Okay,
we
know
we're,
not
gonna,
be
ready.
You
know
in
the
next
two
weeks.
So
therefore
it's
like
that's
the
understanding
where
you
know
working
whether
you
know
what
I
mean
is
it?
Is
it
one
or
the
other
of
those
or
is
it
something
else?
I.
F
F
For
me,
the
thing
that
continues
to
be
to
hang
up
like
despite
my
opinions
on
things
like
resolution
and
extensions
and
stuff
like
that,
like
it's
really
the
use
cases
that
I've
been
concerned
about
and
I've
repeatedly
said,
which
is
that
there's
two
kinds
of
compatibility
I
want
I
want
to
be
able
to
have
a
package
that
works
in
pre
module,
node
and
post
module
node.
Both
it
I
had
a
conversation
with
miles
last
week
that
convinced
me
that,
as
long
as
exports
ships
at
the
same
time
as
GSM,
they
both
are
on
flag.
F
At
the
same
time,
then,
that's
actually
achievable
because
you
can
use
the
export
dot
and
the
main
thing
to
kind
of
implicitly
get
a
module,
no
module,
pivot,
right
and
so
fair
that
works.
But
then
the
other
kind
of
compatibility,
I,
think
is
important.
Is
that
I
want
to
be
able
to
have
like
to
make
doing
that
which
is
transparently
switching
between
the
ESM
or
the
CJS
implementation,
depending
on
which
version
of
node
you're
in
right?
So
that's
possible
there
cool.
F
As
long
as
the
use
case
can
be
met
and
so
I'm
open
to
suggestions
and
like
I,
think
it's
it's
unfortunate
that
I
don't
have
the
skillset
or
the
time
to
make
PRS
and
write
code
to
explore
solutions.
But
I
also
think
that
this
is
something
that's
and
the
use
cases
are
important
enough.
That
I
hope
they're
not
held
up
by
whoever
has
the
privilege
of
having
the
time
and
ability
to
implement
things.
F
You
know
just
not
being
able
to
implement
the
use
cases
I'm
interested
in
so
that's
kind
of
my
like,
like
I,
don't
you
know
I
don't
want
to,
and
only
anyone
once
to
have
the
perception
of
being
a
blocker
of
like
being
the
lone
voice.
You
know
disrupting
in
progress
and
like,
but
I
think
that
I
hope
that
we
all
consider
the
the
effect
it
will
have
like
either
it's
like.
F
If
we,
if
we
unflagged
now,
what
I
suspect
will
happen
is
that
many
packages
will
not
know
that
it's
a
sin
per
major
change
to
use
the
SM.
That
will
cause
a
lot
of
ecosystem
churn.
The
ones
that
know
will
be
a
breaking
change,
which
will
still
cause
ecosystem
churn
and
will
prevent
new
bug,
fixes
and
security
fixes
and
new
features
from
landing
in
things
that
support
old
versions
of
node,
including
versions
of
node
that
are
still
under
LTS
and
or
in
another
alternative,
is
that
people
won't
switch.
F
The
ESM
and
I
think
that's
just
as
much
of
a
tragedy,
so
like
I'm,
I
I'm,
not
sitting
here
with
a
like
here's.
A
pull
request
like
to
look
at
but
I
think
that
it's
really
important
that
we
come
up
with
the
solution
for
those
use
cases
and
I
think
it
would
be
a
huge
loss
if
we
unflagged
without
that.
D
Can
write
but
I
have
a
follow-up
for
that?
Oh
you
can
you
can
go
first,
if
you
had
your
first
yeah
I.
Think
the
the
quick
note
I'll
have
is
I
think
we
have
a
fundamental
decision
point
between
if
the
same
specifier
can
be
required
and
imported.
Is
it
okay?
If
that
will
then
get
the
common
jazz
implementation,
or
do
we
care
more
about
Singleton's
and
the
fact
that
it
is
generally
safer
in
terms
of
implementation
choices
of
the
package
itself.
D
Yeah
and
we
well,
no
opposite:
we
don't
care
as
much
about
that
and
we
can
allow
that
it
gets
the
ESM
or
the
common
jazz
implementation
depending
on
the
import
side.
I
think
totally
agree.
Yeah,
that's
a
very
important
decision.
Point
I
I
think
we
wanted
to
make
that
decision
in
the
past.
By
saying
that
resolution
should
be
always.
D
D
F
It's
still
like
I
see
that
the
bugs
people
run
into
because
of
this
I
see
as
a
correct
earlier
indication
that
you've
architected
incorrectly
and
that
you
need
to
fix
it
or
you're
gonna,
run
into
problems
later
so
I'm
completely
comfortable
with
just
us
deciding
that
hazards.
Okay,
let's
document
it
it
well
and
focus
on
education
and
I.
E
E
I
think
what
we've
determined
is
that
there
are
going
to
be
people
that
are
just
never
gonna,
be
okay
with
just
accepting
the
habits.
Hazard
is
okay
and,
like
the
users
will
deal
with
it
like
miles,
is
firmly
opposed
to
that,
and
that's
I
mean
if
that's
gonna,
be
that's
just
a
blocker
for
many
people
and
so
that
a
if,
if
that
becomes
like
an
irreconcilable
difference
between
you
saying
we
have
to
allow
it
and
then
saying
that's
too
dangerous,
like
I,
think
the
solution
that
can
find
consensus
is
require
VSM,
as
we've
discussed.
E
That's
not
gonna
happen
before
LTS
a
12.
Clearly,
so
you
know,
and
if
we
allow
this
hazard
that
might
I
feel
like
might
prevent,
require
me
Sam,
but
I,
don't
know.
Someone
could
correct
me
on
that.
I
think
those
other
issues
you
discussed
Jordan
of,
like
you
know
it
would
be
a
shame
if
we
release
this
and
people
can't
do
x.
E
Y&Amp;Z
yeah
I
mean
that
it's
a
shame
to
release
it
without
loaders
I
mean
I'm
up,
but
all
these
other
things
like
I
would
like
to
release
it
with
require
BSM
or
a
solution
for
what
you're
describing
etc.
But
I
also
feel
like
there
is
a
real
cost
in
like
just
kicking
this
down
the
road
for
another
year
year
and
a
half
or
whatever
note.
14
goes
LTS
and
I
think
that
that
consequence
is
like
jdd
zsm
becoming
even
more
than
the
de
facto
standard.
E
It
already
is,
and
more
people
not
using
the
SM,
syntax
and
node,
and
more
fragmentation
and
more
build
tools
and
I,
don't
think
that's
at
all
good,
either
like
being
able
to
use
the
same.
Bear
specifier
into
module
systems
feels
relatively
minor
to
me,
and
that
could
be
something
we
ship
as
a
as
an
improvement
like
in
a
later
minor
release
at
12,
you
know
or
require
VSM.
We
can
certainly
ship
in
14
I'm.
E
F
I
wonder
if
there's
like
there's
something
we
could
do
with
like
currently,
exports
is
just
like
an
import
map
kind
of
it's
like
a
mapping
of
left-hand-side
specifiers,
to
which
file.
Does
that
mean
and
there's
like
some
scopes
and
stuff
I
think
but
like
the
after
refresh
my
memory
on
it,
but
the
I'm
wondering
if,
if
there's
a
way,
we
could
with
lower
and
effort,
come
up
with
a
solution
that
says
we're
like
by
default.
Having
this,
you
know
the
same
specifier
can't
I,
don't
know
something
we're
like
you
can't
require
ESM
right
now.
F
It
froze,
but
there's
something
we
could
do
in
the
exports
map.
That
would
allow
require
of
that
ESM
file.
To
do
something
like
you
could
wear,
you
could
explicitly
opt
into
saying
yeah,
it's
cool.
This
is
not
stateful
or
you
could
say
this
is
stateful.
So
go
to
this
shared
stateful
thing
or
you
know,
I,
don't
know
like
something
like
that.
F
E
I
mean
there's
a
there,
one
of
the
other,
the
only
other
likes
or
I.
Guess
it's
not
quite
the
same
solution,
but
there's
a
there's,
a
proposal
that
I
made
for
the
issue
about
not
having
named
exports
out
of
common
Jas,
which
was
I,
was
just
like.
Well,
we
can't
get
any
other
effin
solution
to
work
like
dynamic
modules,
and
you
know
all
the
various
things
people
have
tried.
So
I
was
like
just
spent
just
to
find
them
in
damn
packages.
Jason
like
yeah.
E
F
But
I
mean
proposal
what
I
like
about
that
is
that
it
there's
a
difference
between
shipping
now
with
a
feature,
a
use
case
being
impossible
and
saying
we're
gonna
open
up
that
use
case
later
and
shipping
now,
with
a
use
case
being
annoying
but
possible
and
then
saying
we're
gonna
make
it
less
annoying
later,
like
I
I
feel
like
the
latter
approach
is
far
better
for
the
ecosystem,
because
people
will
just
make
tools
to
automate
the
annoying
part
and
then,
when
we
fix
that,
then
great
they
can
drop
those
tools.
But
like
the.
A
E
I
think
I
think
I'm
done
so
we'll
wait,
I
think
the
consensus
where
I'm
hearing
is
we'll
wait
for
the
PR,
the
unflagging
PR
to
actually
be
ready
to
be
merged
in,
like
it
passes
all
the
tests
and
then
we'll.
Let
me
discuss
this
at
the
next
meeting.
Is
that
we
have.
We
all
agree
on
that
and
then
they.
B
F
E
Same
thing,
I
guess,
Jordan.
Please,
look
at
that
PR
anyone
else.
Please
look
at
the
PR
about
the
roadmap.
I
think
it
correlates
with
what
I
just
described
about
waiting
for
the
Jew
unflagging
PRS.
If
you
want
me
to
change
the
wording
of
like
after
unflagging
to
something
else
by
all
means
suggest
something
and
we
can
make
changes
and
just
land
it,
but
I
think
it
reflects
essentially
where
we,
where
we
are.
E
A
Okay,
great
thanks.
The
next
item
we
had
was
the
JSON
modules
on
the
web.
I
don't
want
to
go
too
deep
into
this
one
since
we're
already
running
out
of
time,
but
because
Jason
monteux's
have
actually
been
removed
from
HTML,
we're
now
and
they're,
based
on
a
security
argument,
and
there
are
potentially
other
types
of
syntax
that
are
being
proposed
for
importing
JSON.
A
So
the
concern
is
that
if
we
shift
JSON
and
then
the
web
does
import
Kasaan
as
JSON
or
something
like
that,
that's
kind
of
a
semantical
semantic
import,
then
we
might
be
in
a
situation
where
we've,
you
know,
created
a
compatibility
issue.
So
the
the
suggestion
was
to
reef
flag
in
node.
If
anyone
has
any
strong
objections
to
that
or
any
opinions
on
that,
either
way,
if
used
to
show
your
opinions
as
I
said,
I
prefer
not
to
get
too
too
deep
into
this
one.
Now,
if
possible.
Ideally,
we
can
move
on
fairly
quickly.
A
D
So
click
the
wrong
button,
but
meant
to
raise
my
hand
I
I,
think
unflagging
right
now
is
relatively
cheap.
Flagging
right
now
was
relatively
cheap,
so
I
think
we
can
relatively
safely
err
on
the
side
of
safety
and
just
bring
the
flag
back,
and
then
we
can
hopefully
still
on
flag.
As
soon
as
the
dust
has
settled.
A
This
hazard
protection,
which
was
effectively
throwing
when
you
load
a
JS
file
from
common
J's
inside
a
type
module
package,
and
when
that
went
out,
we
had
a
bug
report
by
Fedor
that
liked
it
es
Lindo
J's
wasn't
working
in
there
type
module
package,
and
it's
worth
bearing
in
mind
that
since
we've
been
documenting
type
module,
when
we
first
came
up
with
side
module,
there
was
like
no
one
using
it.
Now.
People
are
shipping
it
and
using
it
already
so
like
we
already
have
compatibility
constants
out
of
our
own
documentation
efforts.
A
Unfortunately,
maybe
we
should
just
kept
quiet,
but
anyway,
so
we're
now
in
this
sort
of
interim
period,
where
people
are
already
something's
used
it,
and
then
we
ship
behaviors
that
break
things
and
the
example
is
you've,
got
your
Bible
configs
you've
got
all
these
other
things
and
most
of
those
configuration
systems
load
their
config
with
a
require
statement
or
something
internally,
and
now
all
your
tools
break
so
upgrading
to
modules.
Isn't
you
add
a
field
to
a
package.json?
A
And
now
suddenly,
all
your
tooling
breaks
I
mean
of
course
not
typescript,
because
it
uses
JSON,
but
everything
else
breaks.
So
that's
one
example
and
there
might
be
other
ways
that
this
this
thing
bites
so
for
now,
we've
disabled
it,
but
we
do
have
to
consider
what
we
want
to
do.
I
did
post
one
PR
up
to
node
core
I'll
just
get
the
link
very
quickly,
which
was
basically
taking
in
the
opposite
direction.
To
say
you
know
what
do
we
have
to
restrict
comment
just
as
much?
A
Maybe
we
can
just
let
the
common
choice
require
still
require
things,
and
even
even
when
it
is
the
hazard,
but
because
of
the
fact
that
the
only
module
Stickles
that'll
hit
the
case
where
you've
got
two
different
instances.
Our
modules
that
use
neither
require
syntax
norm,
export
syntax
so
that
the
has
it
might
be
a
small
enough
subset,
or
you
know
that
union
of
of
that
she
might
be
a
small
enough
subset
that
we
could
allow
it,
and
that
also
kind
of
ties
in
to
Jordan's
point.
A
Just
now
we're
you
saying
what
could
we
just
let
require
work,
this
kind
of
does
that
it
just
allows
required
to
work
out
for
common.
Just
assume
you
don't
try
to
change
common
gist,
we
say:
well,
it
can
still
eat
the
world
that
wants
to
require
XE
file
it
can.
It
wants
to
require
a
J's
file
and
a
type
module
it
can.
But
what
we're
controlling
is
the
is
module
semantics
in
the
it's
modulator
I
know.
Wesley
has
very
strong
opinions
on
this
topic
as
well.
C
I
mean,
like
my
pots:
that's
simply
that,
like
big,
so
like
the
problem
was
never
looked
like
the
from
the
resolver
standpoint.
The
problem
was
never
really
from
the
ESM
side,
because
the
ESM
side
is
already
so
heavily
limited,
where
it
can
only
like
import
things
that
are
exact
has
anyway,
like
it
was
always
the
behavior
of
the
common
je
s
was
already
and
so
like
walking
it
back
in
saying
the
competence
was
Oliver
can
require.
Jsc
is
undoing
pretty
much
everything
that
we
talked
about
when
we
were
discussing
to
the
type
module
of
field.
C
Oh
here
then,
like
the
change
in
the
SM
of
like
throwing
or
not
like
the
reason,
the
type
module
field
exists
at
all
is
to
prevent
this
problem
from
happening,
so
the
CJS
loader
can
throw.
Otherwise.
You
have
no
need
to
use
the
type
module
field
because
you
can
just
say
well
the
CGS
loader
loads
things.
Yes,
yes
mo
devotes
things
dsm,
rug,.
A
B
I'm,
basically
thinking
along
the
lines
of
create
a
legacy
you
require
function
or
require
dot
legacy.
If
people
want
to
use
require
with
resolution
that
is
separate
from
ESM,
and
you
don't
want
to
create
this
as
a
contentious
alternative
run
time,
flag
or
setting,
we
can
just
make
a
require
function
that
works,
but
is
discouraged
and
not
meant
to
be
used
as
an
alternative
to
the
normal,
require
it's
just
fused
by
two.
Oh,
that's!
That's.
C
Actually
not
a
problem,
they
can
already
do
that
and
in
fact
it
was
like
a
patch
put
up
for
yes,
lint
Beck,
just
you
know,
read
the
file
and
then
freshy
valve
in
anyway,
because
they
don't
actually
use
real
require.
They
use
fresh
if
you
first
import
package
to
get
a
new
copy
every
time,
and
that
was
my
PR
yeah.
C
The
point
isn't,
but
it
could
already
be
done.
It
can
already
be
worked
around
with
new
code.
The
only
concern
is
well
existing
code.
People
already
started
adopting
type
module
before
we
shipped
it,
and
so,
like
existing
code,
that
air
quotes
works
is
already
using
an
experimental
flag
and
is
breaking
the
platicas
people's
package.
It's
on
when
you
started
using
it,
you
opted
into
being
broken
because
we
haven't
ship.
The
finished
feature
yet.
E
E
And
there's
not
that
many
of
them
they
can
look
at
the
ESM
NPR
and
do
the
same
thing.
It's
not
that
big
a
deal.
You
know
as
far
as
your
point
that
I
wanted
to
respond
to
you
about
like
how
does
the
tool
know
how
to
interpret
a
file
that
I
don't
think
that
really
exists
yet
like
right
now
in
node
until
will
be
until
we
a
DSM
like
they
all,
they
know
it
all
jazz
files
or
common
JavaScript
files.
You
know
what
I
mean
no.
C
That's
actually,
that's
actually
not
true
at
all
see.
The
issue
here
is,
if
I
see
today
before
node
ships
modules
a
j/s
file
in
the
package,
I
heuristic
lis,
guess,
whether
it's
a
common
J's
file
or
an
es
M
file
that
needs
to
be
transpiled
and
I
do
that
by
looking
at
syntax
and
people
have
come
to
the
conclusion
over
the
last
three
years
that
that's
a
terrible
solution
and
no
one
wants
to
encode
that
solution
as
a
standard.
C
So
we're
trying
to
look
beyond
that
and
find
a
different
answer
here
and
that's
why
we
have
type
module
and
extension
based
module
format,
detection
and
so
the
ideal
there
is,
we
say
all
right.
Well,
that
means
that
J
is
in
a
node
package,
means
that
it
is
just
a
comedy
s
file
and
will
always
be
a
common
J's
file
unless
there's
something
indicating
otherwise
and
that's
something
indicating
otherwise
would
either
be
a
different
extension
of
andreas
extension.
That's
why
that
exists
or
the
time
module
field
which
changes
the
interpretation
of
those
extensions.
C
This
way,
we
don't
need
to
look
at
syntax
at
all.
Now,
when
you
make
it
so
require.
Can
just
require
arbitrary
files
as
ESM.
That
means
that
these
formats
are
no
longer
strong.
They
mean
that
I
can
have
this
file
that
might
be
loaded
as
common
as
es
m
or
as
common
jazz
and
yes,
I
could
theoretically
load
an
arbitrary
string
as
common
GS
or
GSM,
but
the
entire
thing
that
matters
is
the
intense
like
do.
E
F
A
F
C
More
importantly,
that
doesn't
change
anything
to
do
with
the
current,
like
adding
type
module,
and
it's
common
to
us
resolve
our
behavior
like
breaks.
People
who
are
already
using
type
module
like
that
still
requires
people
to
write
new
code
to
change
things,
which
is
exactly
what
we're
talking
about,
avoiding
and
like
I'm,
simply
here
trying
to
make
the
argument
that
they
propped
it
in
the
tight
module
and
we
break
you.
That's
fine,
because
you
opted
in
to
type
module.
C
E
A
D
Wes
is
preaching
to
the
choir
I.
Don't
think
that
people
really
believe
that
being
able
to
opt
out
of
type
module
for
common
GS
files
is
the
thing
that
exists
should
exist
also
exists
longer
term.
It
is
more
a.
How
do
we
deal
with
the
intermediate
term
fallout
of
actually
enforcing
it
and
I
think
multiple
people
have
made
a
very
good
case
that
maybe
the
shock
of
this
first
breakage
was
enough
for
petula
authors
to
support
the
CGS
for
their
files,
because
as
soon
as
tools
supported
CGS,
we
are
good.
D
People
can
just
use
es
Lindauer
seed
of
CGS
and
everything's.
Fine
and
people
who
are
using
type
module
already
should
be
on
the
edge
enough
that
they
are
able
to
update
to
the
latest
version
of
you
slant
and
I.
Think
if
we
have
that
in
place,
there
really
isn't
much
of
a
reason
to
not
try
again
to
either
bring
back
the
exception,
or
at
least
not
a
very
big
deprecation
message
or
whatever
it
is,
and
then
longer
term.
D
A
E
C
Yet
we
haven't
ship
modules.
Yet
even
and
we
are
now
admitting
deprecation
warnings,
because
we
know
what
people
are
doing,
will
error
in
the
future
and
we're
warning
them
about
that.
That's
fine
to
me,
however,
shipping,
a
version
of
type
module
and
it
is
a
different
version
of
it
that
emits
a
temptation
warning
rather
than
the
heart
error,
is
an
environment
that
is
like
a
different
and
third
environment
like
it's
different
than
CGS
today,
and
it's
different
than
type
module
with
a
heart
error
and
playing
tools
will
have
to
support
that
environment
as
well.
A
Now,
given
the
limits
of
time,
we
have
what,
if
we
try
the
shipping,
the
deprecation
again
separate,
like
now
like
we
did
before,
but
as
as
a
duplication,
warning
with
suitable
context
and
information
to
use
a
service,
not
just
what
like
it
was
before.
Error
require
ism
and,
and
it
wasn't
it
very
clear,
we
allow
it
to
work,
but
we
ship
with
the
deprecation
already
now.
C
A
Okay,
let's
move
on
where
we
still
have
time.
I'm
gonna
skip
over
later
hooks
on
the
agenda.
If
you
don't
mind,
unless
anyone
has
anything
important
to
add
on
that
which
brings
us
to
Young's
pre
PR
to
like
package
relative
specifiers
he's
had
the
PR
for
a
while
I
believe,
there's
still
some
debate
over
the
symbol,
Devon
govern
and
parcel
was
saying
that
quite
likes.
The
tilde
and.
A
At
the
moment,
the
PR
uses
the
at
symbol,
so
it
seems
like
the
consensus
issue
is
actually
just
over
the
symbol
at
this
point
and
whatever
we
like,
even
if
Devon
suggested
the
till
do
whatever
consensus
we
have
is
obviously
the
consensus
we
move
forward.
So
we
just
need
to
make
sure
that
we
ourselves
agree.
Sorry
Alex,
just
added
there.
That
loader
has
the
de
provided
the
PR
to
rename
loaded
to
experimental
loader
for
now
on
on
the
loader
topic,
but
on
the
package
relative
topic,
who
wants
technical
discussion
where
the
young.
F
Yeah
I
mean
so
the
this.
The
primary
debate
was.
We
originally
went
with
tilde,
because
that's
what
literally
everything
in
the
ecosystem
that
wants
this
use
case
does.
But
then
there
was
an
objection
from
not
even
just
I.
Think
Gus
was
original
one
but
like
I,
think
at
least
one
other
person
echoed
it
that,
because
of
the
conceptual
overlap
with
the
users
home
directory
in
like
a
POSIX
shell,
that
they
didn't
want
til
to
go
through,
and
we
kind
of
settled
on
at
and
like
I'm
guess,
I'm
a
little
confused.
F
Why
we
don't
just
go
ahead
and
do
that
like
mainly
because
like
if
those
are
the
two
choices
and
no
one
has
a
hard
objection
to
one
of
them,
then
that's
the
one
we
should
pick
and
as
much
as
I'd
prefer
tilde,
because
that's
what
everyone
uses
like
that's
fine,
like
I,
want
the
feature:
let's
just
ship
it.
So
there.
A
A
A
A
E
A
E
F
Well,
it
sounds
like,
though,
like
if
we
can
maybe
right
now
agree
that
tilde
or
at
is
okay
as
long
as
node
collaborators,
which
includes
Gus
and
Matteo,
can
agree,
then
that's
modules,
group
consensus
and
then,
if
we
could
recommend
strongly
that
the
TSC
just
vote
and
pick
one
in
you
know,
then
great.
That
should
be
the
plan
and
then
Gus
in
Matteo
and
whoever
else
can
battle
that
out
in
the
TSC
meeting
or
we
don't
have
to
be
involved.
E
F
A
Okay,
which
brings
us
to
the
last
agenda
item,
which
is
I
posted
a
PR
to
unflagging
experimental
exports
when
we
originally
shipped
exports,
its
ship
behind
experimental
modules
and
behind
its
own
experimental
exports
flag,
leading
up
to
what
you
know,
requirements
to
think
about
unflagging
modules.
I
think
it
is
important
that
exports
goes
along
with
it.
So
to
me
this
was
like
one
of
the
prerequisite
PRS
to
the
unflagging
modules
PR.
We
don't
need
to
land
it
now,
but
I
like
at
some
point.
We
need
to
learn
and
get
through
because
I
can't
get.
A
We
can't
get
an
unflagging
PR,
and
so
we've
got
that
we
don't
want
them
flying
in
PR
to
land
and
then
separately
do
the
exports
unflagging
and
then
we've
got
a
potential
gap,
so
I
just
wanted
to
find
out.
If
there's
any,
you
know
what
the
objections
are
to
removing
that
flag
or
where
export
should
be
before
we
consider
that
it
can
just
be
a
base.
Little
feature
of
experimental
modules,
young.
D
I
think
the
short
answer
for
me
is
in
the
past:
I
preferred
having
exports
only
land
after
self-references,
now
I
think
that
it's
fine
to
land
it,
as
is
given
that
set
preference.
This
seemed
like
something
it
will
follow
resolution
or
tea
after
because
this
doesn't
seem
to
be
any
fundamental
objections
to
it.
B
B
Lowered
my
hand
first
now,
I'm
gonna
talk,
sorry
I'm,
just
a
quick
question,
because
I'm
not
caught
up
on
the
details
at
some
point,
we'll
wonder
about
the
old
mode
in
the
future.
When,
when
people
have
both,
they
might
actually
want
that
feature
more
than
ever.
So
so,
just
if
we
do
unplug
exports,
I'm
pretty
sure,
there's
a
lot
more
thinking
to
it.
B
A
B
D
Right
I
mean
I
meant
guys
answer
with.
We
don't
have
a
specific
implementation
for
conditional
exports,
but
we
do
have
the
wiring
with
the
arrays
right
now
that
we
could
introduce
conditionals
inside
of
exports.
So
we
could
implement
something
where
it
says.
If
one
of
the
array
elements
has
format
in
a
specific
way,
then
we
would
use
that
only
for
comment.
Yes,
it's
not
planned
right.
F
B
F
A
few
minutes,
late,
Jordan
yeah,
just
wanted
to
say,
like
so
I,
think
I
would
be
very
ecstatic
if
exports
could
be
unflagging
go
out
immediately.
That
said,
based
on
my
conversation
with
Myles
last
week,
that's
the
only
way
I
know
of
to
do
pre
module
and
post
module.
Node
do
duality.
So
if
that,
if
exports
gets
unflagged
first,
even
though
it
should
have
no
correlation,
I
would
be
then
very
concerned
that
there
is
no
way
to
do
that
when
modules
on
flags.
In
a
different
note
version
company.
F
E
A
I
mean
look
another
way
we
could
spend.
This
is
to
actually
merge
the
experimental
exports
unflagging
with
the
experimental
modules
unflagging
so
that
they
just
become
one
PR.
I
was
trying
to
avoid
so
that
we
could
write
them
separately,
but
if
we're
happy
to
do
them
all
together,
I
think
it's
a
non-issue.
I.
E
Mean
it
sounds
like
we
don't
have
any
objections
to
exports,
so,
although
there
might
be
people
who
don't
want
to
be
released
until
models
is
released
so
feel
like
we
might
as
well
merge
in
or
you
could
ask,
does
anyone
objects,
exports
and
assuming
there's
not,
then
we
just
merge
them
together.
Sure.
A
F
I,
just
like
I
do
not
object.
I
think
we
should
do
that,
but
I
want
to
make
sure
that
that
we
have
some
sort
of
explicitly
noted
caveat
that
if
we
come
up
with
a
way
to
do
pre
node
posts,
node
duality
that
does
not
require
exports
at
that
point,
I
would
immediately
prefer
to
see
I
export
son
flag,
didn't
CJ
s
like
that
should
like
to
me.
F
A
Great
we've
had
time,
so
we
can
note
that
resolution
and
we
can
get
that
merged
and
yeah.
Thank
you
so
much
everyone
for
listening
to
each
other,
and
hopefully
we
can
continue
to
make
progress
well.
So
if
anyone
has
any
headcount
to
put
on
this
unflagging
PR,
please
let
me
know
it's
quite
a
patient
thing.
I
think
all
your
luvin.