►
From YouTube: Node.js Foundation Modules Team Meeting 2019-05-22
Description
A
Hello,
we
are
live
with
the
May
22nd
meeting
of
the
noches
modules
team
and
joined
by
a
bunch
of
other
people
who
all
like
modules
and
have
spent
way
too
much
time
thinking
about
this
stuff.
So
we've
got
a
jam-packed
agenda
today,
as
we
usually
do
just
digging
that
up
and
I'll
drop
it
into
the
chat
with
someone
from
the
team
be
willing
to
help
with
taking
notes
today.
As
always,
please
do
not
all
volunteer
at
once.
A
B
B
All
right
people
see
this
all
right,
so
yeah
so
create
require,
got
merged
in
I,
asked
Myles.
If
this
was
like
what
he
had
in
mind
for
a
better
require
function,
and
he
said
yes,
so
I
just
moved.
That's
so
I
put
it
under
a
new
heading
called
done
everything
else.
That
was
that
we're
still
noodling
on
I
just
put
under
in
progress.
This
was
like
the
full
list
before
and
then
these
two
have
at
least
one
block
by
people.
B
No
one's
explicitly
blocked
anything
in
them,
so
they're
just
kind
of
in
progress
until
you
know
until
they
either
land
or
until
someone
blocks
on
so
that's
kind
of
what
I
was
thinking
with
this
and
I
can't
see
anything
that
anyone's
chatting.
So
if
there's
anything
else
that
people
want
to
address
speak
up.
A
C
I
guess
I
feel
that
so
I'm
not
super
stoked
on
the
stalled
section.
I
feel
like
that's
still
in
progress.
I,
like
I,
haven't,
had
a
chance
to
look
through
all
the
in
progress
items,
but
like
I,
hear
that
there's
at
least
one
block,
that's
an
interesting
categorization
method,
but
I
don't
know
if
that's
useful
I
think
it's
still
in
progress.
I
think
things
are
either
in
progress
or
we're
not
gonna.
A
Be
in
progress
so
I
think
that
the
difference
here
and
then
Jeff
you
can
correct
me
if
I'm
wrong
was
that
we
have
previously
had
a
section
called
needs
consensus
that
was
like
the
two
different
categories
were
things
we
had.
Consensus
on
that
were
being
implemented.
Create
require
was
like
a
good
example
of
that
versus
things
that,
like
we're
still
working
through
the
consensus
process
and
I,
think
that
it's
maybe
fair
to
say
that
you
know
looking
at
this
like
a
reference
package
route
by
a
package
name
is
something
that
well
we're
not
actively
blocking.
A
C
C
We
there's
like
lots
of
different
meanings
for
these
things,
but
and
I'm,
maybe
I'm
just
reacting
to
the
connotation
of
the
word
stalled,
but
I
just
don't
know
how
much,
if
that
I
don't
see
that
as
adding
value
and
I
see
it
as
actually
reducing
value
because
it
Prime's
people
to
think
a
certain
way
about
an
unresolved
discussion.
So.
A
C
B
B
It
describes
so
I
think
it's
useful
both
to
set
expectations
to
people
outside
of
our
groups
like
this
is
what's
going
on
inside
the
group
and
also
to
make
sure
that
within
the
group,
we're
all
on
the
same
page,
that,
like
at
the
moment,
I'm
assuming
that,
unless
something
dramatic
changes,
these
two
installed
aren't
going
to
ship
like
what
we've
got
now.
The
status
quo
for
both
of.
C
A
C
A
C
A
A
May
be
useful
for
us
to
maintain
an
abandoned
list,
not
that
we're
doing
that
now,
because
up
until
now,
we
haven't
really
been
abandoning
too
many
things.
We've
been
mostly
punting
them
to
later
in
the
process,
but
now
is
like
when
we're
probably
going
to
be
choosing
if
certain
things
aren't
going
to
land,
and
it
would
be
good,
like
a
historical
record
perspective,
to
keep
this
stuff,
we
didn't
do
well
and.
A
B
B
B
A
A
B
A
D
It's
great
to
finally
be
able
to
discuss
this
one.
This
is
a
long-standing
problem
in
in
the
JavaScript
module
system
is
if
you've
got
a
package
and
you
want
to
look
at
another
module
in
the
same
package.
You're
always
gonna
have
to
backtrack.
If
it's
not
same
folder,
and
then
you
have
to
know
how
far
to
backtrack,
and
if
you
move
modules
around
you
have
to
rewrite
all
those
imports.
D
A
D
Those
you
have
an
end
module.
That's
imported
a
env.
Now,
if
you
wanted
to
be
able
to
map
that
from
within
a
package
boundary
so
that
just
for
that
one
package,
it's
getting
a
very
specific
implementation
of
env,
that's
something
that
would
be
nice
because
of
the
fact
that
we're
supporting
relative
paths
in
the
exports
map.
If
we
also
support
non
relative
paths,
you
could
map
and
within
a
package
to
mean
something
locally
or
or
externally
as
well,
so
that
that
could
be
a
useful
way
to
do.
Mappings
of
names
from
outside
the
module.
D
We've
got
an
issue
on
the
export
Maps
proposal
to
cover
that.
But
if
we
do
that
for
the
own
name,
you
get
a
kind
of
a
circularity
between
the
main
or
which
came
first
between
the
main
and
and
this
name
feature.
So
that's
that's
one
of
the
reasons
why
it
can't
really
be
implemented
through
the
X
and
it's
a
little
bit
of
a
complex
one.
D
You
have
to
kind
of
go
through
the
logic
which
I
can't
really
do
now,
but
if
you
have
the
time
to
kind
of
think
it
through
you
can
you
can
look
at
that.
So
that's
the
reason
why
it's
it's
something
unique.
We
could
do
it
through
some
text.
We
could
do
it
as
a
special
kind
of
relative
namespace
and
then
the
other
proposal
we
discussed
was
to
have
the
syntax
of
the
tilde,
and
that
was
something
that
Jordan
was
also
preferring
and
one
of
the
reasons
why
I'm
I'm
concerned
about
that
kind
of
syntax.
D
Actually,
because
you
end
up
with,
if
I'm
gonna
generate
my
import
map,
I'm
just
gonna
have
this.
This
import
map
littered
with
Tilden's
for
those
for
those
relative
named
and
I
personally
think
it
actually
looks
quite
ugly.
So
it's
actually
most
in
aesthetic
argument
to
have
the
import
map
where
every
every
package
scope
has
got
its
own.
Tilde
I
find
the
name
clearer
to
read:
I.
Guess
it's
a
it's
a
bit
of
a
bike
shed
on
that
one
but
yeah.
D
C
I
have
my
hand
up
so
I've
asked
these
questions
on
the
issue.
I
think
there's
there's
two
different
comments.
The
one
is
I,
don't
particularly
care
about
tilt,
I
just
threw
it
out.
There
is
a
suggestion,
but
the
packages
own
name
that
would
break
the
ecosystem,
because
even
though
NPM
will
refuse
to
install
a
package
named
foo
inside
a
package
named
foo,
you
can
just
make
a
folder
inside
node
modules
named
foo,
and
that
will
work
so
I.
That's
not
really
a
viable
option.
C
So
that
relates
to
the
second
point,
which
is
that
I
do
not,
as
I've
stated
many
times
before,
I
think
it
is
it
should.
It
is
a
very
unfortunate
what
sorta
million
for
it
would
be
a
very
unwise
idea
for
us
to
to
introduce
breaking
changes
between
ejs
and
CSS
or
ESM
and
CJ
s
solely
because
we
have
the
opportunity
at
the
time
we're
creating
a
new
module
system.
This
is
a
huge
pain
point
for
CJ
s.
It
already
is
there's
tons
of
babble
plugins
that
handle
it.
C
People
put
symlinks
and
node
modules
to
handle
it.
There's
like
tons
of
best
practices.
Debates
about
how
do
you
address
this?
Do
you
address
this
at
Airbnb?
We've
built
our
own
internal
tooling.
To
do
this
so
like
this
is
an
existing
pain
point.
Yes,
M
is
not
unique
to
USM.
It's
something.
I
think
that
nodes
should
solve
for
all
of
its
module
systems
and
if
we're
solving
it
for
CJ
s
and
ESM
together,
number
one
ESN
gets
the
solution
for
free
and
number
two.
C
Then
we
can't
make
breaking
changes,
which
I
think
is
a
reasonable
assumption,
because
when
I
see
a
bear,
import
name
I
expect
that
it's
in
a
node
modules.
That's
how
node
works
and
I
think
that
it's
complicating
the
mental
model
of
how
specifiers
work.
If,
if
I
can
rename
my
package.json
and
all
of
a
sudden
a
bunch,
you
know
from
let's
say
if
I
rename
my
package
from
food
to
es
lint
or
food
to
react
all
of
a
sudden.
My
whole
package
behaves
wildly
differently
in
breaks.
That
seems
like
to
me.
C
It
seems
like
what
we're
looking
for
here
is
less
of
an
identifier
and
more
which
can
be
shadowed
and
more
of
a
keyword
which
cannot
be,
and
it
doesn't
to
your
import
map.
Point.
That's
a
fair
point.
I
using
the
exact
same
token,
for
all
packages
will
make
import
Maps
much
more
complex
and
arguably
ugly
and
I
think
that's
reasonable.
It's
a
reasonable
pushback,
but
there
that
I
think
that
if
we
find
some
combination,
let's
say
we
do
tilled
and
the
package
name
or
something
there
may
be
some.
C
A
E
I
I
mean
I,
just
it's
a
repeat
what
I
said
in
the
text
chat
like
you
can't
actually
rely
on
the
package
name
inside
of
the
package,
because
the
package
name
is
liable
to
change
and
be
changed
by
the
Installer,
like
you
can
force
NPM
to
install
like
n-type
script
under
the
package.
Name
tie
script
and
like
people
do
this.
A
It
was
a
namespace
specifically
for
a
package
and
that
namespace
could
be
like
root
or
it
could
be
self
or
it
could
be
this
or
like
we
could
bike
on
whatever
that
symbol
is,
but
the
idea
would
be
that
it
would
be
a
special
namespace
that
refers
to
the
root
of
the
project
that
you're
in,
and
you
know
this
is
something
that
we
could
even
propose
to
the
package
name
map
proposal.
As
you
know,
a
mechanism
within
I
guess
I'm.
A
Sorry,
import
map
proposal
is
something
that
we
could
propose
to
have
the
exact
same
kind
of
behavior
there.
It
wouldn't
necessarily
require
n
number
of
entries
inside
of
the
map,
because
if
it's
just
a
reference
to
the
root
of
your
project,
you
know
that
would
just
be
like
consistent
between
the
different
environments.
A
The
the
the
thing
for
the
CJ
s-
slash,
ESM
part
of
the
story-
would
be
that
if
we
introduced
and
supported
namespaces
in
node
that
this
feature,
if
there
was
like
a
special
namespace
that
referred
to
the
root
of
the
package
that
you're
in
that
this
is
something
that
could
be
equally
supported
in
both
es
m
and
CJ
s.
And
it's
something
that
could
be
introduced
as
a
cember
minor,
because
it
would
not
change
any
currently
existing
behavior
Jordan
yeah.
C
B
A
C
Imagine
a
world
where
are
you
out
of
your
thousand
dependencies?
50
of
them
use
this
route?
You
now
need
50
entries
in
your
pattern.
Your
import
map
for
each
package
that
uses
route
and
your
tooling
has
to
suss
that
out
and
each
one
would
scope
the
word
route
or
whatever
to
that
package.
I
agree
with
you
that
would
work,
but
that
doesn't
solve
guys
mentions
concern
about
in
you
know,
drastically
inflating
the
size
of
the
import
map
and.
A
That
would
be
where
it
would
make
sense.
I
guess
the
idea
would
be
that,
like
the
capability
is
able
to
be
done
today
by
tooling,
but
that
makes
sense
to
talk
to
Dominic
and
go
to
the
people
working
on
the
proposal
and
bring
this
up
as
a
future,
because
if
it
is
just
a
consistent
feature
and
a
symbol
that
we
all
agree
on,
then
it
can
just
be
a
default
and
not
be
something
that
needs
to
be
in
every
single
scope.
So.
C
I
think
that
sounds
awesome
and
and
meet
Salt
Lake
miles
your
suggestion
or
your
suggestion,
modification
meets
all
of
my
concerns
as
long
as
whatever
the
specifier
is
was
not
something
that
could
exist
on
the
file
system
already,
and
then
it
would
be
able
to
be
cember
minor
in
both
module
systems.
I
can
help
you
actually
and
and.
A
If
we
went
forward
with
namespaces
that
were
colon
based-
and
that
is
part
of
the
beauty
of
that
is
that
has
come
like
it
can't
be
replicated
on
Windows
file
system,
so
we
would
have
yeah.
We
can
explore
West's
showing
some
other
ones.
We
can
explore
some
other
symbol
as
well,
but
yeah
to
me.
That
seems
like
a
solution
that
could
work
by.
D
Yeah
I
could
get
behind
that,
as
as
mentioned,
the
you
get
a
if
you're
going
to
have
a
map
for
each
one
of
these
sort
of
common
symbols
in
your
package,
scopes
in
theory
that
shouldn't
be
so
bad
under
compression
because
it's
gonna
be
the
same
name
as
the
original
name
in
the
scope
that's
being
mapped
to,
and
this
is
being
repeated
so
over
the
wire.
It
shouldn't
actually
add
that
much
cost
its
many
doesn't
say
a
kind
of
an
aesthetic
thing.
D
D
There
wasn't
much
interest
in
it
at
all.
So
if
you
want
to
have
that
discussion
again
miles,
certainly
let
us
know
how
it
goes
and
and
then
also
just
to
just
to
follow
up
on
Wesley's
points.
I,
don't
believe
the
package.json
name
is
overwritten.
Wouldn't
you
install
the
package
as
an
alias
in
NPM
I
think
it
might
override
it
as
another
metadata
in
the
package.json
when
it
when
it
close,
doesn't.
C
A
Okay,
I
ping
Dominic
with
that
thread,
and
you
know
I,
will
figure
out
sorry
I'm,
seeing
all
of
the
bike
sheds
in
the
in
the
chat
I'm
like
laughing.
We've
got
like
pound
this
:
V,
this
dot
pound
this
slashes,
/a,
dat,
self
@
@
and
then
a
smiley
face,
but
I'm
assuming
that
smiley
face
is
meant
to
be
some
sort
of
symbol.
A
B
One
is
it
couldn't
we
just
combine
these
two
ideas
to
solve
both
cases
like
you
had
like
you
know,
your
package
name
is
name
like
tilde
name
and
then
it's
like
it's
unique.
It's
not
repeated
50
times,
but
it's
also
not
something
that
could
be
on
disk
because
it
starts
with
the
tilde
or
it
starts
with
a
colon
or
whatever.
A
C
Is
often
solved
in
ecosystem
is
exactly
what
you're
suggesting
Jeffrey.
Is
that
like
like
internally
at
Airbnb,
we
use
a
colon
and
then
like
a
project
name
in
our
mono
repo
and
in
the
past,
where
I've
had
it
set
up
so
that,
like
tilled,
mapped
to
the
root
of
all
our
JavaScript.
Before
we
had
a
mono
repo
and
like
I've,
seen
many
babel
transforms
in
the
ecosystem
that
do
exactly
that
for
the
reason
you're
saying,
because
it
can't
exist
on
the
file
system.
B
C
Think
that
would
still
create
the
the
lots
of
import
map
entries
and
then
the
similarly
guys
like
Wes
is
pointing
out
the
the
name
of
the
package
is
just
as
mutable
as
the
file
paths,
so
I
think
if
you're
trying
to
solve
refactoring
churn
caused
by
renaming
files
renaming
packages
is
rarer,
but
still
can
happen,
and
so
it
it
almost
seems
more
useful
to
use
the
same
exact
token
in
every
package
and
have
it
refer
to
the
current
package.
But
then
that
aggravates
the
import
map
length.
So
you
know
trade
offs
everywhere.
A
Whereas
if
it's
something
that
we
want
to
do
as
a
specifier
like
Jeff
suggested
with
the
tilde
in
the
name,
then
that's
something
that
like
could
potentially
be
semver
major
and
we'll
have
to
you,
know,
examine
based
on
those
merits.
I
guess
I,
guess
the
one
challenge
that
I
would
pose,
and
maybe
this
changes
the
way
that
we
think
about
it.
I
think
it's
actually
very
reasonable
to
try
to
make
this
a
feature
that
both
CJ
s
and
ESM
can
have.
A
And
with
that
in
mind,
if
we
want
this
to
be
something
that's
usable
in
short
order
like
in
the
next
three
years,
we
do
really
need
to
come
up
with
a
solution.
That's
ember
minor
or
it's
not
something.
That's
going
to
be
able
to
see
adoption
in
any
sort
of
short
order
and
I
think
that
it
also
should
be
very
much
something
we
strive
to
to
make
it
something
that
can
be
cross-platform
as
well.
A
Cool
yeah,
I
guess
guy
guy
brought
up
a
point
that
I
think
is
worth
digging
into
a
tiny
bit
and
we
can
figure
out
how
how
and
what
we
want
to
do
for
this.
But
we
ran
into
some
problems
with
web
assembly
modules,
so
the
implementation
that
that
guy
put
together
and
like
will
help
bring
over
the
finish
line.
Gus
did
a
bunch
of
the
work.
I
did
a
little
bit
of
connecting
the
dots.
Thank
you
guys
for
getting
that
over
the
finish
line.
A
The
tests
and
everything
that
we
wrote
were
taking
I
believe
what
it's
called
W
ast,
which
is
like
an
intermediate
representation,
AST
format
and
then
using
a
tool
to
convert
that
AST
directly
into
web
assembly.
It
creates
much
cleaner
output
that
doesn't
have
any
of
kind
of
the
environment
that
gets
built
in
by
a
lot
of
the
compilers.
A
So
when
I
went
and
tried
just
building
a
few
things
and
bringing
them
into
our
current
implementation,
it
does
not
work
as
expected,
and
it's
less
of
an
issue
of
like
our
implementation
being
wrong
and
more
that,
like
at
least
M
scripted,
which
is
the
main
upstream
compiler.
Being
used
for
web
assembly
modules
is
expecting
you
to
bootstrap
the
web
assembly
with
another
bit
of
JavaScript
code
that
they
give
you,
which
does
a
bunch
of
instrumentation
and
setting
things
up.
A
So
if
you
were
to
compile
with
them
script
in
and
create
that
kind
of,
like
wrapper
j/s
code
and
then
import
that
j/s
code,
it
would
work,
but
then
we're
not
really
dealing
with
a
native
web
assembly
module.
So
if
you
try
just
taking
the
web
assembly
that's
compiled
without
that
wrapper,
you
get
a
warning
right
away,
that
you
are
missing.
An
import
called
env
env
that
F
import
is
expected
by
the
web
assembly
and
it's
acts
like
a
resource
specific
thing.
A
So
there's
kind
of
this
missing
bit
that
we
have
right
now
of
giving
people
the
ability
to
say
like
hey
in
the
name
space
of
like
just
this
module
I
want
to
have
like
this
symbol
available
and
I,
guess
guy.
What
you
were
hinting
at
before
was
like
a
mechanism
like
this
could
be
used
to
do
exactly
what
you're
talking
about,
which
is
making
specific
things
available
to
the
package.
That's
not
available
outside
of
it,
which
could
be
its
own
route,
for
example,
or
a
reference
to
itself.
So.
C
It
kind
of
sounds,
like
you
know,
no
one's
hand
is
raised.
It
kind
of
sounds
like
what
you're
asking
for
is
Global's
plus
one
thing
which
to
me
sounds
exactly
like
what
the
built-in
modules
proposal
is
looking
for.
In
other
words,
they
want.
You
want
Global's,
except
you
want
to
be
able
to
compartmentalize
them
to
specific
modules
and
like
virtualize
them,
but
essentially
at
first,
so
that
module
a
gets.
This
gets
undefined
in
module,
B
gets
three
and
module.
C
gets
four
or
modules.
C
So,
which
is
what
Wes
just
brought
up
for
right
so
I
think
like
that's
a
import
for
considered
like
for
security
and
virtualization
and
stuff,
that's
a
useful
constraint
to
be
able
to
essentially
decide
which
things
you
want
to
inject
into
which
modules.
But
that's
not
that's,
also
not
something
that
has
a
pattern
right,
like
like
other
than
the
the
legacy
stuff
and
CJ
asked
that,
like
dur
name
and
stuff
that
we're
trying
that
we've
actively
tried
not
to
replicate
me
SM.
There
really
isn't
any
convention
in
JavaScript
for
injecting
things
into
contextually
into
modules.
C
A
C
That
would
be
Global's
and
where
the
realms
proposal
also
it
has
a
concept
called
compartments
which
is
within
the
same
realm,
meaning
they
share
like
the
same
array,
dot,
prototype
and
stuff
like
that,
but
they
have
different
like
they
can.
Each
compartment
can
have
different
shadowed
Global's
available
to
it,
and
this
was
one
of
the
constraints
for
the
global.
This
proposal
be
able
to
function
in
this
way
so
like
essentially,
it's
basically
wrapping
a
modules
execution
with
a
pre-populated
scope
and.
A
So
they
make
sure
that,
like
every
time,
you're
calling
like
print
F
printf
then
refers
to
the
end
and
the
end
like
links
that
constant-
and
this
is
a
lot
of
what
huazi
is
looking
at
doing
and
huazi
made
being
the
solution
that
we
can
use
in
node
for
this.
But
it
was
more
than
I
identified.
You
know
this
pattern
of
like
a.
C
One,
and
so
I
also
want
to
add
on
that
like
so
since
there
are
no
like
module
IDs,
in
other
words,
there's
no
way
to
know
when
something
is
being
requested
from
a
given
one
module
over
another
there's,
no,
like
userland
code
way,
I
can
think
of
nonsan
tactic
way,
maybe
to
like
call
a
function
and
say:
hey
give
me
the
end
and
then
have
it
know
where
you're
calling
it
from
with
certainty
and
give
you
the
correct
one.
But
similarly
I've
heard
a
lot
of
talk
over
the
years
about
tenants,
correspondence
principle.
C
The
idea
that
code,
that
does
something
like
I'm,
probably
not
gonna,
probably
gonna,
mangle
it
up
when
I
describe
it
but
like
essentially
I,
have
a
feeling
that
there
will
be
concerns
with
writing
some
code,
that
in
module
a
that,
if
you
extract
to
another
module,
B
will
behave
very
differently
and
I,
don't
think
that's
currently
possible.
So,
while
I
agree
with
you,
this
is
a
something
that
needs
to
be
explored
in
the
module
system
and
the
language.
I'm
I
think
that
there
are
a
lot
of
unanswered
questions
and
a
lot
of
possibly
impossible.
C
To
answer
questions
around
it,
obviously
the
loaders
can
do
whatever
they
want,
but,
like
I
know,
it's
it's
a
very
big
topic,
so
I
I
hope
that
it's
something
that
we
consider
like
possible
to
defer
until
after
unflagging,
so
that
we
can't
so
that
we
can
punt
on
it.
Obviously
we
shouldn't
punt
on
it.
If
it
we
wouldn't
be
able
to
ship
it
after
that
time,
but
yeah
does
that
make
sense.
It.
A
Does
a
slight
caveat:
I
know
that
this
is
a
tangent
for
us
that
can
I
just
say
how
exciting
it
is
that
we're
having
forward-thinking
conversations
right
now
and
not
just
by
chatting
about
like
the
status
quo
of
today,
I
think
that
this
may
be
one
of
the
like
first
meetings
that
we've
had
we're.
The
majority
of
things
that
we're
talking
about
are
forward-looking
and
that's
a
pretty
awesome
change
of
pace
yeah.
So
there
you
go
there.
A
My
my
optimism
for
the
meeting
today
I
think
that,
with
that
being
said,
I
think
we've
maybe
gotten
to
the
end
of
what
we
can
accomplish
on
the
call
today.
I
think
the
last
thing
that
we
have
on
the
agenda
is
moving
forward
with
dynamic
modules
guy.
We
don't
really
have
any
updates
on
that
right
now.
Do
we.
A
I
think
I
think
that
the
the
next
steps
on
it
may
be
like
synthetic
modules
and
cyclical
modules
were
recently.
You
know,
introduced
and
added
to
the
spec,
and
then
work
is
being
done
on
webassembly
modules.
So
you
know
the
next
step
here
might
be
doing
an
evaluation
of
how
these
other
systems
are
accomplishing.
These
things
like
how
how
is
web
assembly
doing
it
but
like
web
assembly,
doesn't
have
the
same
like
dynamicism
that
we
do
in
in
CGS.
But
you
know
I
I
think
it's
just
people
stepping
up
and
doing
some
more
work.
A
There
West
puts
that
dynamic
modules
still
on
the
tc39
proposal
list
as
stage
one,
so
we
just
need
to
kind
of
revisit.
It
I
think
that
a
bunch
of
the
folks,
myself
and
I
included,
who
were
who
have
been
focused
on
this
one,
have
been
kind
of
heads
down
on
top-level
await
which,
by
the
way
for
the
record,
is
now
on
the
agenda
to
try
to
move
to
stage
three
for
the
next
meeting
and
we
are
in
the
midst
of
spec
review
with
reviewers
right
now.
A
A
A
Right
cool
open
for
anyone
who
wants
to
get
into
that
at
the
very
least
what
we
can
do
is
you
know
we
have
the
collab
summit
coming
up.
Maybe
we
can,
during
the
modules
breakout
just
talk
about
it
a
little
bit
and
maybe
come
up
with
a
plan
to
bring
things
to
the
tc39
meeting
and
talk
to
some
folks
if
we
have
bandwidth
for
it.
A
D
A
Promise
that
I,
don't
think
modules
are
boring.
I
think
that's
it
for
today
did
anyone
else
have
any
announcements
things
they
wanted
to
bring
up
grievances
appreciations,
I,
updated
the.