►
Description
A
Live
now
welcome
to
the
no
jeaious
Foundation
CTC.
That's
core
technical
committee
meeting
for
August,
2nd
2017
I
have
a
pretty
full
agenda.
I
know
I
have
to
stop
at
the
top
of
the
hour.
So
let's
get
right
to
it.
Does
anyone
have
any
announcements
that
they
wish
to
make
it
this
time?
I
know
8.30
is
imminent,
but
not
available
yet,
and
there
was
an
LTS
release
yesterday.
B
B
D
A
All
right
in
that
case,
then,
let's
quickly
review
the
previous
meeting.
We
discussed
four
issues
that
that
meeting
one
was
the
semantic
versioning
impact
of
error,
messages
and
I,
see
Michael
you're,
taking
notes
actually
already
wrote
these
notes
out,
yeah
above
so
they're
already
there
there's
the
semantic
version,
impact
of
error
messages,
and
we
concluded
that
for
now
our
message
changes
are
still
considered
breaking
changes,
even
in
the
new
internal
error
system.
That
may
change
at
some
point
in
the
future
and
all
other
aspects
of
discussion
were
referred
back
to
github.
A
For
es
modules,
we're
going
to
get
to
that
so
that
was
supposed
to
put
into
this
meeting.
We
also
discussed
the
turbofan
and
ignition
release
plan
and
communication
plan.
We
did
some
discussion
and
refer
to
back
to
github.
We
do
that
a
lot,
and
we
also
talked
about
chartering.
The
release
group
also
referred
back
to
github.
A
A
Is
there's
been
a
long-standing
issue
and
Matteo
added
this
to
the
to
the
agenda,
but
there's
been
a
long-standing
issue
about
what
to
do
across
the
code
base,
where
we
access
underscore
prefixed
a
couple
of
underscore
prefixed
properties
of
streams,
and
that
kind
of
that
had
an
issue
open
pretty
early
on
and
it
kind
of
stalled
out
and
Matteo
wants
to
figure
out
what
to
do.
I
think
so.
That's
probably
gonna
be
the
second
thing
we
talked
about.
A
A
Great
okay,
so
if
we
have
time
that
will
certainly
be
the
third
thing
on
the
agenda
and
the
last
thing
was
put
on
by
Anna
Henningsen,
who
might
not
be
able
to
make
it
I,
don't
think
she's
here
yet
is
she
look
like
it,
but
that
has
to
do
with
more
robust
ramification
and
promises,
and
hopefully
she
can
show
up
a
little
late
and
we
can
talk
about
it.
If
not
I.
Imagine
there's
good
possibility,
we'll
push
it
off
to
the
next
meeting.
Okay.
A
A
We
have
guy
bedford
here,
who's
the
author
of
it
as
a
guest
today
to
help
us
with
the
conversation
around
what
to
do
with
this
thing,
and
so
I'm
gonna
frame
it
a
little
bit
but
I'm
gonna,
let
you
frame
it
guy
and
then
we'll
have
a
conversation.
Jeremiah
just
posted
the
the
other
link
to
it
for
anyone
listening,
it's
github.com,
slash,
nodejs,
slash,
node
e
PS,
/
pol
slash
60,
so
my
understanding
is
that
basically
wanna
have
a
little
bit
of
a
conversation
just
to
serve.
A
You
know
make
sure
that
this
is
not
a
proposal
that
is
going
to
be
inevitably
rejected
and
therefore
working
on.
It
is
a
complete
waste
of
everyone's
time
and
this
sort
of
got
a
feel
that
there
is
some
support
for
this
in
the
project
on
CTC
and
sort
of
just
try
to
hash
out
anything
that
might
be
quick
and
easy
quicker
and
easier
to
hash
out
through
a
verbal
conversation.
Then
over
github
is
there
anything
else.
You
want
to
add
to
the
framing
of
this
issue.
E
F
F
So
it's
a
purely
additive
change,
so
we
don't
have
to
worry
about
that.
Also
last
week
at
tc39
tc39
decided
not
to
adopt
the
use,
module,
pragma
and
so
for
people
who
are
unable
to
change
their
current
workflows,
for
whatever
reason
this
is
now
much
more
appealing,
since
one
of
the
routes
that
was
being
looked
at
has
been
closed.
So,
yes,
that's
it.
A
F
F
A
D
I
guess
this
might
be
better
for
further
into
the
conversation,
but
I
have
a
summary
that
mostly
consists
of
two
points
that
I
can
link
to
of
things.
That
I
think
are
really
important
to
consider.
With
this
end,
related
proposals
and
I
mean
our
detection
in
general
kind
of
favors
this
or
a
similar
approach.
G
C
G
E
To
understand
the
context
of
the
proposal,
I
know
that
there's
been
many
proposals
made
in
this
space
already,
but
I
found
in
my
own
feeling
work
when
I
was
wanting
to
work
with
a
jeaious
extension
for
ES
modules.
I
wanted
to
know
that
I
could
build
on
top
of
something.
That
is
where
no
one
is
going,
because
if
I
do
something
in
my
own
tooling
and
then
node
there's
something
else
down
the
line,
but
that's
going
to
be
a
breaking
change
in
my
own,
tooling
work.
E
D
They
don't
need
to
implement
the
entire
thing,
so
we
are
sort
of
stuck
waiting
for
api's
and
things
from
v8
to
get
this
thing
all
working
properly,
so
we're
kind
of
lagging
behind
and
not
and
actually
implementing
something,
and
it's
kind
of
also
pushing
us
back
in
I
mean
we
don't
want
to
find,
go
down
an
implementation
route
and
find
something
is
like
very
difficult
or
anything
to
do.
I
know:
Bradley
has
a
lot
of
this
sort
of
thing
implemented,
but
that's
just
part
of
why
it's
backed
up
so
long.
F
Oh
sure,
so
we
have
a
PR
up
on
node
4.
What
we
can
do,
which
given
the
current
v8
AP,
is
essentially
what
we
can
do
is
we
can
make
the
main
module?
B,
yes,
module,
however,
to
use
dynamic,
import
or
import
meta.
We
have
to
wait
on
v8
to
finish
implementing
them.
They
technically
have
a
dynamic
import
implementation,
but
it's
not
suitable
for
node,
given
how
it
does
resolution
only
on
strings,
not
on
object
references
they're
working
on
it,
but
we
can't
progress
further
in
our
implementation,
except
for
bug
fixes
with
our
existing
stuff.
F
E
Certainly-
and
it's
it's
worth
mentioning
that
with
this
proposal,
my
goal
isn't
at
all
to
try
and
push
something
through
quickly,
but
instead
for
when
MJS
lands
in
a
node,
stable
or
I
mean
in
in
developments
at
least
as
users
start
using
it.
And
thinking
about
these
questions
for
them
not
to
be
coming
across
a
past
history
of
proposals
that
are
all
no
longer
active,
but
to
have
a
proposal
that
can
potentially
then
gain
further
support.
H
H
Actually
I
think
found
that
the
best
way
would
have
been
just
to
everyone
agreed
on
use
model
from
the
very
beginning,
because
it's
the
only
solution
that
could
work
both
for
node.js
and
for
browsers,
so
that
she
won
or
C
and
dodges
file.
They
would
be
able
to.
Tell
me
that
is
targeted
for
browser
is,
if
it
is
targeted
for
script
or
for
es
model,
looks
like
that.
Won't
happen,
and.
H
H
H
She
says
the
only
way
how
we
couldn't
break
things
now
with
the
current
path
browser
shows,
and
so
when
she
now
supports
target
n
dot,
I'm
just
option,
because
you
can
do
anything
better
so
now
about
the
packages
on
Antietam.
I,
actually
think
that
she
is
shoot
a
dog
because
I
see
well
use
cases
which
wouldn't
broken
without
that,
for
example,
if
some
librarians
some
JavaScript
libraries
mostly
target
browsers
and
his
daughter
mg
has
not
been
adopted,
and
each
now
doesn't
come
zero
cost
because
he
just
don't
suppose
dot
I'm
just
out
of
the
box.
H
So
when
someone
published
library,
which
is
primarily
targeting
browsers
on
NPM,
they
would
probably
name
make
files
Dargis,
and
when
someone
comes
in
complaining
that
this
library
doesn't
work
for
old,
they
would
still
not
want
to
the
name
every
single
file
to
and
just
until
and
just
becomes
adopted
and
said
so
at
least
for
now,
I
didn't
match
for
those
whose
cases
and
some
other
chain
just
don't
want
to
spend
time
to
mention
here,
which
would
be
a
pushed
into
oh
well.
That
would
share.
H
H
I
So
I
had
some
clarifications,
so
use
module.
D39
chose
not
to
adopt
it
because
they
consider
it's
it's
a
platform
concern.
So
it's
a
host
concern,
not
really
a
language
concern
and
and
I
know.
Bradley
has
opinions
on
this
and
we
don't
really
need
to
discuss
use
module
right
now,
but
I
would
even
consider
the
door
to
be
closed
for
used
module
and
as
far
as
the
browser's
are
concerned,
I
mean
it
browsers
already
have
a
pragma
that
goes
into
the
HTML
that
so
so
they
can
simply
ignore
it.
H
20
use
module
is
the
only
adventure
show
you
use,
math
would
work
if
everyone
just
folded.
Example,
for
example,
if
browsers
of
all
use
module
as
well
as
I
mean
if
they
would
target
GSM,
if
they
see
any
of
those
that
would
make
use
module
usable,
but
if
use
module
you
can
suppress
from
concern,
then.
H
I,
don't
think
that
it
would
become
standard
because,
whatever
it
is,
television
only
browsers
would
not
use
use
module
because
it
would
not
be
needed
for
them,
but
that
time
Jesus
is
better.
In
that
case,
if
browsers
are
not
supporting
data,
I'm
Jess
and
your
browsers
and
our
support
was
mortal
because
it
doesn't
cover
this
advantage
of
just
something
that
is
God
by
browsers,
because
browsers
have
always
not
extensions,
and
even
though
China
has
become
standard
for
yes
modules,
they
wouldn't
be
any.
A
I
just
want
to
reject
real
quickly
to
say
that
probably
only
want
to
spend
about
another
five
or
so
minutes
on
this.
We
can
talk
forever
about
modules,
it's
the
nature
of
es
modules,
and
it
would
be
good
to
try
to
focus
on
the
pros
and
cons
of
this
proposal
as
much
as
possible.
I'm
not
trying
to
cut
conversation
off,
but
I
am
trying
to
prevent
it
from
spiraling
off
too
much
I'll
stop.
F
So
I
can
bring
up
something.
I
would
like
some
more
clear
feedback
on
this
proposal
at
the
last
tc39
meeting.
They
also
talked
about
a
third
parce
qu'elle
for
the
javascript
language,
which
is
the
AST
form
of
JavaScript,
and
so
I
am
personally
slightly
worried
if
we're
going
to
have
greater
than
two
about
this
greater
than
two
parcels
about
taking
this
approach,
because
it
might
mean
having
a
third
yield
and
package
JSON
or
something
so
yeah.
E
I
think,
with
that
case,
just
like,
we
already
have
node
binaries
and
JSON
files
as
separate
parcels
that
the
file
extension
should
be
enough,
especially
since
we're
not
fighting
against
an
existing
ingrained
ecosystem
habit
of
creating
J's
files
and
having
to
ask
people
to
rename
those
to
MJS
with
a
new
format.
As
long
as
we
can
get
in
there
on
the
ground
floor
and
make
it
clear
that
it's
its
own
file
extension
that
that
should
be
enough
distinction,
just
like
MJS,
would
be
more
than
enough
distinction.
D
Okay,
I'd
like
to
bring
up
the
two
things
that
I
had
on
my
sort
of
summary
thing.
So
I
think
that
there's
two
large
things
that
favor
this
general
sort
of
approach
where
it's
not
per
file
I
suppose
number
one
is
that,
aside
from
like
Jason
and
I,
think
there
might
be
one
other
thing
that
we
special
case
into
something.
I
know
certain
people
across
the
ecosystems
through
the
mechanisms
that
we
have
for
this
in
the
module
module
have
a
special
case.
D
Other
files,
do
you
mean
different
things,
but
we
don't
do
that
for
regular
script
mode.
Javascript
I
think
this
was
something
that
it
was
perhaps
missed
in
earlier.
Discussion
certainly
was
from
me,
so
we
already
interpret
like
anything
you
throw
in
as
script
no
JavaScript,
so
we
don't
detect
on
the
file
by
the
dot.
Someone,
unfortunately
kind
of
passed
that
decision
I
think,
although
we
will,
in
the
future,
probably
have
to
reserve
more
names
from
it
regardless
such
as
waz,
'm
or
AST
I,
suppose
so,
there's
that
also,
but
because
of
how
browsers
load
files.
D
Now
this
comes
from
the
fact
that
they
really
only
have
or
going
to
have
one
module
system,
because
otherwise
you
just
have
tacking
things
onto
a
global
from
various
script
tags,
but
they
only
specify
from
the
very
top
level.
So
you
specify
that
stuff
is
a
module
and
then
partially
because
there
is
only
one
module
system.
D
So
partially
brought
up
in
this
proposal.
Also,
although
I
don't
think
it
actually
pertains
to
the
proposal
itself,
we
will
need
to
have
a
module
flag
of
some
sort
of
description
for
eval
scripts,
so
where
you
do
know,
II
or
no
eval,
and
also
for
the
repple
for
the
replicas
can
probably
also
we
can
probably
also
make
an
internal
command
that
turns
on
module
mode,
but
we
will
probably
need
some
sort
of
way
to
turn
those
on
before
they
are
launched.
D
F
E
Correct
in
in
terms
of
the
points
against
this
proposal,
the
the
primary
points
that
I
could
probably
see
is
the
additional
performance
cost
in
the
resolver
that
we're
doing
is
packaged
our
JSON.
The
gaps
and
the
argument
that
was
used
in
the
in
defense
of
Jays
proposal
was
exactly
the
same,
which
is
that
we
already
do
packaged
our
JSON
lookups
for
direct
remains,
so
that
it's
only
a
minor
extension
to
that.
The
other
counter-argument
to
the
potential
reserve
of
performance
is
that
we
already
do
up
to
I.
Think
four
different
file
extension
checks.
E
I
forget
the
exact
number,
each
of
which
is
a
separate
file
system
stat.
So
there's
already
that
latency
in
the
module
system
for
those
bad
cases
and
if
performance
of
the
Riddler
were
to
be
a
primary
concern.
That's
we
should
be
rather
enforcing
the
use
of
file
extensions
because
that
would
remove
all
of
those
sort
of
standing
cases.
D
So
I'm
really
not
sure
that
performance
was
ever
much
of
a
thing
against
the
package.json
performer
proposals.
Initially
proposed
performance
is
definitely
a
negative
point
against
trying
to
do
any
dual
parsing
scenario,
where
we
pars
it
say
as
a
module
first
and
if
it
doesn't
work
far
so
as
a
as
a
script,
I
seem
to
recall
that
major
points
against
previous
ones
were
things
such
as
dual
modules
would
be
easier
to
differentiate,
particularly
in
situations
where
you
are
requiring
or
importing
a
specific
file
in
a
module.
G
E
G
G
G
E
That
that
would,
in
that
sort
of
a
case
it
would
likely
be
an
entry
point
to
an
application
that
doesn't
have
a
package
to
JSON.
So,
yes,
we
would
start
up
to
the
roots,
but
then,
after
that's
done
once
it's
cached
and
it's
not
done
again
for
any
of
the
other
modules
in
the
app
in
the
app
so
worst
case
scenario,
it's
it's
only
five
or
six
step
unnecessarily
on
startup.
G
A
D
A
I'd
like
to
kind
of
wind
this
down
at
this
point,
I
do
think
it's
probably.
This
is
probably
not
the
right
venue
to
try
to
go
over
and
cover
every
every
concern
that
might
be
raised
with
the
issue
with
the
pro
requests,
but
I
do
want
to
I.
Guess.
I
first
want
to
see
if
a
guy,
if
you
feel
like
you,
have
a
decent
understanding
of
where
this
sits
and
if
there
and
and
if
you're,
able
to
evaluate
if
this
is
something
you
want
to
pursue
further
or
not.
E
Yeah
I
mean
it's.
It
certainly
helped
to
be
able
to
get
an
idea
of
what
what
their
concerns
are
for
me
personally,
I
be
keen
to
potentially
look
at
making
50
back
into
the
proposal
and
refining
it
further,
or
also
potentially
doing
some
some
performance
analysis
on
on
possible
implementation
part
of
typing.
But
if
there
are
any
strong
arguments
against
going
further
along
this
road,
it
would
be
help
to
hear
so
far.
It
doesn't
sound
like
there
are
any
huge
negatives.
D
I
think
I
should
probably
bring
up
one
last
thing,
then
that's
that's
also
from
the
previous
discussions
about
this
I
think
the
majority
of
us
at
least
at
the
time,
saw
very
few
overwhelming
positives
with
it
all.
So
perhaps
that's
just
our
limited
perspectives
ourselves,
but
we
don't
really
I.
At
least
the
consensus
was
at
the
time
there
wasn't
that
much
positive
in
maintaining
and
the
jas
extension,
or
so
it
seemed.
G
Have
one
question
for
everybody
that
might
what
stops
this
proposal
to
be
implemented
on
top
of
note,
so
it
is
blocking,
it
is
blocking
us.
It
requires
changes,
you
know
to
work,
and
can
we
allow
some
experimentation
of
the
ecosystem
and
the
greater
system
likes
it
then
right,
I,
don't
know
really
there's
a
possibility,
but
I
just
wanted
to
mention
it
because
it
might
be
useful.
A
E
I,
don't
wants
to
move
it
further
based
on
interest,
so
the
idea
would
be
for
it
to
have
some
homework
and
sits,
even
if
it's
just
still
on
this
PR
as
as
an
open
one
and
and
be
in
some
form,
active
and
able
to
pick
up
on
interest
if
and
when
it
develops
after
MJS
lands
in
node,
so
that
it
can
form
part
of
a
path
or
alternative
paths.
Can
you
come
in,
but
but
just
for
there
to
be
something
active,
because
if
you
look
back
at
the
history
of
these
proposals,
it's
it's.
E
A
C
A
A
A
So
the
next
topic
that
we
were
going
to
discuss
was
the
issue
of
Mateo
put
on
the
agenda,
which
is
in
the
nodejs,
slash
node
repo
issue
number
four
for
five
clean
up,
writable
state
and
readable
state
access
across
the
codebase
Mateo.
Would
you
like
to
summarize
and
ask
explain
what
you're
looking
for
in
this
conversation
so
sure.
G
But
then
there
was
I
think
there
were
some
objections
by
by
Brian
and
others
about
the
fact
that
we
were
adding
more
things
more
new
properties
to
to
some
base
classes
of
the
pollak
system
and
that
they
may
cause
clashes
and
problems
like
that.
So
genetically.
What
I
would
like
to
know
is:
should
we
keep
down
the
drought
or
should
we
should
we
stay
on
the
underscore
property?
Now,
it's
not
possibly.
G
We
don't
think
it's
feasible
to
remove
either
you
take
Vista,
but
there
are
other
options,
of
course,
and
one
which
is
to
remove
them
the
score,
which
is
fine,
but
that
will
open
up
the
feed.
If
you
put
the
fact
that
here
also
opening
stage
that
we
don't
really
want
to
open
to
the
public
and
with
the
first
one
and
then
the
second
one
is
that
I
think
another
object,
another
readable
state,
another
writable
state
specific.
G
Now,
if
you
know,
if
you
know
or
not,
that
the
code
path
in
in
the
streams,
it's
very
heavyweight,
very
costly,
so
we
don't
I,
don't
want
you
to
create
more
objects
for
streams
when
they
are
not
really
really
needed.
So
I,
don't
know.
I
hope,
I
have
been
clear.
I
can
provide
some
reference
for
thought
before
the
minutes.
If
it's
needed.
H
G
G
G
G
G
G
Yeah
well
part
of
the
concerns
were
the
name,
the
name.
Where
would
the
name
would
clash?
And
of
course
we
are
people.
People
are
inheriting
from
from
those
base
classes.
So
you
know
there
is,
when
you
add
something,
there's
always
always
the
risk
of
causing
issues
and
some.
So
that's
the
only
thing
that
if
we
think
if
we
want
it,
those
some
of
those
Piera
can
be
landed
at
at
some
point
in
the
near
future.
It
it's
more
about.
A
A
C
We
actually
did
that
last
time,
so
I'm
and-
and
there
hasn't
been
a
lot
of
discussion.
So
what
I'd
like
to
do
is
see
if
there's
opposition
to
just
setting
a
date
for
ratification
right
like
I'm
trying
to
rent
through
the
working
group
saying-
and
it
said
it
needs
to
be
ratified
by
the
CTC
and
what
I
didn't
parse
from
that,
whether
that
means
like
we
actually
have
to
have
a
vote,
or
it
just
has
to
be
our
regular
consensus,
seeking
where
there's
no
objections
but
I
wanted
to
sort
of
see.
A
A
Cleared
that
yeah
and
in
the
meantime
yeah
I
guess
in
the
meantime
I
mean
ratified,
does
sort
of
imply
a
formal
signing
off
on.
So
maybe
we
should
maybe
we
should
call
for
a
vote
either
in
the
in
the
github
thing
itself
or
or
at
the
next
meeting.
Although
I
really
am
a
fan
of
if
nobody
objects,
just
it's
done.
C
A
C
C
C
A
D
A
A
A
I'm
having
a
hard
time
yeah
here,
we
are
so
upcoming
meetings.
This
meeting
now
happens
every
two
weeks,
so
it'll
be
the
next
one
of
these
will
be
at
11:00
a.m.
UTC,
which
is
4
a.m.
on
the
west
coast
of
the
United
States
and
7
a.m.
on
the
east
coast
of
the
United
States
on
Wednesday,
August
16th,
and
for
that
matter
you
know
what
you
can
just
go
to
know:
JSTOR,
slash
calendar
and
just
see
a
whole
bunch
of
other
meetings.
A
C
Right
and
from
my
perspective,
it's
always
good
to
avoid
that,
because
I
think,
if
you
ever
get
into
cases
where
you
know
notice
being
loaded
into
a
process
as
a
shared
library
or
something
Global's,
do
do
limit
they'll
cause
things
that
you
know
can
cause
things
that
won't
work.
So,
if
you
don't
need
to
do
them,
that's
better
not
to
do.
A
D
Yeah
I'd
like
to
mention
quickly,
since
that's
sort
of
framing
from
a
browser
perspective
so
browsers,
don't
currently
have
a
module
system,
as
we
talked
about
earlier
so
global
various
variables
are
kind
of
used
in
some
ways
in
place
of
that,
although
also
in
global
state.
So
it's
a
little
bit
nicer
to
know
just
to
kind
of
wrap
this
up
in
packages
and
modules,
and
perhaps
that
will
be
the
become
logic
part
of
the
future
in
ES
modules.
In
the
browser
too,.