►
From YouTube: Node.js Foundation Modules Team Meeting - 2018-04-25
Description
A
B
A
As
per
usual,
YouTube
is
open,
willing,
saying
this:
we've
got
some
fun
feedback.
We
currently
have
quorum
with
meeting
with
members
of
modules
teams.
Since
the
last
meeting,
14
members
have
moved
to
an
observer
status
which
allows
us
with
14
members
in
the
meeting
today
to
reach
quorum
to
make
decisions.
So
we
have
a
current
agenda
today,
which
starts
with
approving
some
PRS.
The
first
PR
that
we
have
to
approve
is
number
66.
This
is
the
PR
that
updates
the
membership
for
all
the
members
that
have
moved
to
observers.
A
Okay,
I
have
rebased
and
merged
it
now,
something
that
was
brought
up
by
Jordan.
Our
band
was
that
membership
updates
if
they
have
to
do
with
updates
that
don't
require
approval
such
as
moving
people
to
a
to
an
observer
status.
He
was
saying
it
maybe
makes
sense
for
us
to
not
have
to
wait
until
a
meeting
to
approve
those
changes.
Does
anyone
object
to
adding
some
language
to
our
governance
that
allows
for
that.
A
We
have
no
objections
if
whoever
is
taking
the
notes,
if
you
can
make
a
note
that
I
will
take
the
action
item
of
drafting
that
and
getting
something
in
the
next
three
pull
requests
that
we
have
our
number
64
number
53
and
number
50.
They
are
all
meeting
notes
for
prior
meetings.
Does
anyone
have
any
objections
to
landing
any
of
those
pull
requests?
I
have.
A
A
Okay,
great,
so
I
have
landed
due
to
pull
requests
that
have
the
notes
that
are
that
are
that
are
approved
and
then
Gus
I
will
leave
number
53
to
you.
Also
keep
in
mind,
guess
one
thing
we
do
have
in
our
governance
that
sending
any
sort
of
errata
changes
can
be
landed
without
consensus.
So
we
could
theoretically
land
that
pull
request
and
then
send
a
new
one
to
fix
the
errata
in
the
future,
but
without
needing
approval
at
a
meeting.
But
I
will
wait
for
you
for
that
one.
A
A
So
if
we
take
a
look
at
the
membership
rules
and
what's
going
on
here,
it
expands
upon
the
membership
types
and
makes
it
explicit
definition
between
active
members
and
observers.
It
defines
the
roles
of
those
two
observers
and
to
be
explicit
about
that.
Active
members
are
invited
to
all
meetings,
can
participate
in
the
consensus
seeking
process
and
are
counted
towards
quorum
in
team
meetings
and
participate
in
voting.
Observers
are
invited
to
all
meetings
can
kiss
apey
tin.
The
consensus
seeking
process
are
not
counted
towards
quarantine
meetings
and
cannot
participate
in
voting.
A
If
you
look
at
our
our
bit
on
consensus
seeking
it,
that
has
the
notes
about
what
the
consensus
seeking
process
is,
and
so
essentially
what
this
boils
down
to
is
that
for
a
meeting
like
we're
in
right
now,
when
we
call
for
objections,
observers
are
totally
able
to
object
in
pull
requests.
Observers
are
also
similarly
able
to
object
the
only
time
we're
an
observer
is
that
any
sort
of
a
different
capacity
for
participating
is
if
we
cannot
reach
consensus
when
they're
in
an
objection.
If
it
goes
to
a
vote,
an
observer
doesn't
have
a
vote.
A
A
Great,
so
we
now
have
an
explicit
process
in
place
for
adding
new
observers,
which
is
our
next
point
of
order.
So
we
have
three
people
who
have
applied
to
be
observers.
They
are
all
with
us
today.
There
have
been
no,
you
know,
pushback
in
the
meeting
in
the
PRS
themselves.
We
have
a
pull
request
open
to
add
jeffrey
booth
as
an
observer,
a
pull
request
to
add,
spend
as
an
observer
and
a
request
to
add
smote
all
as
an
observer.
So
one
of
the
time
are
there
any
objections
to
adding
Jeffrey
as
an
observer.
A
Okay,
so
the
motion
passes
and
Jeffrey
is
now
an
observer.
Is
there
any
objection
to
adding
spend
as
an
observer?
Okay,
with
no
objection
spent
spending
has
been
added
as
an
observer.
Is
there
any
objections
to
adding
salah
as
an
observer,
excellent,
so
I
will
take
care
of
adding
them
all
properly
to
our
membership.
Can
I
just
get
pre-approval
for
landing
the
pull
request
that
adds
them
all?
A
The
two
there
wasn't
one
for
Salah,
so
I
just
wanted
to
make
sure
that
it's
done
and
we
can
work
on
trying
to
improve
this
process.
If
anyone
thinks
that
this
can
be
improved
upon,
we
do
have
a
base.
Governance
talk!
That's
in
there
now
that
outlines
this
exact
process.
Please
feel
free.
If
you
want
to
make
it
issues
rather
than
pull
requests
anything
that
you
do,
that
we
think
can
improve
this
process,
I'm
open
to
it,
just
trying
to
make
it
ER
ative
improvements,
as
we
do
have
three
new
observers:
Jeffrey,
Sven
and
Salah.
E
B
B
Have
two
faces
here
so
I'm
working
on
baby,
where
I
think
Tom's
fighting
is
a
bit
part
of
the
rescue
pod
just
because
people
are
already
using
it
and
they
are
using
it
by
transpired.
Same
two
commands.
Yes,
so
I
think
it's
a
good!
That's
an
important
part
of
cesky
mother's
life,
also
I'm
working
on
the
JavaScript
modules
implementation,
where
it
integrates
where,
with
web
assembly
and.
A
A
C
Hi
everyone
so
basically
I
have
a
very
long
history
with
JavaScript
back
in
the
day
when
modules
were
not
even
a
concept
and
then
I
went
to
print
color
signs,
image,
processing
and
eventually
to
JavaScript
I,
found
that
the
idea
of
open
source
being
able
to
open
a
file
and
just
make
changes
and
see
that
reflected,
got
lost
somewhere
along
the
way
on
I,
appreciate,
building
tools
and
tooling.
C
But
I
really
find
that
it's
counterintuitive
when
you
think
of
JavaScript,
if
you're
from
the
old
days
right
now,
I'm
trying
to
create
something
similar
to
a
for
GL
environment
for
image,
processing,
which
basically
just
uses
modules,
and
it
has
been
an
extremely
educational
experience,
trying
to
keep
up
with
all
the
changes
and
also
seeing
how
everyone
is.
You
know
absorbing
a
standard
that
it's
been
out
there
since
2015
I,
guess
I'm,
really,
you
know
happy
to
be
observing
I'm,
also
able
to
help
if
anybody
needs.
A
Now
that
we've
gotten
through
all
the
all
the
stuff,
we
have
two
main
agenda
items
to
dig
into
today,
one
we
could
decide
to
punt
on
I
just
didn't
want
to
remove
the
label,
which
was
the
cash
system
mismatch
with
web,
and
then
the
next
one
is
digging
into
more
use
cases
and
features.
So
the
castmates
mismatch
with
web
is
number
62
and
was
open
by
Brad
and
I.
Believe
John
Dalton
was
also
heavily
involved
in
this
as
well
John.
Do
you
and
I
mean
gets
to
everyone?
Does
anyone
think
that
we
should
skip
this?
A
A
A
F
Okay,
so
last
week
we
transitioned
from
reviewing
and
use
cases
to
taking
those
use
cases
and
pulling
out
features
from
them.
During
this
exercise,
we
tried
to
keep
a
yes,
an
attitude,
so
we
weren't
blocking
or
saying
no
to
features.
We
were
just
trying
to
explore
what
features
are
sussed
out
of
the
use
cases.
We
did
those
the
feature
of
additions
during
the
meeting
and
the
time
between
the
two
meetings.
E
E
Alright,
so
I
added
36
through
41,
which
is
only
five
cuz
if
we
skip
time,
39,
36
and
37
are
basically
very
similar
like
they're
like
37,
is
what
what
really
happened
to
me
and
then
I
tried
to
write
it
as
a
generic
version
in
36.
So
the
idea
is
well
I'll
start
with
the
real
word
1.
So
CoffeeScript
is
a
common
Jas
module
and
the
way
it's
tests.
E
E
Is
assuming
that
the
starting
point
is
a
file
for
37
because
of
this,
because
the
actual
starting
file
is
already
CoffeeScript,
the
transpiler
will
convert
it
into
JavaScript.
The
thing
gets
evaluated
as
a
string.
I
think
that's
it.
That's
deserves
to
be
its
own
use
case,
even
besides
CoffeeScript,
because
you're
still
gonna
have
that
with
babel,
like,
as
you
know,
es
2019
and
es
2020
and
so
on.
Pushes
forward
and
people
want
to
keep
using
these
things.
E
You
know
they'll
keep
using
babel
even
beyond
you
know
when
we
get
the
transition
figured
out
with
yes
modules.
So
you
know,
wherever
you
see,
CoffeeScript
mentioned
just
assume
that
you
could
like
drop
the
word
Babel
in
there
instead
and
it'll
have
the
same
problem
essentially
or
it
could
I
mean
depending
on
how
so
that's
those
two,
the
38.
E
The
real-world
case
of
this
is
CoffeeScript,
has
a
coffee
command
which
is
meant
to
mimic
the
node
command
so
like
just
as
in
you
in
node,
you
can
do
like
node
eval
and
then
a
string
and
that's
a
node
will
just
like
parse
it
and
execute
it.
You
have
the
identical
thing
in
CoffeeScript.
All
the
CoffeeScript
is
doing
is,
takes
the
string
trans
piles
it
into
JavaScript
and
then
spawns
the
node
process
to
execute
it.
E
There's
no
way
like
right
now
in
node,
there's
no
way
to
run
this
example
in
38
like
note,
eval,
import
path
from
path,
console
log
paths
at
SAP,
because
there's
no
there's
a
file
name
so
that
the
whole
life
needing
and
MJS
extension
to
is
the
as
the
out-of-band
way
of
telling
node
what
to
do
doesn't
work
in
this
case,
and
it's
probably
not
a
good.
You
know
the
package
that
jason
version-
probably
isn't.
Such
a
good
solution
well
actually
get
away
from
potential
solutions
anyway.
E
This
is
a
there's
no
way
to
do
this
right
now.
There
are
use
cases
where
you
would
want
to
do
this,
like
the
one
I
just
mentioned,
but
imagine
any
other
tools
that
can
that
convert
from
anything
into
JavaScript
and
want
to
execute
it.
You
know
they
might
not
know
the
tool.
That's
that's
doing.
The
converting
might
not
know
what
the
form
the
input
takes,
which
module
format
it
is,
and
so
it
might
not
be
a
way
for
it
to
tell
node
what
to
do,
etc.
E
Number
forty
is
this
is
more
just
about
user
experience
in
general.
I
opened
a
separate
issue
just
talking
about
this
in
general.
To
be
like
you
know,
yes,
we
have
use
cases
and
it's
sort
of
like
there
are
many
ways
to
solve
these
use
cases.
You
know,
like
the
current
experimental
modules.
Implementation
solves
a
lot
of
these
use
cases,
but
what
I
was
trying
to
get
at
was
that
it's
not
just
that
they
get
solved.
E
The
more
angry
users
we're
gonna
have,
and
so
I
just
wanted
to
have
that
conversation
or
I,
don't
know
where
that
fits
in.
If
that's
a
use
case
or
if
it's
a
goal
or
if
it's
a
feature
of
our
matter,
what
it's
so
something
I
want
us
to
really
consider
as
we're
evaluating
implementations
down
the
line,
how
to
how
to
build
these
things.
So
this
is.
This
is
meant
to
be
a
specific
example
of
that
of
someone
has
important
export
statements
in
an
app
just
leave
out
commonjs
for
now
other
than
requiring
dependencies.
E
E
My
apologies,
if
I
do
prefer
here,
that
just
means
that
it's
all
the
more
common
I
suppose
and
the
last
one
and
then
I'll
finally
stop
talking
is
that
I
in
the
CoffeeScript
module
there
are
require
statements
that
they're
not
quite
in
if
blocks
but
they're
in
there
in
functions
and
depending
on
which
function
gets
run
at
the
start,
certain
other
things
get
required.
So
we
don't
have
just
like
a
huge
block
of
require
statements
at
the
top
of
the
file.
We're
only
requiring
certain
dependencies
like
as
needed
and
I.
E
Don't
really
want
to
refactor
a
CoffeeScript
to
not
be
structured.
This
way
and
I'm
sure
other
people
will
will
have
the
similar
thing
I
mean,
even
if
even
if
refactoring
is
easy
or
desirable,
there
are
going
to
be
people
that
just
don't
want
to
refactor
their
modules
for
whatever
reason,
but
do
have
modules
that
are
like
commonly
depended
upon
by
other
things.
E
F
F
E
E
H
F
I
F
I
Yeah
CJ,
this
is
I,
think
M
is
M
importing
CJ
s.
D
Yeah
I'm
here
sweet
yeah
so
that
the
first
one
is
pretty
much
just
stating
the
obvious,
but
I
just
wanted
to
get
it
down
in
writing.
So
we
can
make
sure
it's
kind
of
I
mean
I
know
it's
discussed
a
number
of
times
so,
basically
just
to
say
like
full
backwards
compatibility
of
the
CGS
system
alone.
So
just
to
make
that
super
super
clear
and
in
writing,
and
then
number
22.
D
You
know
we're
not
specking
it
or
providing
it,
but
it
should
be
possible
like
it
should
be
clear
how
people
are
going
to
be
building
for
the
browser,
given
the
way
that
node
works.
So
just
yeah
kind
of
trying
to
put
that
into
writing
that,
like
the
way
the
we
load
between
the
format's
must
support
being
built
for
the
browser
and
it
shouldn't
break
or
have
funny
edge
cases
when
you
do
that
that
suddenly,
someone's
gonna
find
in
some
scenario
of
circular
references
codes,
gonna
break
because
it
can't
run
in
the
browser.
The
same
way.
F
F
B
F
F
E
D
Mean
it
might
be
worth
being
more
specific
here
because
there's
a
lot
under
browser
compatibility
and
saying
specifically
here
that
the
idea
is
that
you
should
be
able
to
build
a
single
file
of
say
you
have
an
app
consisting
of
common
GS
than
ES
modules.
You
should
be
able
to
build
that
into
a
single
file
that
executes
under
the
same
semantics
in
the
browser,
just
like
we
do
with
common
J's
today,
so
the
same
executions,
the
forensics,
that
you
would
get
at
night
die.
Would
you
say.
D
Line
with
that,
or
is
this
so
that's
why
I
was
saying
like
a
single
file,
because,
like
I'm
trying
to
separate
this
from
the
resolution,
concerns
and
the
es
module
system
in
the
browser
entirely,
and
just
say
that
say,
you
know
how
if
you're
running
command,
Jason
node
and
you
have
you're
doing
things
with
your
bindings
and
your
circular
references,
that's
gonna
behave
the
same
in
the
browser
and
that's
why
all
bundle
is
for
the
Browns.
They
use
an
internal
registry
to
make
circular
references
work.
D
So
you
know
from
that
perspective
the
way
that
we
bundle
for
the
browser
is
trying
to
maintain
the
semantics.
So
just
saying
that
whatever
we
do
with
those
semantics,
there
should
be
a
part
to
make
when
bundle
to
the
browser,
and
we
should
be
at
least
aware
of
how
those
semantics
can
be
adapted.
Okay,
sorry.
E
Just
gonna
say:
I,
don't
I,
don't
know
if
this
is
necessary,
but
something
that
occurs
to
me
is
like
it's
as
far
as
interoperability
goes.
It
might
be
worth
talking
about
it
separately
in
terms
of
I'm,
making
a
module
whether
it's
CIC,
jester,
DSM
and
I
want
this
module
to
be
used
by
whatever
by
CJ
SPS
my
browser
versus
the
flipside
I'm
writing
an
app
and
I
want
to
import
any
SM
module
and
CGS
module.
I.
Don't
do
it
might
be
separate
features
in
a
sense.
You
know,
I
mean
yeah.
J
A
C
To
say
something:
yeah:
while
we're
talking
about
interoperability
with
browsers
the
biggest
pain
point
I
get
is
import
from
an
absolute
thing
like
path
or
FS.
I
know
that
it
doesn't
make
sense
to
load
a
module
that
has
a
specifier.
That
is
specifically
a
note
specifier,
but
they
do
happen
even
accidentally.
Hopefully,
and
once
that
happens,
it
breaks
off
any
module.
That
was
loading
the
module
that
was
loaded
by
mistake.
C
F
F
Just
because
there's
bear
imports,
there's
way
stories
or
all
of
that
guy
on
yours
feel
free
to
tweak
the
description
of
the
of
the
bullet
there,
because
I,
just
I
have
still
just
browser
compatible
path.
But
if
you
want
to
break
that
out,
feel
free
to
like
wordsmith
that
and
get
that
going,
do
we
have.
A
F
D
F
F
H
Yes,
okay
and
so
the
first
one
is
based
on
the
observation
that
people
do
and
people
don't
like
writing
long
list
with
flashed
on
top
and
would
like
a
well-known
convention
for
module,
specifies
that
are
relative
to
the
package
reached
and
so
in
the
ideal
world.
This
is
asking
for
a
convention
and
a
default
way
of
expressing
that.
F
H
F
H
Then
25
and
is
about
first
of
all,
offering
named
package
and
pre
points
as
opposed
to
the
Whydah
fault.
We
have
main
at
the
moment,
and
this
is
about
expanding
the
set
of
named
entry
points
you
could
provide
for
a
package
and
then,
following
that
up
with
some
kind
of
resolver
mode,
where
you
did
not,
I
subparts
into
a
package,
and
you
only
permit
people
to
import
anything
having
the
default
from
that
set
that
explicitly
declared
entry
wines.
E
Both
of
the
things
rob
has
just
mentioned
seemed
like
they
would
be.
Amazing
features
to
also
have
on
CGA
CJ
s,
even
if
he
SM
never
existed,
and
so
I
think
it
would
be
awesome
if
we
could
figure
out
a
way
to
explore
those
two
features
kind
of
in
parallel,
like
adding
them
to
CJ
s.
While
we
consider
how
that
will
be
impacted
by
the
work
we're
doing
in
this
group
would.
E
It
like
it's
around
encapsulation,
so
people
right
now,
for
example,
use
roll-up
to
bundle
up
their
entry
points
and
then
NPM
ignore
all
of
the
things
that
aren't
their
entry
points
so
that
they're
able
to
have
kind
of
hidden
internal
helpers
and
files
that
they
don't
have
to
consider
part
of
their
API.
And
it
would
be
great
if
there
was
a
feature
to
avoid
having
to
do
that
to
achieve
that
encapsulation,
in
other
words,
being
able
to
do
it
without
a
build
tool.
Yeah.
H
Yep,
okay,
so
are
we
done
on
talking
about
the
multiple
entry
points
and
package
encapsulation.
L
J
H
To
me,
I'm
at
know
about
package
encapsulation,
okay,
then
so
26
is
about
and
yeah
cut,
custom
resolution
again
and
I
could
be
more
precise
and
and
upgrade
this
to
say,
like
a
tiered
resolution
customization,
you
could
imagine
layering
this.
In
addition
to
other
other
kind
of
plugins
to
the
resolver.
H
F
F
F
F
A
D
F
C
I
just
wanted
to
say
maybe
having
a
universal
fallback
mechanism,
basically
a
way
to
gracefully
handle
fallback
that
does
not
require
script
tag
with
a
no
script
or
no
module
or
whatever
something
that
can
actually
be
a
one-size-fits-all.
If
it
fails
in
a
browser,
the
fallback
would
be
to
figure
out
how
to
get
it
to
load,
because
note
is
not
there,
for
instance,
and
if
it
fails
a
note,
it
would
be
because
it's
maybe
an
HTTP
request,
so
a
callback
that
allows
being
able
to
gracefully
recover
from
specifier.
That
is
on
the
wrong
platform.
C
F
A
Maybe
just
make
a
note
of
it
and
we
could
dig
in
a
little
bit
afterwards
into
the
because
I
think
there's
kind
of
two
things
to
pull
out
of
that.
There's
like
the
specifier
side,
when
it's
like
resolving
a
specifier,
if,
like
the
specifier,
can't
be
resolved,
but
you
could
resolve
the
specifier
and
later
during
execution,
not
actually
have
the
resource
available,
which
is
a
different
thing.
I.
F
A
One
more
thing
on
this:
one
that
we
were
just
talking
about
one
pattern:
that
I've
seen
a
lot
when
we're
talking
about
specifiers
and
Shawn.
The
web
developer
wants
to
use
modules
and
NPM
natively
and
we're
just
kind
of
figuring
out
a
way
forward.
I've
been
thinking
about
pluggable
resolution
rules
as
a
feature
that
could
kind
of
solve
this
and
I
think
this
plays
into
a
couple
of
the
different
features
that
we've
been
talking
about.
A
But
if
nodes
resolution
algorithm
was
essentially
a
plug-in
system
where
package
name
maps
could
be
the
default,
but
anything
could
be
the
default.
I
think
there's
a
number
of
different
use
cases
that
get
solved
by
that
so
to
some
of
the
ones
jdd,
the
one
that
you
were
doing
like
you
could
completely
implement
STD
as
a
plugin
for
this
system,
for
example,
that
could
solve
the
case
of
where
we
want
to
do
all
these
different
kinds
of
like
compatibility
issues.
A
F
F
F
A
F
The
number
33
sarah
would
like
to
Det,
I
depend
on
a
dev,
build
and
a
frog
build,
I'm
not
quite
sure,
but
just
me,
but
that
could
be.
I
think
that
can
be
a
couple
of
different
things,
besides
environment
flags,
or
how
to
enable
that.
So
I
think
I
will
skip
and
wait
for
Justin
to
clarify
that
one
is
not.