►
From YouTube: 2020-09-24-Node.js Technical Steering Committee meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
that
issue
is
number
33416
in
the
node
repo
cgs
exports
detection
for
modules,
with
es
module,
export
and
miles.
I
think
you
were
going
to
start
off
by
giving
us
the
framing
and
we'll
go
from
there.
B
Yeah,
so
we
released
modules
with
the
latest
implementation
in
node
12..
It's
now
unflagged
in
both
12
and
14..
B
We
got
a
lot
of
feedback
from
the
community
for
a
number
of
different
aspects
of
the
implementation,
one
one
of
the
biggest
pieces
of
feedback
that
definitely
frustrated
people
was
that
our
implementation
does
not
support
named
exports
from
common
js
modules.
B
As
a
team,
we
worked
on
a
number
of
different
potential
solutions
for
this,
including
going
to
the
standards
or
tc39
to
try
to
make
changes
to
the
spec
that
would
allow
it,
but
up
until
now
there
hasn't
been
really
a
clear
and
spec
compliant
way
to
offer
this
and
the
spec
compliance
is
is
one
of
the
most
important
bits
here.
B
In
the
last
couple
months,
guy
bedford,
jeffrey
bruth
and
a
few
other
folks
have
been
exploring
using
static
code
analysis,
so
parsing
the
the
module
from
that
from
that
parse
being
able
to
do
some
heuristics
and
from
those
heuristics
determining
the
exports
of
the
module
and
essentially
allowing
exports
that
can
be
heuristically
determined
on
the
module.
It
is
important
that
we're
able
to
verify
that,
because
the
spec
expects
exports
that
do
not
exist
to
fail
early
prior
to
the
execution
of
the
module
itself.
B
That's
one
of
the
bits
in
the
spec
that
we've
been
trying
to
you
know
remain
adherent
to
so
guy
has
this
pull
request
that
uses
well?
Guy
can
get
more
into
the
specifics,
but
we
have
gotten
very
close,
but
have
not
been
totally
gotten
consensus
on
lan
on
landing
this.
This
change
with
an
additional
heuristic
that
it
would
only
attempt
to
predict
exports
on
modules
that
include
an
underscore
underscore
es
module
export.
B
The
underscore
underscore
es
module
export
is
a
special
export
that
is
used
primarily
from
transpilation
tools,
so
babel
or
webpack
or
rollup
will
amend
this,
and
a
number
of
tools
that
build
like
umd
modules
will
include
that
underscore
underscore
es
module
as
a
way
to
signal
the
fact
that
this
was
transpiled-
and
you
know
can
be
loaded
that
way,
I
I
can
maybe
hand
it
off
to
jeff
and
guy
now
to
get
more
into
the
specifics,
but
we're
getting,
I
believe,
like
mid
90s
accuracy
in
the
expected
exports
with
that
constraint.
B
That
would
limit
which
modules
this
feature
would
support,
but
it
would
still
be
better
than
the
status
quo.
I
believe
that
if
we
turn
this
on
for
all
modules,
the
accuracy
is
something
in
the
70
range,
but
this
may
be
a
good
time,
maybe
to
stop
and
answer
some
quick
questions.
If
anyone
from
the
tse
has
any
and
then
hand
it
off
to
jeff
and
guy
to
dig
a
little
bit
more
into
the
implementation
and
explain
the
numbers
and
choices
that
we
have
so
does
anyone
have
any
questions
right
now.
A
B
When
it
gets
it
wrong,
it
means
you
would
try
to
do
a
named
import
and
it
would
fail
early
saying
that
import
is
not
available,
and
I
believe
that
the
concern
from
objectors
to
this
pull
request
is
that
unless
it
has
like
high
90s
accuracy,
it
would
be
very
confusing
if
some
modules
worked
and
some
modules
didn't
work,
and
there
wasn't
like
a
clear
way
to
understand
like
why
certain
modules
worked
in
certain
modules.
Didn't.
C
It's
it's
worth
noting
on
that
point
that
I
believe
miles.
Maybe
you
can
clarify
this
as
well
the
error
message
when
you,
when
a
user
hits
that
failure
scenario,
will
give
them
the
correct
action
to
to
do
the
default
import
and
then
read
the
name
of
that.
So
there
is
a
very
quick
fix
if
the
user
hits
that
case,
which
we
make
sure
is
prompted
in
the
error
message,
so
that
kind
of
easily
recoverable.
C
C
If,
if
there
are
no
more
questions,
I
could
just
give
a
bit
more
background.
If
that
would
be
useful,
I.
B
It
has
to
be
integrated,
there
is
no
wave.
This
is
like
a
platform
feature
there,
like
in
theory
with
custom
loaders.
Someone
could
potentially
allow
this
behavior
specifically
at
an
application
level,
but
unless
this
was
deeply
integrated
into
node,
it
is
not
something
that
module
authors
or
community
members
could
expect
to
when
they're
publishing
modules.
A
B
Doing
is
just
one
to
be
sure:
yeah,
the
the
import
stuff
is
deeply
integrated
into
v8.
A
bunch
of
the
machinery
is
handled
by
v8
itself
and
so,
like
we're
we'd,
be
modifying
the
module
record
that
we're
handing
between
these
things,
but
there
would
be
no
way.
This
is
a
platform
specific
feature.
C
Yeah
so
as
miles
said,
this
has
been
a
very
long
process
for
the
modules
group
trying
to
work
through
this,
and
it's
very
clear
that
the
expectation
that
users
have
is
that
these
things
work,
and
so
it's
a
surprise
to
everyone
when
it
when
it
doesn't
work
and
they're
getting
this
error
today,
that
they
try
and
import
something
it
doesn't
work
and
then
they
have
to
be
told
to
import
the
default.
C
Now,
then,
that's
not
necessarily
going
to
work
with
their
current
typescript
workflow
or
it's
not
necessarily
going
to
work
with
their
current
browser
workflow.
So
it's
creating
a
friction
and
it's
causing
friction
with
other
tools.
So
no
doing
things
differently
is
yeah.
It's
it's
detrimental
to
node
and
is
detrimental
to
the
ecosystem.
So
at
the
same
time,
gus
is
quite
right
to
block
it
on
on,
because
it's
heuristical
it's
it's
a
it's
a
very
fast
lexa
that
I
wrote
for
a
separate
reason.
So
it's
it's
not
actually
a
full
passer.
C
It
doesn't
construct
objects,
it's
just
a
simple
lecture,
but
it'll
it'll
basically
run
through
and
check
your
exports
assignments
and
be
able
to
statically
see
what
looks
for,
and
it's
pretty
accurate,
considering
it's
doing
no
computation
of
the
actual
source.
C
But
at
the
same
time
it
is
it's
it's
somewhat
of
a
hack
and
but
it
fills
into
a
scenario
where
users
would
otherwise
not
be
able
to
get
anything.
And
so
it's
it's
sort
of
like
a
patch
to
just
make
the
ecosystem
better
and
the
difficulty
we
have
is
that
gus
was
wanting
high
accuracy,
which
is
a
very
difficult
thing
to
get
in
this,
and
that's
why
we
added
this
es.
C
C
But
then
it
just
became
clear
that
we
were
catering
this
whole
pr
to
gus,
when
in
fact
this
is
about
the
ecosystem
as
a
whole
and
it's
about
what
is
best
for
you
know,
node
and
the
js
ecosystem,
and
my
personal
opinion
at
this
point
is
that
this
restriction
to
just
es
modules
is
with
which
gas
has
since
removed
his
block
on
is
too
restricted
to
be
useful,
because
it
will
only
apply
in
maybe
five
to
ten
percent
of
cases,
whereas
users
want
this
on
most
modules
and
so
there's
another
pr
which
which
applies
this
to
all
common
js
modules,
even
without
the
es
module
export,
and
that,
I
think,
would
be
the
most
widely
useful
to
the
system
and
that's
one
that
gus
will
very
clearly
continue
to
block
on.
C
So
in
a
sense,
it's
that
one
that
I
would
be
looking
to
get
the
block
basically
overruled.
But
we
do
have
to
move
relatively
quickly
because,
as
miles
says,
we
would
like
to
see
this
land
on
node
12..
C
If
we
don't
land
on
node
12,
there's
a
risk
of
people
pushing
packages
that
assume
they
can
import
names
and
then
their
users
try
it
on
12
and
they
don't
get
that
functionality
so
people,
you
know
we
kind
of
get
stuck
in
a
place
where
we
can't
do
this
stuff.
It's
not
the
end
of
the
world.
If
it
doesn't
land,
I
think
it's
just.
C
It
would
be
a
huge
boon
to
the
ecosystem,
to
be
able
to
make
a
decision
to
do
something
that
just
helps
but
yeah,
so
that
that's
that's
my
feeling
on
this
stuff.
E
So
I
disagree
with
the
assertion
that,
as
modules,
the
underlying
line,
s
modules
approach-
gives
higher
accuracy
because
from
a
user
perspective,
if
the
model
is
still
transparent
or
not,
it
doesn't
care
like
like.
If
I'm
a
user,
I'm
using
asv
modules,
I
don't
care
if
my
module
is
transpiled
or
not.
If
my
dependency
is
transpired
or
not,
and
in
practice
limiting
this
approach
to
yes,
modules,
give
us
lower
accuracy.
From
that
perspective,
which
is
a
worse
experience
for
users.
E
A
A
C
The
only
other
consideration
here
would
be
performance
so
running
a
pass.
How
much
does
that
slow
down
module
loading,
and
so
there's
a
few
things
that
are
done
there,
which
I
can
go
into
in
a
little
bit
more
detail?
C
The
short
of
it
is
it's
typically
under
a
millisecond
or
a
millisecond
per
module,
and
it's
only
when
you
import
from
the
es
module
system,
so
it
doesn't
affect
your
current
if
you're,
just
using
commonjs
and
no
no
es
modules,
there's
no
effect,
if
you're,
just
using
es
module
that
there's
no
effect.
It's
only
when
you
on
the
on
the
lines
between
your
common
js
and
your
and
your
es
modules.
When
you
import
a
comment.
C
C
B
So
so
I
guess
a
question:
maybe
you
can
correct
me
if
my
intuition
is
wrong,
if
someone's
just
importing
the
default.
Doesn't
that
just
equate
to
the
module
that
exports?
And
in
that
case
we
don't
need
to
do
the
parse.
The
reason
why
I'm
saying
that
is
like
that
at
least
could
help
with
that
performance
problem,
because
in
theory,
if
someone
was
concerned
about
performance,
they
could
just
import
the
default
destructure
afterwards
and
then
not
have
to
worry
about
that
performance
hit
to.
C
Be
clear:
there
isn't
a
performance
hit,
that's
why
it's
not
a
full
passer.
It's
it's
alexa
that
runs
incredibly
fast
over
the
source
code
and
does
like
barely
any
allocations.
C
C
A
C
Yeah,
so
it's
additive,
it's
backwards
compatible
and
we
can
potentially
continue
to
improve
it
over
time.
B
B
I
guess
a
question
for
guy
in
jeff
that
I
hadn't
thought
about
before.
B
Would
there
be
a
way
to
write
a
tool
that
could
validate
expected
exports
for
packages
so
that
for
module
authors
who
have
who
are
publishing
common.js
modules
they
could
essentially
like
we
could
give
them
a
tool
to
make
it
really
easy
to
validate
that?
What
they
are
expecting
would
be
happening
so
that
hey?
If
someone
opens
a
pr
saying,
hey
your
your
project,
is
not
working,
they
could
fix
that.
C
Sounds
like
a
nice
idea,
I
mean
it
would
be
kind
of
cool
in
your
your
npm
see
what
you're
exporting
and
things
like
that.
I
don't
know.
Maybe
there's
some
interesting
discussions.
If.
D
You
have
there
with
him,
I
mean
that
would
just
be
basically
node
itself,
like
node
itself
tries
to
import
the
module,
and
you
know
you
see
what
names
are
available.
That's
similar
to
that's.
Basically,
the
test
suite
that
I
wrote
that
generated
all
the
numbers
with
the
percentages.
That
is
such
a
tool.
I
don't,
I
think,
like
we
would,
rather
than
encouraging
people
to
like
game
our
detection
algorithm,
so
that
their
common
days
module
was
successful.
D
I
think
we
would
try
to
we'd,
probably
prefer
to
push
people
in
the
direction
of
creating
an
esm
wrapper
so
that
you
know
they're
not
relying
on
this
detection
algorithm,
but
it's
like
just
they're,
truly
explicitly
defining
their
esm
exports
and
it's
kind
of
you
know
done
in
the
standard
compliant
way
et
cetera,
but
but
yeah
we
could
do
it
either
way.
B
D
Yeah,
I
think,
as
far
as
documentation
and
what
we
encourage
as
a
project,
I
think
we'd
want
to
encourage
the
esm,
wrapper
and
anna
created
a
tool
to
create
one
of
those
automatically.
So
I
think
we'd
probably
push
people
in
that
direction,
because
then
that's
standard
compliant
and
we'll
work
with
all
bundlers
all
tools,
browsers,
etc.
Whereas
you
know
other
environments
aren't
going
to
implement
guys
like
detection
algorithm,
that's
going
to
be
a
node
specific
thing.
A
B
Yeah,
I
guess
like
adding
adding
to
that
question
as
well,
like
guy
with
what
you
were
saying
about
how
like
importing
the
default
would
would
still
have
to
go
through
this
pipeline.
Does
that
mean
that
this
pipeline
is
creating
that
default
object
now?
Is
there
any
possibility
that,
like
importing
the
default
from
a
module
will
have
different
outcomes
now
than
they
would
have
prior
to
this
lecture
being
introduced?.
C
Yeah,
that's
an
important
consideration
and
so
far
in
all
our
discussions,
that
has
been
a
semantic
that
has
been
maintained
and
is
maintained
in
the
current
pr.
C
C
There
are
some
obscure
interrupt
cases
where
you
might
want
that
default
to
be
something
else
which
can
be
discussed
further,
but
I
think
that's
probably
out
of
scope
for
this
meeting
in
terms
of
backwards
compatibility.
There's.
Another
thing:
that's
that
happens,
which
is
all
of
the
all
the
exports
are.
C
Their
accesses
are
triggered
if
there
are
any
errors
thrown
so
because
we're
exporting
everything
as
soon
as
you
import
that
commonjs
module
we're
triggering
the
exports
accesses
and
some
of
those
could
cause
side
effects
will
throw.
But
I
really
can't
see
basically
it's
fully
backwards
compatible.
Like
worst
case
scenario,
you
access,
it
accesses
an
export
that
has
a
warning
that
will
throw,
but
then
it
will
get
caught
and
you'll
never
see
the
error
and
and
that's
it
and
and
it's
only
when
the
user
explicitly
imports.
C
This
this
common
js
module
from
the
es
module
system,
so
it
doesn't
affect
non-ess
module
workflows
at
all.
A
So
so
is
it.
C
Yeah
there's
there
is
minimal
risk,
it's
it's
safe
to
back
port.
The
the
main
thing
is
like,
I
think
it's
just
because
it
feels
ugly
because
it's
like
it's
this
kind
of
heuristic
and
that's
that's
the
biggest
thing
that
I
think
gus
is
complaining
about.
C
No
one's
complaining
about
or
semantics
they're
complaining
about
the
fact
that
it's
this
this
weird
heuristic
and
inaccuracy,
yeah
and-
and
I
think
just
getting
over-
that
in
the
name
of
compatibility,
is
kind
of
the
reason
we're
coming
to
the
tsc
here,
to
request
permission
to
be
able
to
overrule
gas
on
this
and
say.
Actually,
this
is
in
the
better
interests
of
the
ecosystem.
C
F
Wait
a
bit
if
this
is
about
that
this
looks
ugly
or
something
like
that.
Then
what
is
this?
What
are
the
consequences
of
that
like
we
have?
Basically,
if
we
leave
the
options
to
to
pass
one,
we
don't
do
this
and
the
second
one
is
we
do
this.
F
What
are
the
consequences
of
each
of
those
actions,
and
I
think
that
we
should
decide
putting
on
the
consequences
and
if
there
is
an
objection
of
some
sort
like
this
heuristic
or
something
like
that,
can
we
reward
that
into
something
that
is
closer
to
the
consequences
of
the
decision.
C
I
think
the
biggest
consequences
from
a
user
perspective-
a
user
will
just
be
like
I
don't
know
if
I'm
gonna
get
a
named
exports
or
not,
and
it
won't
be
clear
to
them.
It's
always
a
bit
of
a
gamble
like
will
it
be
there?
Oh,
it's
not.
C
Yeah
like
the
worst
aspect,
is
a
user
just
not
knowing
what
they're
gonna
get.
But
the
point
is
it's
correctable
there
there
aren't
ramifications
of
it.
Yeah
it's
it's
it's!
B
I
think
that
there's
there's
some
differing
opinions
about
how
developers
work
and
the
appropriate
way
to
do
things,
but
I
think
that
there
is
a
common
pattern
that
is,
you
know
you
npm
install
something
you
look
at
an
example,
and
then
you
write
it
and
you
try
to
use
it
and
a
lot
of
that
is
driven
by
the
docs.
But
some
people
don't
even
look
at
the
docs.
They
may
look
at
other
examples
of
the
code
or
just
try
to
use
it.
B
So
I
think
that,
like
one
of
the
things
here
is
definitely
like,
if
someone's
npm
installing
something-
and
they
know
like
they're,
installing
low
dash
or
installing
some
module-
and
they
know
more
or
less
like
the
api
off
the
top
of
their
head
and
know.
The
methods
like
the
argument
is
that
they
should
be
able
to
just
do
it
as
of
today
like
they
do,
need
to
go
and
then
look
at
the
documentation
and
see
whether
or
not
it
supports
esm.
Whether
or
not
it's
common
js.
B
As
opposed-
and
so
you
know,
I
think
the
major
contention
here
was
whether
or
not
improving
the
status
quo,
but
only
moving
the
needle,
a
certain
amount
actually
made
the
fail
case
more
confusing
or
if
just
having
a
clear
like
from
an
educational
standpoint,
and
this
is
something
I
can
also
empathize
with.
If
I'm
teaching
a
student
about
javascript
and
I
teach
them
about
common
js,
and
I
teach
them
about
esm-
and
it's
like
if
you
import
a
common
js
module,
there's
no
named
imports,
like
that's
a
really
easy
concept
to
teach.
B
B
So
so
this
kind
of
the
optimization
that
we're
talking
about
making
here
is
absolutely
one
that
caters
to
both
legacy
into
like
experienced
developers.
So
I
I
could
see
an
argument
here
where,
like
we
could
say,
you
know
we
should
optimize
for
something
that
makes
it
easier
to
teach
people
how
to
use
node,
even
if
it
upsets
or
annoys
the
developers
that
are
using
it,
because
it
removes
magic
and
removes
complexity.
B
G
B
I
I
think
that
I
think
that
that's
it
for
me.
I
just
wanted
to
make
sure
that,
like
kind
of
more
than
one
side
of
this
was
expressed
and
some
of
the
like
concerns
that
are
a
little
bit
more
esoteric,
especially
the
education
bit
like
I
have
to
be
honest,
I
have
flip-flopped
on
whether
or
not
I'm
okay
with
this
and
have
probably
been
on
the
like.
You
know
like
plus
minus
zero,
like
kind
of
like
what
one-ish
camp,
because
I
think
what
we
have
right
now
in
esm
is
very
usable.
B
This
makes
it
more
usable
but,
like
does
add,
complexity
and
magic
to
the
implementation,
but
we
have
been
adding
some
other
magic
too
for
usability
for
similar
purposes.
So
I
would
say,
like
considering
some
of
the
other
things
that
we've
added
recently,
including
the
like
wildstar
import
stuff.
It's
for
packages.
C
It's
worth
noting
as
well
that
this
is
the
same
magic
that
outlanders
do
when
when
we
use
named
exports
as
well
so
like
at
some
level.
It's
like
a
similar
kind
of
process
to
you
know
what
roll
up
is
doing
in
detecting
the
named
exports,
so
we're
kind
of
we're
following
a
lead
that
was
given
to
us
and
that
we
had
no
choice
on
because
we
engaged
at
an
earlier
time,
basically
and
yeah
sorry
miles
I'll.
Let
you
get
back.
G
Yeah,
my
only
other
hesitation
is
that,
given
that-
and
I
generally
leaning
towards
this
making
sense-
but
I
think,
given
that
this
is
alexa
and
it's
using
some
heuristics
we
there
was
the
idea
brought
up
that
we
could
improve
this
in
the
future.
But
I
think
any
improvements
would
have
to
be
backwards
compatible
right.
G
So
you
could
never
release
anything
that
now
suddenly
doesn't
understand
one
of
the
modules
or
a
couple
of
the
modules
that
that
it
did
before
so,
just
something
that
that
is
like
in
terms
of
somewhere
compatibility
would
would
have
to
be
kind
of
taken
into
account
and
without
some
overhead
I
guess
in
terms
of
like
like
do
we
have
documentation
around
everything
that
this
can
handle
right
now
and
and
how
it's
going
to
be
affected
in
the
future
right
or
like
test
cases
or.
C
Moving
forward,
if
we
wanted
to
get
this
on
twelve,
what
what
are
the
realistic
steps
for
us
working
on
modules
to
be
able
to
try
and
meet
that
goal?
Is?
Is
it
possible
or
is
it
not
possible
at
this
point,
because
that
would
save
a
lot
of
time
and
energy
if
we
know
where
we
are
and
that
as
well.
B
So
I
I
guess,
speaking
to
that
the
release
team
had
a
meeting
today,
I
unfortunately
wasn't
able
to
meet
it,
but
I
did
see
the
notes
I
think
beth
was
in
the
meeting
can
maybe
speak
to
what
they
were
saying
regarding
12.
H
Yep,
so
we
have
a
son
for
minor
due
out
in
a
couple
of
weeks,
we're
not
going
to
hold
off
on
that
one
for
the
modules
updates.
There
is
another
sum
for
minor
due
at
the
end
of
october,
so
we
might
be
able
to
make
that
if,
if
these
changes
were
to
land
soonish,
we
would
still
like
to
keep
the
two
weeks
baking
time
in
14.
B
I
think
that
it
like
there
there
is,
I
think,
there's
an
urgency
here
to
a
certain
extent
that
if
we
did
want
to
land
this,
we
really
should
be
considering
doing
it
as
soon
as
possible
and
getting
it
out
in
a
release,
potentially
even
as
soon
as
next
week
to
marry.
What's
saying
is
an
immediate
vote,
I
I
I
partially
agree.
I
think
that
if
the
tfc
has
consensus,
then
we
don't
need
a
vote,
but
I
I
would
love.
B
I
just
finished
today,
going
through
and
back
courting
all
of
the
other
changes
for
modules
that
were
not
yet
on
14,
so
the
14.x
staging
is
up
to
date,
and
I
can
I
am
on
vacation
next
tuesday,
but
I
will
volunteer
to
get
a
14.x
release
out.
That
includes
this.
If
we
can
reach
an
agreement
on
landing
it,
unless
someone
else
wants
to
volunteer
to
do
that
release
but
like
I'm,
I'm
willing
to
help,
try
to
get
it
out.
B
So
if,
if
we're
okay
with
saying
we
want
to
land
this,
and
we
want
to
move
forward
with
it,
I
think
you
know-
we've
been
trying
for
a
very
long
time
to
build
consensus
and
build
been
unsuccessful.
So
if
we
can
get
quick
consensus
on
the
tsc,
I
I
think
that
we.
I
So,
just
to
be
clear,
there's
no,
I
saw
gus
cleared
their
objection
to
the
poor
to
the
request.
I
Right
and
then
for
the
other
one
there's
but
then,
but
then
for
for
other
things,
there's
there
is
a.
C
I
think
if
we
got
approval,
I
think
gus
would
probably
re
reinstate
his
rejection.
You
know,
maybe
he
won't
make
it
explicitly,
but
I
know
he
is
in
objection
to
that
pr
effectively,
but
yeah
they
could
be
somewhere.
C
B
What
we
could
do
today,
if
people
are
up
for
it,
is
the
underscore
underscore
es
module
version
of
it
does
not
have
any
objections.
We
could
land
that
today
and
put
the
intention
to
land
the
other
one.
We
could
explicitly
ping
gus
and
see
if
he
will
block
it
and
if
gus
says
that
he
would
block
it,
then
we
can
follow
up
with
the
tsc
and
try
to
get
a
vote
going
out
today.
That
closes
maybe
like
monday.
That
way
we
can,
I
might
just
add,
I
would.
C
Prefer
if
we
could
pick
one
or
the
other
and
and
go
with
it
if
that's
possible,
just
because
I
have
to
do
a
full
day
of
work
to
get
the
pr
merge,
because
it's
still
in
web
assembly
and
we
can't
land
webassembly
in
core
because
of
other
restrictions.
So
I
have
to
convert
the
code
into
javascript,
so
I
won't
be
able
to
do
that
work.
C
A
Well,
the
the
you
know.
Basically,
I
think
we
would
need
to
say
here
the
two
pr's
and
it's
basically
that
we
we.
You
know
the
tfc
believes
that
both
of
these
should
land,
just
you
know,
or
or
whatever
we
get
consensus
here
and
say
that
you
know
from
the
people
in
the
meeting.
This
is
what
we
think
is.
Is
this
what
the
tfc
consensus
seem
to
be
other
tfc
members
who
weren't
there?
A
E
E
C
Yeah,
I
mean
it's
difficult
to
know
how
much
context
is
needed
to
make
an
informed
decision.
I
mean
it
would
be
really
nice
to
get
get
something
that
can
you
know,
I
think,
the
the
risk
with
the
es
module.
One
is,
as
mary
said
in
in
the
chat
that
you
know
you,
you
get
a
low
percentage,
and
now
it's
like
only
one
in
20
of
packages
will
get
exports,
even
though
you're
getting
90
of
those
working.
C
So
you
know
now,
that's
sort
of
that
gamble
of
will.
I
get
a
named.
Export
goes
down
to
like
one
in
20
from
a
user
perspective,
and
I
I'm
still
a
little
bit
concerned
about
that.
So
I'd
be
wary
of
putting
a
vote
that
that
sort
of
gives
a
choice
and,
like
I
feel
like
there
are
a
lot
of
like
other
factors
as
well,
so
it's
like
if
we
could
just
get
from
the
tse
either
either
like
an
ability
to
say
you
know
the
modules.
C
I
don't
know
it's
it's
just.
We
need
to
get
over
gus's
block
and-
and
I'm
I'm
concerned
about
the
tfc
taking
ownership
for
the
the
decision
as
a
whole.
If
that
makes
sense,
sorry
I
don't
mean
to
muddy
the
waters
even
more.
C
Right
so
say
that
we
think
this
is
a
useful
feature
and
and
that
now
we
can
override
gases.
Pr
in
the
name
of
where
the
existing
modules
group
consensus
is
so
saying,
deferral
to
the
modules
group
and
willing
to
override
individual
blocks,
based
on
the
fact
that
it's
not
a
modules
group
majority.
H
I
Made
yet
like
I
I
I
know
that
it's
exactly
what
what
we
don't
what
we
you
probably
don't
want
to
hear
in
this
situation.
But
you
know
different
objections
require
different
votes,
because
people
are
going
to
be
objecting
for
different
reasons,
and
some
objections
are
more
valid
than
others.
B
So
so
I
I
would
like
to
just
like
augment
what
what
guy
suggested
a
little
bit.
The
modules
working
group
is
not
a
chartered
working
group.
It
does
not
have
ownership
over
this
decision,
although
we
have
given
them
kind
of
like
a
by
proxy
authority
over
modules.
The
the
eventual
blocks
once
a
pr
is
opened,
like
the
modules
group
has
said
that,
like
we'll
respect
blocks
and
try
to
reach
consensus
but
like
the
reality
is,
is
that
this
is
a
node.js
collaborator
on
node.js
pr.
B
I
B
There's
two
pr's
right
now
and
that
gus
has
not
objected
to
either
the
exports
for
all
modules.
One
has
been
open
for
seven
days
and
has
been
approved
by
mary
gus
has
said
in
there.
Those
numbers
are
not
looking
too
good,
but
it
has
not
explicitly
blocked
it.
B
So
I
think
I
think
what
we
what
we
need
to
do
right
now,
the
order
of
operations
to
to
kind
of
follow
what
you're
saying
rich
would
be
tsc
members
should
approve
that
pr
that
want
to
see
it
land
I
can
ping
gus
and
let
him
know
that
after
this
conversation,
you
know
folks
are
feeling
like
moving
forward
with
this
and
that
he
would
like
to
block
it.
B
Now
is
the
time
to
do
it
basically,
and
if
that
block
comes
in
then
we
can
call
a
vote
to
override
that
specific
block,
and
especially
since
we
haven't
had
quorum
in
this
call
today,
we
can't
predict
what
the
outcome
of
such
a
vote
would
be
and
gus
is
not
blocking
the
underscore
under
scories
module.
Iteration
he's
dropped
his
block
for
that,
but,
with
that
being
said,
guy,
it
is
sending
like,
even
from
you,
you're
kind
of
feeling
at
this
point
that,
like
we'd
all,
must
be
better
off
not
doing
it.
B
I
don't
know
that.
I
totally
agree
with
that,
because
I
think
that
the
underscore
underscore
es
module
iteration
unlocks
a
use
case
for
umd.
So
I
personally
like
a
perfect
solution
here
that
I
would
love
to
see.
Guy
would
be
that
underscore
underscore
es
module
one
get
fixed
up
and
just
get
landed
as
soon
as
possible,
and
then
the
thing
that
you
pivot
on
for
checking
for
underscore
underscore
eos
module,
just
open
a
follow-up
pr
to
remove
that,
and
essentially
like
have
that.
C
A
B
Yeah
I'll
ping,
I'll
ping
gus
right
now,
and
let
him
know
that
we're
planning
to
move
forward
on
this
in
lieu
mary
just
objected
to
underscore
and
discouraged
modules
that
we're
planning
to
move
forward
with
this
in
lieu
of
an
objection.
So
if
he
doesn't
want
to
see
this
land,
you
know
he
he
needs
to.
He
needs
to
voice
that.
I
I
would
I
would,
I
would
encourage
any
tsc
members
who
want
to
see
that
thing
land
to
make
sure
they
go
and
approve
it,
because
just
psychologically,
it's
very
easy
to
vote.
Yes
on
overriding,
a
single
objector.
When
there's
you
know
eight
people
approving
you
know,
even
if
you
don't
fully
understand
the
issues
which
you
know
a
lot
of
people
in
the
tsc
won't
so
just
putting
that
out
there.
Please
approve
it.
If
you
want
it.
A
Okay,
so
we're
now
we
do
have
some
private
business.
We
have
a
few
other
issues
on
the
agenda
which
we
won't
be
able
to
get
time
to
to
get
to
all
of
them.
So
I'd
suggest
we
identify,
which
ones
are
the,
maybe
one
other
one
we
try
and
address.
There
is
the
change
requirements
for
object.
Dismissal
that
one
mary,
I
think
the
only
remaining
question
was
whether
you
think
we
should.
You
know
we're
okay
with
pasting
into
the
issue,
our
recommendation,
or
we.
E
Yes
yeah.
I.
I
A
E
No,
that's
still
on
the
agenda.
I'm
gonna
comment
on
the
request
with
what
we
decided
and
I
can
help
with
auditing
the
the
teams
that
are
code
owners.
I
E
I
I
propose
at
this
point
with
it
being
this
late
and
with
us
having
private
business
to
talk
about,
I
would
say,
move
everything
to
next
week,
except
for
if
anyone
sees
anything
on
the
agenda
that
needs
to
be
addressed
sooner,
take
it
to
email.
We
can
do
announcements
in
in
the
next
tsp
or
whatever,
but
just
take
it
to
email
and
and
and
let's
let's
wrap
this
up,
as
is
I
I
I
I
propose.
A
F
Object
to
putting
out
in
the
github
I
think
that
could
be
moved
to
github
and
earlier
and
not
the
next
week.
Even.
A
Okay,
okay,
so,
let's
close
out
for
today
in
the
public
system,
I'll
stop
the
stream.
Thank
you
for
everybody.
Who's
been
who's,
come
and
participated,
and
for
those.