►
From YouTube: 2018-10-03 Node.js Foundation Modules Team Meeting
Description
A
A
A
B
B
Yeah,
it's
very
give
me
one
stack
so
so,
basically,
until
now
we
were
really
just
defining
normative
terms
and
I
thought,
because
we
are,
you
know,
dealing
with
very,
very
specific
operations
about
modules.
Then
we
might
want
to
go
a
little
bit
more
like
a
little
bit
deeper
in
our
definitions,
so
stiff
elusive
terms,
which
are
really
a
more
specialized
way
to
define.
Something
is
something
that
came
to
mind
and
basically,
what
I
tried
to
do
with
that
is
try
to
define
straight
ones
back.
B
It's
free
specific
to
what
we
all
agree
on
the
nice
thing
about
this
kind
of
definition
is
that
it
forces
us
to
agree
on
meaning
a
lot
more
in
a
lot
more
concrete
terms
than
we
just
then
simple,
normative
terminology.
So
I
guess,
if
people
can
get
it,
they
can.
You
know,
look
at
the
proposed
format
and
maybe
come
up
with
some
more
definitions
that
could
be
done.
This
way,
I
think
that
would
be
a
good
next
step
for
this
effort.
A
Excellent.
Thank
you
very
much,
a
quick
note
to
sneak
in
before
we
move
to
our
official
agenda
items
I'm
looking
at
the
list
of
people
on
the
call
there's
nine
of
them
all
the
people
who
are
on
the
call
right
now
are
people
who
have
been
fairly
active
in
attending
the
calls.
So
I'd
like
to
encourage
ten
of
you.
Thanks
for
the
heads
up,
West
I'd
like
to
encourage
any
of
you
who
are
on
the
call
who
are
not
currently
active
members.
A
I'm
gonna
set
a
fifteen
minute
time
box
on
the
first
discussion,
which
is
surveys
which
can
be
led
by
a
Salah
there's
three
issues
that
are
open
right
now.
In
developer
survey
survey
initial
drafts
serve
a
purpose
and
scope.
We
have
a
deadline
coming
up
next
week
of
node
interactive.
A
lot
of
us
will
be
there
in
person
during
the
week,
so
we
could
actually
have
time
from
you
know,
Tuesday
to
Thursday,
to
work
on
this
in
person
to
have
something
that
we
could
potentially
deliver
at
the
collaborator
summit.
A
B
I
was
hoping.
Other
people
would
also
get
a
chance
to
draft
their
own
few
questions
or
maybe
their
own
version
of
the
survey.
So
so
at
this
point
the
issue
is
really
outlined
where
how
it
can
be.
You
know
more
like
where
participation
can
take
place
worst
case
scenario.
We're
gonna
have
at
least
one
one
form
that
we
will
give
to
groups
of
three
or
four
or
four,
and
at
that
point
anyone
attending
can
help
moderate
groups
during
the
the
summer.
C
D
B
B
So
we
are
like
I'm
struggling
to
get
input
on
what
the
best
questions
that
everybody
else
wants
and
the
survey
would
be,
and
the
second
step
would
be
to
actually
frame
them
in
such
a
way
that
you
would
get
the
answer
that
you're
looking
for.
So
the
summit
will
definitely
help
point
out
really
bad
questions
that
get
very
bad
data,
but
also
give
us
feedback
on
how
to
better
ask
it
after
we
clarify
to
those
participating.
A
Excellent,
thank
you.
We
are
so
close
to
quorum
here
and
actually
in
the
process
of
pinging
people
on
Twitter
to
see
if
we
can
get
two
more
people
to
show
up.
I
think
that
we
can
move
forward
from
the
conversation
on
on
surveys
right
now,
unless
there's
anything
else
to
add.
So
is
there
anything
else
right
now?
Are
you
happy
moving
forward?
No.
B
A
Excellent
then,
that
kind
of
leaves
us
the
remainder
of
the
time
to
talk
about
the
minimal
kernel.
So
I
don't
know
how
closely
everyone
has
been
paying
attention
to
it,
but
we
have
to
open
bits
to
take
a
peek
at
for
this.
We
have
issue
180,
which
is
open.
It
was
quite
active
this
morning
of
identifying
and
documenting
the
first
phase
of
the
kernel,
and
we
have
pull
request
six
on
Ekman
script
modules
which
implements
it
and
implements
it
in
a
way
that
passes
all
the
testing
suites
and
is
kind
of
ready
to
land.
A
So
you
know
I'm
gonna
kind
of
leave
it
to
the
floor.
Do
people
have
thoughts
about
where
we're
at
I
guess
the
first
one?
That's
really
easy
to
ask
everyone.
You
know:
we've
got
11
people
on
this
call
right
now.
Does
anyone
have
any
objections
to
what's
currently
going
on
with
it?
Or
does
anyone
have
any
objections
to
moving
forward
with
it
right
now,.
E
A
Well,
I
mean
yeah,
let's
start
with
just
talking
about
like
actually
merging
these.
If
we
get
two
more
people
on
this
call
that
are
active
members
before
the
end
of
the
call,
we
can
actually
get
approval
and
land
both
of
these
pull
requests
and
then
I
think
we
should
spend
some
time
talking
about
what
people's
visions
are
of
Phase
two
and
their
thoughts
about
the
process
so
far
and
kind
of
what's
missing
from
phase
one.
F
I
guess
well,
while
you're
waiting,
I'm
trying
to
get
to
more
people
just
to
clarify
I,
don't
have
any
objectives
with
merging
either
of
these
I
wonder
if
maybe
some
people
who
haven't
attended
in
many
many
meetings
might
want
to
consider
going
down
to
like
observer
or
something.
So
we
don't
have
much
trouble
well
hidden
quorum,
but
maybe
that's
something
else
to
talk
about
later.
Yeah.
A
And
I
think
that
that's
definitely
I've
been
I've,
been
like
kind
of
quietly
reaching
out
to
people
one-to-one
for
the
people
who
have
not
been.
You
know
like
actively
engaging
it's
kind
of
it's
kind
of
tough
right
because,
like
on
one
hand,
you
want
to
be
fair
to
everyone,
but
on
the
other
hand,
if
like
people
are
just
not
responding
even
to
those
requests,
I'm
not
sure
what
we're
supposed
to
do.
A
So
it
is
possible
if
we
want-
and
perhaps
this
is
something
that
we
should
consider
drafting-
is
some
more
guidance
or
governance
around
attendance
and
participation,
and
you
know,
ironically,
we'll
need
to
have
quorum
to
land
that,
but
assuming
that
we're
able
to
get
quorum
for
it,
we
should
be
able
to.
It
looks
like
we
have
a
pull
request
open
to
make
Kevin
Smith
an
active
member
or
an
issue
up,
and
so
in
theory.
A
So
one
thing
I
wanted
to
point
out
and
I
think
Gus
you're
on
the
call
right
great
so
Gus
you're,
someone
who
I
wanted
to
talk
to
about
this.
So
in
the
minimal
kernel,
Enzo's
putting
it
together,
you
know
I
have
to
go
through
and
change
all
the
tests.
So
all
the
tests
that
were
originally
importing
common
jests
are
now
in
are
now
using
create,
require
from
path
and
I.
A
Don't
know
if
you've
gone
and
seen
the
examples
right
now,
but
I
find
working
with
it
currently,
not
extremely
organ
Amish,
because
to
actually
get
a
required
function
that
we
can
use
import
matter
require
is
going
to
give
us
a
string
file
like
a
five-year-old
URL.
That's
a
string,
it's
not
a
URL
object
and
if
we
just
pass
that
to
create
require
from
path
it's
not
going
to
work
because
our
path
objects
do
not
recognize
file
URLs.
A
We
then
have
to
bring
in
another
API,
which
is
like
URL
string
to
path,
which
is
another
API
that
just
like
got
exposed
recently.
I
think
it
was
God
I'm
totally
spacing
on
whose
PR
that
it
was
oh,
is
guy
dead.
Furred.
Thank
you
guy,
but
it
seems
really
not
organ
mcfar
long-term
solution
to
be
working
with
having
to
import
two
different
api's,
knowing
how
to
use
them,
knowing
that
they
exist
I
know
that
that's
not
like
the
solution
from
a
user
experience
standpoint
that
we're
gonna
want
to
ship
so
Gus.
A
The
question
that
I
wanted
to
pose
to
you
if
you're
up
for
talking
about
it
is
I,
know
that
because
FS
the
FS
stuff
got
blocked
and
didn't
end
up
landing,
yeah
Wes
just
pasted
it
in
the
chat.
Thank
you
very
much.
None
of
these
things
that
actually
landed
on
10.
Yet
none
of
these
api's
so
I'm
curious
Gus
of
seeing
like
how
this
API
needs
to
be
used
to
use
it
with
import
meta
URL.
Does
that
change
any
of
your
opinions
about
about
separating
the
front
path
from
the
from
URL?
A
Should
we
implement
from
URL
or
alternatively,
and
another
thing
I
was
thinking
about
it?
Should
we
look
into
adding
file
URL
string,
support
to
the
path
objects,
because
that
would
I
know
that
under
the
hood
create
require
from
path
is
using
path,
dur
names?
So
if
paths
that
her
name
started
to
support
file
URLs,
then
it
would
just
transparently
start
working
with
important
that
a
URL
I
guess
to
Gus
in
particular,
but
also
to
the
floor.
Has
anyone
had
any
thoughts
on
these
particular
api's
and
what
a
more
ergonomic
API
would
look
like.
A
G
Sorry
for
the
loud
environment,
so
the
ergonomics
of
like
I've,
never
personally
considered
this
pattern
to
be
something
we
should
ship
just
because,
like
I
mean
the
issue
that's
coming
up
now,
like
personally.
My
money
right
now
is
on
the
thing
that
guy
is
working
on,
which
is
dynamic
modules
and
then
we'll
never
need
to
worry
about
this
ever
at
that.
G
E
G
A
G
G
Have
to
check
that,
but
if
it
is
not,
that
could
be
a
solution
we
take
and
if
it
is
I
think
that's
probably
like
in
like,
from
my
perspective,
I
think
it's
fine,
if
that
is
the
case
I'm
just
like
reading
through
this,
to
see.
Okay,
so
yeah,
it's
just
exposed
to
state
require
so
like
the
area
outside
we
can
do
create,
require
from
URL
and
then
just
like
use
that,
like
again
I,
don't
like
personally
I,
don't
see
this
as
like
best
solution,
or
at
least
the
default
solution.
G
A
Yeah
I
guess
I
guess
the
thing
is,
and
maybe
I
could
be
wrong
on
this,
but
I
have
a
distinct
feeling
that
we're
not
going
to
be
seeing
extremely
fast
iterations
on
this
right,
like
it
means
you
think
you
were
meant
to
get
get
that
stuff
standardized
at
q39
for
dynamic
modules
at
the
very
least,
and
so
I
do
think
that
we
need
some
sort
of
some
sort
of
process.
Okay,
so
hold
on
one
second
quickly.
A
A
A
A
A
So
I'll
just
update,
we
had
guy
joined
right
at
the
end
guy,
we
were
on
hey
Matteo,
thanks
for
joining
the
table
to
update
you,
we
just
reached
consensus
tool
and
all
the
things.
So
it's
great
guy,
we
were
just
talking
about
the
ergonomics
of
create,
require
from
string,
Matteo,
I'm
sure
this
is
something
that
you
would
be
interested
in
as
well.
I've
just
pasted
the
current
boilerplate
that
we
need
to
get
a
require
function
inside
of
the
ESM
in
the
minimal
kernel
right
now
require
from
path
has
not
landed
in
a
node
release.
A
Yet
neither
has
the
URL
string
to
path.
So,
if
you
take
a
look
at
this,
this
is
a
lot
of
Hoops
to
jump
through,
and
it's
a
kind
of
thing
that
I
think
most
people
would
want
to
do
so.
The
question
was
kind
of
like
are
these
API
is
that
we
actually
should
be
looking
at
landing
on
10,
or
should
we
be
kind
of
doing
an
emergency
PR
to
change
the
API
before
it
goes
out
in
a
release.
H
So
my
impression
on
this
one
was:
we
were
gonna,
have
two
functions,
create
require
from
path
and
H
require
from
URL,
where
the
create
require
from
URL
would
be
the
one
that
would
create
the
ergonomics
for
this
situation.
As
far
I
recall,
we
could
so
that
the
suggestion
was
instead
of
implementing,
create,
require
from
URL
into
core
that
that
could
go
into
the
minimal
kernel.
So
that's
it
doesn't.
H
I
H
A
F
So
I'm
not
opposed
to
any
of
these
things,
I
just
kind
of
wanted
to
raise
a
question.
It's
like
it
seemed
I
thought
that
people
were
still
like
intending
generally
for,
like
the
the
new
modules
implementation
to
have
an
import
statement
being
able
to
import
either
ESM
or
command
is
in
some
form
now,
whether
we,
in
other
words,
to
try
to
get
to
the
author
driven
to
Sam
beauty.
That
seems
to
be
that
we
have.
That
would
be
something
else.
While
we
have
quorum.
Do
we
have
consensus
on
that?
F
We
want
author-driven
to
see
a
huge
disambiguation,
but
anyway.
So
my
question
is
assuming
we
do
want
that
and
assuming
that
that's
probably
going
to
be
through
an
import
statement,
then
what
is
the
use
case
for
these
create
require
functions
like
they
seem
cool
I,
don't
mind
that
they
exist.
They
just
give
you
another
way
to
import
commonjs
into
an
ESM
environment,
but
you
know
like
I
I,
just
don't
understand
where
they
fit
in
I.
Guess
that's
my
question.
G
So
the
original
reason
that
I
made
this
create
require
function.
Petar
was
not
actually
even
for
Interop,
it
was
for
tooling,
and
the
Interop
thing
kind
of
fell
out
of
that
people
were
like.
Oh,
we
could
use
this
and
I
think
it's
a
it's.
It's
a
good
tool
for
that,
but
it
was
like
the
reason
that
it
exists
is
not
specifically
for
this
purpose.
It's
just
one
of
the
use
cases
of
it.
F
G
J
A
Ok,
excellent,
so
maybe
one
of
the
things
that
we
can
break
off-
and
this
has
me
like
it-
was
actually
one
of
those
things
where
I
started.
Hacking
on
the
kernel,
I
immediately
kind
of
got
excited
when
working
with
this,
like
kind
of
obtuse,
API
he's
like.
Oh,
my
god,
it's
a
really
clear
first
thing
for
us
to
work
on
next.
A
Has
anyone
else
had
a
chance
to
like
kind
of
look
through
or
play
with
the
kernel
or
go
through
anything?
Is
there
anything
that
feels
really
under
ganar
there
specific
things
that
you
want
to
bring
forward
as
part
of
phase
2?
And
how
should
we
do
things?
Should
we
be
doing
it
piecemeal,
or
should
we
be
trying
to
put
together
a
document
that
we
reach
consensus
on,
like
we
did
with
phase
1
I.
A
J
And
yes,
I
said
to
answer
your
question
is:
should
we
do
this?
You
know
doc
or
just
implementation.
It
seems
clear
to
me
that
the
things
that
need
to
be
resolved
are
not
really
coding
issues
and
therefore
it's.
We
definitely
need
a
Docs
to
define
these
things.
First,
it's
the
most
accessible
way
of
getting
everyone's
input.
J
A
F
So
I
don't
have
objection
to
that.
I
was
just
gonna
paste
and
there
was
that
one
pull
request
that
I
had
started
about
the
the
mime
type
map
thing.
That's
already
pretty
much
documented
out.
So
unless
there's
any
more
feedback,
people
wanted
to
give
to
it
or
discussion
that
anyone
feels
like
it
needs.
That
could
be
something
that
maybe
move
either
moves
into
the
document
or
turns
into
a
PR
I.
Think
you
want.
A
F
Mean
that
was
the
point
of
that
that
PR
and
the
one
and
the
issue
that
preceded
it.
They
were
like
six
or
eight
options
that
people
went
through
and
gave
feedback
on
and
voted
towards.
So
I
mean
you
can
look
through
those
to
see
if
any
of
those
other
options
seem
better
to
you.
I
know,
for
anyone
wants
to
propose
anything
else,
but
I
mean
there
were
a
whole.
Several
people
that
went
through
that
and
tried
to
try
to
reach
a
consensus
on
the
design
for
this
mm-hmm.
B
A
H
Yeah
I
just
want
to
say
in
terms
of
process
I
think
like
since
we're
starting
with
the
minimum
kernel
and
then
our
gonna
add
in
effectively
features
I,
guess
it.
You
know
instead
of
trying
to
like
I,
don't
know
how
much,
how
much
scope
you
want
to
put
behind
face
to,
but
you
know
try
to
go
for
those
small
wins.
H
A
Individual
proposal
that
I
think
we
could
or
should
explore
you
know
kind
of
depending
on
how
we
want
to
do
it
would
be
we
stripped
out
not
only
the
phone
load
resolution
algorithm,
but
also
package
package
main,
so
perhaps
that's
another
one
that
we
can
start
kind
of
by
shedding
on
is
like.
Do
we
want
to
support
kind
of
unnamed
main,
whether
or
not
the
it
is
named
main
in
in
modules
that
are
in
the
node
modules
folder?
Do
we
want
it
to
be
main?
Do
we
want
it
to
be
module?
A
Rob
commented
in
here
about
loaders
in
Phase,
two
I
know
for
a
fact
that
there's
at
least
three
different
people
that
are
exploring
loaders
in
depth
right
now
and
I
think
it
would
be
a
good
idea,
perhaps
maybe
in
the
next
meeting,
even
if
we
can
to
get
you
to
those
people
to
give
us
presentation
about
how
they
view
loaders
and
what
their
proposal
is
for
implementing
and
running
loaders
in
the
on
top
of
the
new
kernel.
Any
specific
thoughts
around
that.
A
That
seems
pretty
ripe
to
me
because
I
think,
once
we
figure
out
our
loader
story,
we
can
then
make
the
decision
on
all
the
other
hard
decisions
that
we
can't
really
reach
consensus
on,
based
on
how
the
loaders
themselves
work,
but
I'm
sure
that
we
can
reach
consensus
on
a
couple
of
UX
things
that
don't
really
you
know
affect
future
proposals,
make
a
couple
fast.
Small
wins
would
feel
really
great.
B
Yeah
I
think
now
that
we
have
everything
stripped
out.
One
problem
I
was
struggling
with
with
the
experimental
modules
was
there
were
some
optimizations
that
were
baked
in
into
the
module
wrap
itself,
but
then,
if
I'm
using
a
custom,
loader
then
I'm
implementing
everything.
You
know
JavaScript
side
at
this
point
that
creates
a
you
know
like
a
it's
hard
for
us
to
design
a
good
module
system.
If
our
module
loading
is
done,
you
know
in
module,
wrap
and
then
we
expect
user
loaders
to
be
JavaScript.
B
So
I
think
what
I'm
trying
to
say
is
that
we
should
have
really
like.
We
should
see
how
efficient
it
will
be
to
do
it
in
JavaScript,
because
if
it's
not
going
to
be
efficient
enough,
then
no
matter
how
good
an
API
for
a
loader
is
going
to
be
offered.
Maybe
it's
not
going
to
be
that
useful
if
it's
not
going
to
be
possible
without
module
wrap
optimizations,
because
once
once
you
can't
use
those
optimizations,
then
your
Lord
is
really
going
to
be
at
a
disadvantage
from
the
get-go.
So.
L
It
might
have
been
the
same
question
just
what
do
you
mean
by
good
enough
because,
like
babel,
node
and
TS
node
and
all
those
other
things
are
currently
considered
good
enough
by
a
number
of
people,
even
though
they're
very,
very
slow,
so
I
guess
my
instinct
is
that
that
bar
is
is
very
low.
It's
very
easy
to
clear
the
performance
requirement,
but
like
what
was
your
criteria
for
good
enough.
B
So
I
guess
it's
just
pointing
pointing
out
the
fact
that,
like
I
I
do
realize
that
using
tooling
today
you
can
the
same.
You
can
get
really
good.
You
know
performance
aspects,
but
but
then
people
working
on
module
rap
have
certain
expectations
for
performance
and
I
think
to
them
they
would
be
better
qualified
to
say
what
is
good
enough.
B
But
if
module
rap
needed
to
resolve
packages
and
and
do
all
that
work
outside
of
JavaScript,
then
it
was
that
due
to
the
fact
that
it
would
it
be
that
wouldn't
be
good
enough
in
JavaScript
side
or
was
it
just
part
of
the
experimental
aspect?
See
like
I,
really
don't
have
the
answers,
but
it
just
these
were
questions
that
I
kept
asking.
You
know
when
I
looked
at
the
code,
so.
B
At
least
make
sure
that
that
making
a
loader
in
JavaScript
will
be
as
efficient
as
if
we
end
up
relying
on
mod
your
app
for
resolving
things,
then,
then
you
should
find
a
way
to
make
sure
that
loaders
written
in
JavaScript
can
be
as
efficient
at
least
just
consider
it.
You
know
whatever
whatever
solution
will
end
up
coming
from.
This
is
very
premature
at
the
moment,
but
just
keeping
in
mind
that
if
someone
is
doing
it,
a
JavaScript
purely
JavaScript
loader,
then
how
can
we.
A
I
could
take
one
of
it.
Okay,
I
know
for
a
fact
that
you
know
at
least
two
of
the
people
that
I've
talked
to
that
are
working
on
exploring
different
loader
implementations
performance
is
a
very
high-level
concern
and
allowing
people
to
write
loaders
that
are
efficient
is
definitely
you
know
something
that
they
want
to
do.
B
A
J
Rob,
you've
got
your
hand
up
and
yeah
I
just
wanted
to
point
out,
I
think
when
I
heard
people
talk
about
loaders
so
far,
they've
talked
about
using
them
to
experiment
with
different
types
of
resolution.
Different
types
of
transformation,
so
I
think
then
being
slow.
At
least
at
this
stage
is
absolutely
fine
and
and
also
I
think
that
potentially
we
can
use
this
with
a
definition
of
our
next
deliverable,
maybe
their
end
of
stage
two
and
in
the
stage
three
which,
which
is
that
we've
we've
now
agreed.
J
We've
now
got
consensus
on
on
what
we
what
we
have
agreement
on.
So
we
have
our
shared
base
of
decisions
and
the
tough
part
is
going
to
be
deciding
on
those
things
that
are
not
easy.
The
things
where
we
start
excluding
things
and
I,
think
the
there's
an
intermediate
stage
between
those
two
points
which
is
perhaps
when
we
have
loaders
that
allow
the
full
experimentation
of
what
those
difficult
decisions
might
be.
J
Is
that
the
some
people
that
that's
a
usable
end
state
and
having
having
that
base
plus
fully
flexible
loaders
that
that's
in
a
position
to
try
lots
of
things
out
and
that
can
then
inform
the
follow-on
phase
of
taking
those
difficult
decisions?
But
please
please
ask:
if
are
not
clear
and
do
I
just
outlined
there.
A
A
If
we
assume
that
phase
three
is
loaders
and
phase,
two
is
all
the
things
that
we
don't
need
loaders
to
make
decisions
on
and
face
for
all
the
decisions
we
make
after
we
have
the
loaders
you
may
be
even
in
a
place
where
we
can
make
a
pull
request
against
core
after
phase
three
to
update
the
experimental
modules
implementation,
to
give
the
ecosystem
a
chance
to
experiment
with
various
different
loaders
and
to
try
to
figure
out
what
kind
of
defaults
we
want
to
include
so
I.
You
have
your
hand
up.
B
Yeah
just
coming
browser
Interop
moving
on
to
the
next
phases,
I
think
it's,
it's
always
important
to
ask
what
a
loader
and
a
browser
could
look
like
and
III
put
it
this
way,
because
I
know
that
there
were
attempts-
and
there
are
still
attempts
to
you
know,
find
ways
to
maybe
support
their
specifiers
and
so
on.
I'm,
not
gonna,
name
particular,
you
know
attempts
but
I
guess.
We
can
also
keep
it
in
mind
that
while
we
try
to
design
the
infrastructure
for
loaders,
we
should
consider
if
this
was
in
a
browser.
B
What
would
it
look
like
just
consider
if
you
know
if
it
would
be
a
security
concern
or
not?
Maybe
not
not,
have
it
have
it
ties
down
out
and
our
design,
but
just
if
we
can
find
a
design
that
can
lend
itself
to
a
browser
standard
that
would
be
really
good
for
the
community
in
general.
For
you
know,
the
JavaScript
community
in
general.
F
Jeff,
you've
got
your
hand
up,
hey,
yeah,
so
I
think
I
agree
with
your
general
proposal.
Miles
of
yeah
phase
two
is
is
whatever
little
things
we
I
mean.
We
don't
really
need
phases,
I,
guess
at
this
point
like
we
could
just
start
merging
in
pull
requests
for
you
know
anything
that
doesn't
require
loaders.
F
That
has
some
I
think
we
have
some
work
to
do
there
like
research,
like
the
package
name
ass
proposal,
fleshing
that
out
doing
something
else
instead
of
it,
I
don't
know,
but
we
should
maybe
think
about
like
whoever's
interested
in
that
to
try
to
flesh
out
like
a
design
for
that,
so
that
by
the
time
loaders
are
in,
you
know
we
could
start
shifting
to
that
and
then
for
loaders.
We
should
I.
M
M
M
A
L
So
both
tinker
cruise
or
whatever
NPM
calls
their
things,
and
that
thing
now
and
yarn
plug-and-play
are
both
really
they're
experimental
things
they're
brand
new.
They
both
will
break
the
ecosystem,
definitely
already
break
the
ecosystem
in
lots
of
ways
and
are
trying
to
figure
out
how
to
avoid
doing
I.
Don't
even
think
that
they're,
it's
necessarily
an
automatic
thing
that
getting
rid
of
node
modules
is
a
good
thing.
L
So
like
it's,
it's
useful
to
be
aware
of
them,
and
everyone
involved
in
the
working
group
I
should
absolutely
read
up
on
on
both
of
them,
but
I
think
it
that
we
should
not
assume
that
the
node
CJ
s
module
resolution
algorithm
and
node
modules
is
going
away
in
the
next.
Let's
say
five
years,
I
expect
it
will
take
much
longer
than
that
to
actually
effect
such
a
change
in
the
system,
but
I
think
that
that
loaders
should
already
are
and
should
be,
should
remain
a
way
to
implement
whatever
ends
up
The
Comedians
of
wanting.
K
Yeah,
so
my
kind
of
philosophical
approach
is
that
this
is
a
pretty
exciting
time
to
be
involved.
There's
lots
of
ideas
all
in
the
air
and
people
are
experimenting
and
all
kinds
of
directions
and
yeah.
We
should
enable
and
encourage
experimentation
via
loaders,
and
then
you
know
we
can
see
what
works,
and
then
you
know
using
using
that
that
information
from
promote
that
experimentation,
you
know
figure
out
a
good
plan.
A
Take
the
lack
of
hands
as
an
opportunity
to
speak
my
mind
yeah
like
so.
What's
the
saying
in
here
seeing
these
maps
a
separate
relationship
resolution
is
true
but
unhelpful,
they're,
more,
like
incremental
caches
and
I.
Think
I
agree
with
that.
To
an
extent
I
mean
like,
if
you
look
at
how
P
NP
is
implementing
things
they're
going
in
to
require
extensions
and
they're
kind
of
hijacking
require
itself.
What
I
think
that
these
patterns
are
showing
and
I
think
that
this
is
what
what
George,
which
Jeff
was
saying
was.
A
These
are
just
showing
patterns
that
people
want
to
be
experimenting
with
the
way
the
things
work
and
I
think
that
we
definitely
should
be
enabling
that
experimentation,
especially
when
that
experimentation
is
doing
things
like
potentially
improving
cold
boot
time
for
node
running
containers.
I
do
think
that
there's
kind
of
two
different
questions
going
on
here
to
a
certain
extent,
and
one
is
like
what
kind
of
infrastructure
do
we
make
available
to
people
to
customize
the
experience
of
node
versus
what
are
nodes,
defaults
and
I?
A
Think
in
in
general,
I'm
hearing
a
collection
of
people
wanting
to
move
more
towards
the
former
than
the
latter
and
I
think
that
would
be
a
wise
move
for
us
right
now.
So
it's
like
I
think
we
collectively
all
work
on
like
creating
a
loader
system
that
we
could
all
build.
Our
ideal
implementations
with
we
should
be
able
to
from
that
derive
the
hard
decisions
or
potentially
even
not
make
decisions.
A
A
It
seems
like
one
of
us
should
take
an
action
item
to
document
the
future
phases.
Would
anyone
like
to
volunteer,
for
you
know,
just
opening
an
issue
taking
over
some
of
the
thoughts
of
what
we
had
happen
in
today's
discussion
about
kind
of
like
phase
1
phase
2
phase
3
phase
4?
Can
anyone
take
an
action
on
that
yeah
I
can
okay.
A
I'll
definitely
try
Ninh
we're
gonna.
Have
the
ability
for
an
in-person
meeting
next
week
at
interactive
I
will
get
the
exact
time
that
our
session
is
scheduled,
so
people
can
dial
in
but
I
we're
not
going
to
be
running
our
regularly
scheduled
weekly
meeting
and
we
will
not
be
doing
the
following
weeks
or
a
next
meeting
will
be
on
August
24th.
A
If
anyone
has
any
issues
with
that,
let
me
know,
but
I
just
want
to
kind
of
stick
to
our
original
schedule
and
not
just
shift
the
weeks
as
they're
running
right
now.
Guy
you
have
three
minutes.
Do
you
want
to
do
you
want
to
try
to
quickly
in
three
minutes
tell
us
about,
or
they
say,
August
I
meant
October
once
they're
hard
guide.
You
have
two
seconds
to
tell
us
about
high-level,
weird
I've,
the
dynamic
lateral
stuff
like
to
a
tc39
I.
A
H
High
level
of
timeline
well
at
the
moment,
the
bottleneck
is
actually
where
we've
moved
to
implementation,
so
the
bottleneck
is
C++
developments.
If
anyone
is
interested
in
helping
out
if
anyone's
good
with
C++.
Please
comment
on
the
the
modules
issue
that
I
created
on
the
node,
no
J's
modules
issue
tracker
I
ready
to
have
help
going
through
it.
Gus
is
already
helping
me
with
swords,
but
just
trying
to
make
it
happen
at
the
moment,
however,
with
with
the
little
time
I
have
as
well
so
yeah,
any
app
would
be
very
welcome.
A
Excellent,
thank
you
very
much.
What
two
minutes
left?
Let's,
let's
end
this
meeting
early,
you
know
stop
the
stream
now,
thank
you
for
tuning
in
or
actually
maybe
we
should
check
this
stream
really
quickly
see
if
there's
any
questions.
Thank
you
very
much
now
the
chat
looks
she
looks
super
empty,
oh
cool.
Let's
turn
the
screen
off
and
call
it
a
day.
Thank
you.
Everyone
for.