►
From YouTube: Node.js Foundation Modules Team Meeting - May 9 2018
Description
B
B
See
if
that
works
you'll
see
my
screen,
yep
wait:
cool
okay,
so
we
have
to
hold
off
for
now
on
the
approving
of
the
PRS
and
observers.
So
I
want
to
talk
about
we'll
cover
some
of
the
use
cases
that
were
added
but
I
also
figured.
This
is
a
nice
time
to
talk
about
kind
of,
what's
happened
in
the
last
few
weeks
on
the
modules
front,
both
in
user
land
and
in
EndNote.
B
So
if
you're,
following
along
on
the
pour
requests,
there's
been
some
activity
on
well,
first
of
all,
no
tin
is
released
and
the
note
10.1
has
also
been
released,
and
on
the
ESM
front
on
that
one,
there
is
a
utility
method,
so
util
dot
types
data
is
module,
namespace
object,
oh
I
believe
the
API
is,
and
that
will
detect
if
an
object
is
a
namespace
object.
So
that's
that's.
B
In
there
there's
also
been
some
progress
on
the
experimental
named
export
support
of
built-in
modules,
so
things
like
FS
path,
events,
those
kind
of
built-in
modules
has
been
there's
been
work.
On
that
front,
there
was
a
couple
of
v8
bugs
that
overcomplicate
will
cause
the
the
pull
requests
to
be
complicated
and
those
bugs
were
results.
So
now
the
the
pull
request
has
been
updated
for
simplicity
there.
So
there's
been
work
there
on
the
ecosystem
front,
so
userland
I've
been
experimenting
with
enabling
amp
or
application
performance
monitoring
packages.
B
The
last
two
weeks
I've
been
getting
those
working
in
any
and
userland
with
yes
encode
in
an
interrupt
kind
of
path.
Last
week,
I
was
able
to
also
get
things
like
mocking,
so
that
falls
into
use
cases
for
performance,
monitors
and
path.
Resolution,
augmentation
and
also
a
dynamic
swapping
out
of
exports,
not
only
enabling
them,
but
also
disabling
them
at
runtime,
to
which
turns
out
is
a
separate
piece
to
get
working.
So
that's
that's
on
my
neck
of
the
woods.
B
C
C
You
know
prior
to
HTTP,
to
being
landed
as
a
core
module.
Basically
asking
like
can,
can
we
figure
out
a
way
for
new
core
modules
to
not
conflict
with
the
overarching
bear
package
name
namespace
on
NPM,
and
my
hope
was
that
it
wasn't
wouldn't
be
too
late
for
HTTP
2,
but
all
the
folks
who'd
been
working
on
it
had
some
strong
pushback
against
changing
the
plan
there.
C
So
the
rough
like
consensus
of
the
thread
was
okay
after
HTTP
2
won't
add
anything
new
until
we've
figured
out
some
sustainable
solution
moving
forward,
and
that
might
be
a
namespace
that
node
core
could
own
on
NPM.
It
might
be
some.
You
know
some
string,
that
is
an
impossible
package
name
so
that
no
one
on
NPM
could
be
using
it.
Or
you
know
it
couldn't
be
something
on
the
file
system.
C
A
Just
gonna
add
to
that
discussion
in
that
there
was
some
discussion
that
you
know.
Maybe
it's.
What
we
do
for
for
CGS
is
tied
to
what
we
do
for
for
the
yes
six
modules.
So
if
this
groups
thinks
that
thinks
that
there
is
or
it
is,
it
is
or
is
not
a
linkage
or
and
if
there
is
like
what
the
suggestions
would
be
actually
chiming
in
would
definitely
be
useful
to
help
that
move
forward,
because
I
think
at
this
point
it's
kind
of
like
well,
we
it's
a
little
bit
of
the
sense
I
got.
A
C
And
I
think
I
assume
we'd
all
agree
that
that
the
the
immediate
linkage
is
that
anything
that's
done
with
a
CJ
s.
Module
needs
to
be
future
compatible
with.
You
know
the
general
sense
that
we
have
of
how
it
will
work
with
ES
modules
in
terms
of
ergonomics,
and
you
know
how
the
API
looks
and
stuff
what.
B
This
could
also
bleed
over
into
5039
as
well
they're
trying
someone's
phone's
going
up,
there's
they're,
trying
to
resolve
things
like
array
flatten
and
in
and
that
naming
issue
and
namespaces
and
naming
tends
to
come
up
a
lot.
So
having
a
way
to
do
that,
cleanly
would
be
great.
Ok,
let's
look
at
the
if
they're
another
right
hand,
sorry
Bradley.
B
B
B
I
think
so
now
that
we
have
features
and
they
are
bucketed,
it
may
be
good
to
go
back
through
them
and
actually
start
now
that
there
is
a
bucket
start
flushing
out
what
what
features
would
actually
materialize
from
those
buckets
I
looked
through
the
buckets
to
see
which
use
cases
fell
into
them.
The
the
which
features
fell
into
the
most
use
cases-
and
it
appears
to
be
things
like
specify
resolution
and
specify
our
customization
is-
is
a
is
a
one
that
affects
a
large
number
of
use
cases.
B
But
let's
look
at
the
use
case
documents
so
from
there.
If
you're
following
the
agenda,
the
meeting
issue,
it
should
be
issue
number
55
and
inside
issue
number
50,
there's
a
link
to
the
use
case
document
and
right
now,
I'm,
not
looking
at
zoom,
so
I
can't
see
hands
range.
So
please
I'll
pop
back
over
there
in
a
second.
B
If
someone
else
wants
to
also
lead
the
discussion
on
the
use
cases,
that's
cool
too
I.
Don't
have
to
do
everything.
There
I
believe
the
we
left
off
last
week
right
before
the
typescript
use
cases,
because
I
remember
they
were.
They
were
saying
that
they
forgot
to
add
their
use
cases,
and
then
we
were
looking
at
some
of
Jeffrey's,
so
I
think
we
have
either
either
that
the
tail
end
so
number
forty
below.
Let's
see
do
we
have
any
volunteers,
nope,
okay,
so
that's
gonna!
Be
me
all
right.
B
A
E
Think
it's
pretty
pop,
like
I
I,
would
think
that
most
people
just
kind
of
choose
one
of
the
other,
like
that's
not
common,
that
they
would
use
import
and
export
statements
as
well
as
require
statements
in
their
code,
there's
probably
just
like
either
one
style
or
the
other
throughout
their
codebase,
at
least
for
their
app,
not
not,
including
like
any
dependencies
like
no
models
that
they're
for
you,
so
for
them,
like
I,
think
for
the
average
user.
They
don't
think
of
this
feature
as
like.
E
Supporting
like
that,
node
added
support
for
modules,
I
think
the
average
user
just
sees
it
as
node
added
support
for
import
and
export
statements
like
the
syntax
so
like
from
an
from
an
average
users
perspective.
It's
like
well
I
already
have
import
statements
in
my
code,
and
it
already
has,
like
you
know,
import
underscore
from
underscore
and
stuff
like
that
or
underscore
from
Lodi
or
whatever,
and
you
know
once
at
once
know
dad's
support
for
it.
B
E
Like
I,
obviously,
if
they're
using
both
import
and
require
in
the
same
file
and
stuff
like
that,
that's
you
know
that
it's
not
gonna,
be
like
every
single
person
for
every
single
variant.
It's
gonna
just
work
when
they
disable
battle
but,
like
you
know,
I,
think
for
common
use
cases
or
for
like
the
the
most
plain
types
of
apps
or
like
that,
we
see
a
lot.
B
E
So
well,
it's
not
a
real
world
use
case
of
number
40.
It's
just
a
separate
real
world
use
case.
So,
like
you
can
so,
for
example,
you
can
put
a
require
statement
inside
an
if
you
know
which
you
can't
do
with
an
import
statement,
and
there
are
that's
just
one
example
of
like
you
know
just
looking
at
the
plain
syntax
definition
in
like
the
MD,
an
article
for
import,
for
example,
of
like
this
is
something
you
can
do
with
comma
J
s.
E
F
E
For
that
reason
that
you
know
either
they
have
to
refactor
and
drop
functionality
or
they're
stuck
on
commands.
Yes,
for
whatever
reason
like
if
they
have
it
like.
In
CoffeeScript,
for
example,
we
have
a
like
a
basically
the
equivalent
of
a
module
loader
hook
for
specifically
like
require,
like
required
out
extensions,
so
that's
obviously
very
specific
to
comma
J
s.
So
unless
we
want
to
drop
support,
for
you
know
integrating
with
the
commonjs
module
loader,
we
need
to
keep
that
and
keep
the
stuff
related
to
cough
and
Jas.
E
E
B
E
I
guess
I
didn't
really
put
this
in
the
in
the
Google
Doc,
but
I
guess
maybe
part
of
it
is
like
I
as
the
package
maintainer
I.
Don't
want
to
have
to
do
anything
for
my
package
to
be
used
in
DSM
like
I.
Don't
want
to
have
to
like
create
a
babel
transform
to
create
a
separate
output
so
that
someone
can
do
an
import
statement
for
my
package
because
then
it's
like
you
know
the
million
packages
that
are
out
there
on
NPM.
E
G
B
E
They
are
different
because,
like
right
now,
if
I
do,
like
you
know,
if
processed
and
blah
blah
blah
require
such-and-such
that
require
statement
is
synchronous.
You
know
I'm
not
like
it's
not
returning
a
promise,
so
that
code
would
be
to
have
to
be
refactored
beyond
just
converting
inquire
to
import.
They
would
have
to
be
like
some
significant
refactoring
in
that
app
to
make
that
handle.
D
E
B
C
B
B
B
B
E
Is
the
advantage
of
showing
up
so
yeah
another
real
real
world
use
case
of
importing
a
JSON
file
like
yeah?
Obviously
you
could
do
this
via
I
guess:
FS
dot
read
file
sync,
but
it's
pretty
common
for
apps.
To
do
like
require
something
Jason
in
particular,
the
like
something
I've
seen
in
several
different
apps
is
require
package
that
Jason
to
dynamically
pull,
for
example,
the
version
of
your
package
without
having
to
like
copy
paste
that
or
you
know,
do
a
file
open
or
any
that
kind
of
stuff.
B
B
B
B
E
Well,
what's
synchronous
is
that
it's
like
you
know
like
then
the
example,
their
version
equals
require
package
jason,
the
very
next
line
you
could
use
that
version
variable.
You
don't
need
to
wait
for
a
promise
to
resolve.
That's
how
people
are
using
it
now,
because
it's
like
generally,
I
mean
I'm
assuming
even
in
even
in
the
ESM
world,
when
you're
importing
a
relative
file
like
your
main
dot,
j,
ass
and
you're
importing.
You
know
food
on
Jas,
that's
a
synchronous,
import
right!
It's
not
like
every
import
statement
becomes
a
promise
to.
D
E
E
That's
that's
what
I'm
saying
that's
what
I
mean
by
synchronous
like
I?
Don't
care
under
the
hood,
it's
synchronous
or
asynchronous
I
mean
like
from
a
developer
or
I,
don't
have
to
write
a
promise
or
in
a
wait
or
any
that
stuff.
The
same
way
that
I
don't
have
to
write
now
wait
a
little
wire
statement.
B
Jeffery
I'm
going
to
have
you
do
a
follow-up
just
to
clarify
the
use
case,
because
it
feels
like
that
there's
a
lot
of
room
for
interpretation
on
it
and
what
that
means
is
that,
if
the?
If,
if
that
ends
up
in
the
process
of
fleshing
out
that
use
case,
if
it
becomes
a
synchronous
one,
then
we
can
add
it
to
the
synchronous
bit.
B
But
at
the
moment,
source
being
able
to
read
like
a
JSON
or
HTML
or
or
native
is,
is
a
scenario
or
a
feature
and
I
think
that
as
it's
written
at
the
moment,
it
feels
a
little
Wiggly
to
be
just
synchronous
but
feel
free
to
modify
the
use
case
and
then
totally
will
be
able
to
add
it
to
the
synchronous
use
case
for
sure
or
I
could
add
a
second
one
sure
yeah
yeah,
that's
great
cool
all
right.
So
we
have
a
bunch
of
features
with
numbers.
I
would
like.
B
If
we
could
talk
about
like
next
steps,
we
I
mean
every
week
we
can
look
at
the
use.
Cases
that
are
are
entered
and
then
bucket
eyes
them
into
possible
features.
But
we
need
to
talk
about
like
what
are
we
going
to
do
now
that
we
have
a
list
of
features
and
scenarios
that
fit
into
those
features?
My
my
take
would
be
just
throwing
it
out.
There
we'd
be
to
start
seeing
if
they're
materializing
the
features
a
little
bit
more
seeing
if
we
can
start
saying
things.
B
Prioritizing
the
features
and
start
thinking
about
them
in
terms
of
implementation.
Yes,
that's
the
next
step.
We've
approached
this
at
the
so
far
with
a
yes
and
mindset
and
I
think
that
now
we're
going
to
have
to
start
talking
about
core
design
decisions,
so
things
like
synchronous
being
able
to
do
something.
Synchronous
can
affect
common
J's
Interop
and
has
a
ripple
in
terms
of
implementation.
B
Details
beyond
that,
and
things
like
ap
is
that
shakeout
into
VM
module
and
other
things
so
I
know
that
we're
going
to
have
to
to
to
work
that
out
and
if
anyone
has
any
ideas
on
how
to
go
forward
with
that
in
a
way
that
we
can
handle
with
a
discussion
and
maybe
something
that
we
can
tackle
in
between
the
two
weeks,
but
between
the
meets
we
can
come
to
a
meeting
prepared
to
be
able
to
to
move
some
of
these
things
forward.
That
would
be
great.
B
A
B
F
H
There
you
go
there,
you
are
so
Daniel
is
use-case
was
number
42,
yes,
which
was
Rachel's
typescript
user
who's,
importing
some
JavaScript
code
that
uses
common
GSU's
declaration
files
that
were
written
on
definitely
typed,
but
we're
authored
as
es
module
top-level
exports
like
so
export
stuff,
and
when
she
imports
from
transcript,
she
has
code
completion
on
the
namespace
import
for
foo
and
bar
meaning
you
do
import
stars
whatever
from
some
packaging
to
run
and
compile
on
either
the
college
S
aureus.
Next
module
plug
it's
correct.
H
B
H
Yeah,
so
definition
files
are
just
an
extra
I
guess
wrench
in
this
compatibility
problem
that
be
at
typescript
have
their
extra
metadata
describing
the
type
information
for
hundreds
of
thousands
actuals.
The
community
has
been
maintaining
over
the
last
few
years
and
typically
they
are
authored
in
the
style
of
esm.
Even
if
the
package
itself
isn't
actually
written
in
ESM
today,
it
couldn't
be,
but
the
syntax
was
available
and
everyone
assumed
that
they
would
work
in
the
same
way,
and
so
that's
how
they've
been
written.
H
B
You
flesh
out
the
use
case.
Well,
I
guess
won't,
might
go
under
features
whenever
we
do.
It
would
be
nice
to
understand
the
problem
case
or
the
the
expectantly
so
work
like,
for
example,
if
you
have
this
ESM
kind
of
syntax
for
your
type
definition
file,
how
does
that
change
with
the
module
format
being
ESM
or
a
comma
j
s
underneath
the
underneath
it
so.
H
The
the
the
core
of
it
is
that,
like
saying
that
you
export
foo
is
the
same
as
exports,
dot,
foo
income
and
j
s,
and
so
on.
Like
that's,
that's
pretty
much
it
like
it's
that
the
that
XM
is
effectively
just
like
a
mask
over
colin
GS
that
lets
you
not
assigned
to
the
entire
module
object.
That's
the
only
thing,
that's
different,
so
yes,
this
would
be
an
interrupt.
A
B
H
Recompiling,
specifically,
wouldn't
be
the
problem.
The
thing
is
what
I'm
talking
about
type
definition
files
I'm
talking
about
extra
files
of
metadata
that
are
distributed,
sometimes
alongside
a
common
JSP
that
just
provides
trouble
pipe
to
the
package,
those
compiled
per
say,
they're,
just
read
in
what
we
would
need
to
do
in
a
world
where,
for
like,
no
DSM,
that
only
new
type
definition
files
can
ever
be
compatible
with,
because,
obviously
old
type
definition
files
were
written
with
the
intent
that
the
Interop
would
be
transparent.
And
it's
not
so.
D
H
If
no
does
have
like
a
braking
upgrade
path
where
ESM
isn't
substitutable
for
common
drafts
and
everything
has
to
be
different,
then
by
extension,
typescript
has
to
do
the
same
thing.
We
just
have
twice
as
many
files.
We
need
to
look
at
because
we
need
to
look
at
ESM
and
we
need
to
look
at
definition.
Files
and
the
definition
files
need
a
marker
to
indicate,
therefore,
no
DSM
and
not
interrupt
babble,
CGAs
transpile
DSM
because
like,
in
effect,
unless
note,
does
almost
exactly
what
Babel
was
doing
prior
to
no
deciding
to
implement.
H
Like
yes,
modules
we
are
going
to
have
to
in
order
to
support
all
everyone.
Who's
been
writing
these
modules.
For
the
last
few
years,
we're
gonna
have
to
support
multiple
SM
formats.
So
it's
one
of
those
you
might
want
to.
You
might
be
able
to
get
closer
to
the
browser,
but
you
will
get
farther
away
from
your
past.
B
J
Yes,
yeah,
it
would
be
really
helpful
if
you
could
describe
how
the
type
definition
files
would
have
to
differ
between
four
different
modes,
because
I
think
that's
what
we're
not
getting,
and
there
are
other
parts
where
it's
like
part
of
the
reason.
The
modules
working
group
exists
now
is
to
draw
these
use
cases
into
the
discussion
about
what
nodes
final
implementation
will
look
like
so
like
this
isn't
one
that
we
had
considered
before.
So
this
is
really
good.
Yeah.
H
B
One
of
the
things
I
can
do
is
to
open
issues
for
us
to
look
at
a
specific
feature
more
closely
and
then
start
to
flesh
that
out.
Does
anyone
have
any
opinions
on
which
one
of
those
that
might
be?
We
have
several
as
I
think
at
the
start
of
the
meeting
there.
Those
one
would
a
lot
of
the
use
cases
looks
like
specify
our
resolution,
our
customization,
but
does
anyone
else
want
to
volunteer
to
pick
up
one
and
start
digging
into
it
or
have
a
feature
that
is
posted.
B
J
B
B
So
what
I
will
do
just
to
kind
of
make
this
easy
is?
We
can
look
at
the
actual
issue
and
then,
if,
if
everyone
is
proven,
so
that,
for
example,
the
doc,
the
meaning
of
from
425,
does
anyone
object
to
merging
in
the
meeting
notes?
Okay,
so
no
all
right
so
of
the
the
members
in
attendance.
We
have
I
believe
12,
but
I
need
to
account
that
again,
so
one
Michael
are
you
a
member?
Oh
yes,
one
two,
three.
B
We
have
Jordan,
that's
overlapping,
we
have
Wes,
that's
overlapping.
We
have
one
two
three,
four,
five,
six,
seven
and
I'm
one
of
them,
eight,
okay.
So
if
you
have
not
approved
this
might
also
be
easier.
If
you
have
not
approved
the
pull
request
and
you
are
in
attendance
and
you
agree
that
it
should
be
merged,
can
you
go
ahead
and
approve
the
pull
request
that
way
after
the
meeting?
B
B
B
B
B
E
B
B
Think
that
leaves
just
one
of
them
open
I'm
at
the
moment
until
we
vote
on
that
which,
I
think
is
just
the
middle
notes
and
we've
already
taken
care
of
that
with-
is
willing
to
merge
the
meeting
notes.
So
we
could
probably
just
merge
that
to
if
anyone
wants
to
volunteer
to
that
or
I'll
have
miles,
follow
up
and
do
that
since
he's
been
closing
up
the
meeting
notes
before
I,
don't
want
to
step
on
toes
in
terms
of
process
cool.
B
D
I
I
And
if
your
module
happens
to
have
it,
then
then
you
can't
actually
provide
it
back
to
note-
and
this
is
the
seems-
okay
within
modules
themselves,
but
when
you're
writing
an
API
that
you're
exposing
to
node
developers
who
want
to
be
able
to
give
back
arbitrary
modules
through
this
API
to
provide
dynamic
input
through
the
VM
module
that
API
breaks
down
as
soon
as
you
give
a
module
object
that
has
then
on
it.
So
you
don't
have
the
guarantee.
That's
the
dynamic
import
is
always
gonna
return.
I
B
We
have
we
did
that
too.
I
think
that's
a
tough
to
get
to
for
awareness.
I
knew
that
it
was
imports
were
available,
I
was
not
aware
of
causing
problems,
know
if
y'all
could
create
an
issue.
If
there
isn't
one
it
worked
with.
Maybe
a
minute.
There
is
one
for
the
discussion,
so
other
people
can
follow
along.
B
B
B
B
B
K
B
E
B
We
are,
we
are
we
as
a
group.
We,
we
decided
to
look
at
use
cases
and
them
from
their
flesh
out
features.
I
think
that
the
the
next
the
next
step
is
to
dig
more
into
those
features
and
start
materializing
them
as
like.
Ok,
so
what
we
have
we
have
interrupt.
What
does
that
interrupt
me,
transparent?
In
turn
off?
We
should
start
listing
things
out
for
that
or
if
it's
path,
resolution
customization.
What
does
that
mean?
B
B
I
would
say
in
between
the
next
main:
we
only
have
an
hour
every
two
weeks,
so
if
we
can
engage
in
the
the
issue
thread
for
things
like
that,
that
would
be
great
I
would
say.
That's
a
we
have
quite
a
few
areas
of
features
now
broken
out.
Let's
see
on
the
exact
list
here
we
have
about
one
two,
three.
B
See
that
if
you
are
passionate
about,
we
have
17
or
18
or
so
features
and
then
use
cases
that
fall
into
all
of
them,
I
that
would
be
my
next
thing
would
be.
The
next
course
would
be
yeah
fleshing
those
out,
so
I
would
say
pick
one.
You
happen
to
be
passionate
about
or
you
to
to
contribute
to
create
an
issue
for
that.
If
there's
already
an
issue
created,
then
you
can
engage
with
that
issue,
so
you
don't
have
to
create
multiple
noise.
B
B
Would
say,
try
to
be
open-minded
and
yes
and
some
it
wouldn't
be
all
so
nice,
though,
that
we
are,
since
we
are
flushing
things
out,
you
will
come
into
a
discussion
that
says
like
under
the
current
approach
or,
as
things
are
now,
X,
Y
or
Z
is
doable
or
not.
Doable.
I
would
also
like
to
encourage
folks
to
say
like
if
it
is
this.
This
encouraging
mindset
is
what
would
need
to
be
adjusted
or
tweaked,
or
what
would
the
path
look
like
to
enable
something
like
X,
Y
or
Z?
B
So
not
just
what
works
under
that.
The
current
work
on
progress,
but
what
would
need
to
be
changed
or
tweaked
to
to
enable
a
feature
in
for
a
given
use
case
would
also
be
helpful.
Just
so
people
kind
of
know
like
where
the
the
roadblocks
are
going
to
be
where
the
challenges
are
going
to
be
where,
where
they'll
need
to
petition
the
tc39
or
other
bodies
for
assistance
and.
D
B
Like
sure
yeah
I
was
qualifying
my
words
just
to
be
nice
yeah,
so
just
keep
that
in
mind.
Try
to
try
to
enable
and
power
think
about
the
the
use
case
in
the
feature
and
and
what
we
can
do
to
solve
that
there's
software
is,
you
can
solve
problems
in
a
myriad
of
different
ways,
so
we
should
start
thinking
about
that
if
it's
not
one
way
well,
what
about
another
way?
Well,
what
about
another
way?
B
What
about
this
way
and
kind
of
approach
it
that
way,
but
I
would
encourage
to
have
more
activity
in
the
issues
and
threads,
so
the
next
meeting
we
have
we
can.
We
can
dig
into
some
of
these
and
start
fleshing
the
map
cool
all
right.
Thank
you.
Thank
you.
Yes,
thank
you.
All
for
attending
I
will
follow
up
on
that
one
issue
where
we
didn't
close
it
out
yet
and
I
believe
now
that
we
have
of
the
approval
process
to
do
so.
B
Those
meeting
that
should
be
closed
up
in
between
then
and
now
in
next
meeting.
If
you
find
something
like
like
the
the
then
issue
with
imports
or
you
run
into
a
language,
constructs
feel
free
to
open
an
issue
or
see
see
the
working
group
I've
seen
it
done
a
couple
times
and
that's
great
I
get
a
heads
up
on
things.
I
would
have
had
no
idea
about
myself
cool.
Thank
you.