►
From YouTube: 2021-11-17-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
welcome
to
the
node.js
technical
steering
committee
meeting
for
november
17
2021
we'll
follow
the
agenda
that
we
had
tagged
in
the
issue,
which
was
issue
number
one,
one,
two,
two
okay.
So
before
we
get
started
with
the
agenda,
is
there
any
announcements
that
people
would
like
to
share.
A
Them
perfect:
okay,
thanks,
okay!
Well,
if
there's
no
announcements
this
week,
we'll
move
on
to
cpc
and
board
meeting
updates,
I
don't
believe:
there's
any
updates
from
the
board
rich.
Do
you
have
anything
you
want
to
share
on
the
cpc
side.
A
A
C
Okay,
yeah,
I
can
do
that.
Let
me
know
if
I'm
unclear
at
all.
Sometimes
these
airpods
have
switched
onto
the
wrong
microphone
setting
and
it
can
be
difficult
to
hear
yeah.
So
mateo
brought
up
this
one
for
the
tsc.
Originally,
the
concern
was
flagged
by
jordan,
so
just
to
go
into
a
little
background
on
the
issue
for
pull
request.
C
4040
708,
we
a
little
while
back
realized
that,
with
these
conditions
in
the
package,
json
exports
and
imports
fields
which
allow
custom
resolutions
based
on
environments
being
in
resolving
in
different
environments
that
there
would
be
benefits
in
ensuring
that
conditions
that
aren't
actually
implemented
in
node.js
are
are
still
well
defined.
So
node.js
only
implements
a
few
conditions
itself,
the
import
condition
the
require
condition.
C
The
node
add-ons
condition.
So
you
can
resolve
specifically
under
these
conditions,
but
there
could
be
other
conditions
like
a
react,
native
condition
or
a
a
browser
condition
is
probably
the
most
popular
one
as
a
kind
of
a
modern
version
of
the
browser
field.
C
So
we
kind
of
thought
about
this
early
on
and
and
added
a
section
to
the
documentation,
called
conditions,
definitions,
I'll
just
link
it
into
the
discussion.
Now,
there's
the
link
in
in
the
documentation
and
the
the
original
goal
of
this
section
of
the
documentation
was
that
okay,
we've
got
these
conditions
in
node.
C
So
we
can
end
up
in
a
situation
where
my
version
of
what
a
browser
is
is
different
to
your
version
of
what
a
browser
is
and
now
I'm
writing.
We're
writing
our
packages.
With
this
with
this
browser
resolution
and
we're
not
clear
on
what
that
browser
resolution
is-
and
we
we
saw
a
little
bit
of
that
happening,
webpack
implemented
a
module
condition,
and
then
it
wasn't
clear.
You
know
if
what
that
condition
would
mean,
and
that
kind
of
thing
so
with
everyone
defining
their
own
conditions.
C
There's
a
coordination
problem
there,
and
so
we
created
the
section
thought
we
can
certain
conditions
we
can
list
and
list
them
as
node.js
conditions
that
in
the
darks
is
a
kind
of
sort
of
a
community
service.
C
The
use
case
for
why
the
why
defining
the
condition
helps
should
be
justified.
So
you
know
it
shouldn't
just
there
should
actually
be
a
coordination
bet
of
it
to
to
defining
it.
There
should
exist.
Existing
implementation
usage
of
that
condition,
it
shouldn't
conflict
and
so
so
trying
to
create
some
kind
of
guidance
around
that
and
how
one
could
coordinate
these
conditions.
C
So
there
didn't
seem
to
be
much
pushback
against
the
types
condition
which
angular
recently
released
in
their
new
package
guidelines
for
package.json
they're,
encouraging
the
types
condition
for
pointing
to
typing
files
and,
for
example,
by
our
listing
it.
It
can
help
popularize
that
condition
and
help
people
ensure
that
they
have
typing
for
all
of
their
their
separate
resolutions.
C
C
C
Yeah,
they
also
have
a
few
others
that
they
define
which
which
we
haven't
listed
variations
of
of
js
versions,
and
things
like
that.
But
I
didn't
want
to
open
up
that
kind
of
worms
just
yet
and
then
the
dino
condition
dino
have
implemented
in
their
node.js
resolution,
interrupt
layer,
support
for
the
dino
condition.
C
So
you
could
have
a
version
of
your
package
export
resolutions
which,
when
running
on
the
dino
platform,
you
can
point
to
a
different
module
and
and
get
a
sort
of
a
dino
native
version,
and
so
you
can
have
these
kind
of
universal
patterns.
And
so
those
are
the
two.
I
was
looking
to
add
as
examples
of
community
definitions
where
we
can
include
the
definition
clearly
define
it
and
provide
some
kind
of
coordination
service
where
we're
maintaining
that
list
as
a
public
thing.
C
Alternatively,
this
could
be
a
list
that
could
be
taken
out
of
the
node.js
documentation
to
move
to
its
own
project
or
repo
somewhere.
So
that's
the
kind
of
thinking
around
it
and
then
jordan
had
a
remark
saying
well.
We
shouldn't
have
a
reference
like
this
to
dino
in
the
node.js
documentation
and
dino
should
document
it
themselves
and
it's
their
responsibility
to
document.
C
C
If
we
want
to
continue
down
this
path
for
node.js
in
maintaining
this
as
a
kind
of
like
a
community
listing
of
conditions
and
the
process
around
that
or
if
we
want
to
move
it
out
somewhere
and
then
the
guidelines
around
what
conditions
we
want
to
list
and
if
we
determine
that
other
js
platform
conditions
are
suitable
to
list
or
not.
So
I
think
those
are
the
kind
of
questions
here
matteo.
You
were
the
one
who
were
commenting
on
this.
Did
you
want
to
maybe
add
some
thoughts
to
that.
D
So
there
are
two
fundamental
fundamental
concerns
for
me:
okay,
one
you
was
resolved
in
in
the
in
in
the
chain,
like
I'm
fine
with
the
current
text
as
it
stands.
Okay,
it's
before
that
it
was
well
it
it.
It
soft
implies
that
we
were
supporting
those
things.
While
is
now
clear
that
those
are
community
editions,
well-known
community
additions,
okay
anyway,
so
I
am
more,
it
could
probably
be
even
more
highlighted
the
fact
that
we
have
no
responsibilities
on
how
those
are
being
handled
so.
C
D
C
Clarify
on
that
point
briefly,
based
on
that
feedback,
I
added
a
commit
to
change
the
title
of
this
conditions:
definitions,
section
to
community
conditions,
definitions
and
and
clarified
a
bit
that
it's
it's
a
that
it
is
this
coordination
around
almost
third-party
conditions.
D
Yeah
as
long
as
it's
like
with
that
thing,
I'm
I'm
okay
in
listing
it
now,
the
the
second
concern
is
more
around
branding
and
marketing
and
a
bunch
of
things.
So
in
for
a
long
time,
we
had
the
position
of
not
mentioning
dino
in
any
communication,
mostly
so
it's
if
that
was,
and
we
have
been
silent
on
it
for
the
vast
majority
for
over
the
course
of
these
years.
So
that
would
mean
changing
that
attitude,
and
if
that's
okay,
then
I
am
good
with
that.
Take,
however,
it
needs.
D
D
If
somebody
wants
to
to
check
on
this,
like
it's,
not
something.
A
A
I
I
think,
like
my
first
question,
is,
is
this
that
that's
worth
discussing
here?
Is
this
the
right
place
to
document
these
or
like
in
my
mind
it
would
be
a
natural
fit
for
a
repo
under
the
openjs
foundation,
where
you
know
we
want
to
you
know
this
is
like
a
registry
of
conditions
across
the
javascript
ecosystem
right
and
that's
like
the.
E
C
Originally,
it's
sort
of
there
was
almost
an
effort
to
split
off
and
create
a
package
json
spec
by
devin
from
parcel,
and
when
that
effort
happened,
there
was
a
huge
amount
of
pushback
to
having
a
package.json
spec
in
the
ecosystem
for
some
reason
or
like
managing
it
in
one
place,
and
so
we
at
the
time
we
were
very
aware
of
that,
like
trying
to
specify
like
as
a
generic
package,
json
spec
can
be
difficult,
but
as
a
specific
exports
condition
thing,
it
could
become
its
own
repo.
C
The
the
thing
with
that
is
just
finding
the
people
who
are
willing
to
maintain
that
on
an
ongoing
basis
and
setting
up
process
around
it.
I
did
create
a
call
for
contributors
to
such
a
thing
to
see
if
there
was
interest-
and
I
did
get
interest
from
derek
who's
with
potentially
able
to
be
involved
in
that
at
the
moment.
I
don't
have
any
other
volunteers
for
setting
up
such
an
effort,
but
that
could
be
an
alternative.
A
D
F
I
am
I'm
fine
also
if
it
stays
in
the
note
project,
but
one
point
in
favor
of
having
it
outside
is
that,
since
it's
not
related
to
what
node
supports,
it
doesn't
need
to
be.
F
Node.Js
version
on
the
other
documentation,
so
if
we
add
dino
now
it
will
be
in
node
17
documentation.
Well,
it
will
not
be
in
note
16
until
we
backport
it.
A
I'm
also
wondering
I
think,
maybe
it
was
it
was
resolved
in
the
issue.
I
didn't
have
a
chance
to
to
to
read
the
issue,
to
see
how
you
know
how
it's
changed,
since
I
think
one
of
them.
One
of
the
concerns
I
also
saw
being
raised
was
like
documenting
things
that
the
projects
haven't
documented
themselves,
so
I
can
see
the
the
concept
of
a
registry,
but
it
almost
seems
to
me,
like
the
groups
projects
using
these
things
should
almost
be
involved
in
having
them
be
added
to
the
registry
right
versus.
C
We
are
kind
of
also
bootstrapping
a
process
here,
as
it
were,
so
I'm
always
trying
to
just
fill
in
examples
to
get
the
ball
rolling
on
that
as
well,
because
at
the
moment
that
initiative
isn't
in
place,
but
once
you've
got
a
few
more,
maybe
it
will
be
yeah
and
it's
it's
really
like
trying
to
fill
this
coordination
gap
in
the
best
way
and
and
communicate
that
and
that
the
node.js
docs
are
a
great
place
to
own
that
communication.
C
If
we
did
set
it
up
as
another
thing
linking
to
it
from
the
node.js
docs
would
be
a
great
help.
C
As
I
said,
my
concern
with
that
is
just
getting
that
process
set
up
and
and
that
we
could
always
move
it
across
at
any
time,
and
that
probably
is
what's
going
to
happen
eventually
if
things
grow
but
right
now,
it's
it's
still
a
bootstrapping
process
of
of
maybe
you
know,
clarifying
these
patterns
and
developing
these
patterns
and
processes
where
people
can
see
how
how
these
things
can
be
put
together
and
clearly
defined
and
yeah.
C
So
dino
is
just
a
very
good
example,
because
it's
a
it's
a
situation
where
there's
a
way
you
can
write
a
package
that
can
basically
be
compatible
between
these
two
environments
and.
C
So
it's
kind
of
the
first
example
of
that.
So
if
you've
got
you
know,
browsers
and
and
these
clear
definitions,
we're
kind
of
starting
to
build
that
pattern.
A
Yeah,
I
suspect
it
would
be
relatively
easy
to
get
like
an
open,
js
repo.
So
like
the
mechanics
of
getting
a
repo
and
getting
text
in
there,
I
guess
the
question
is
more
about
like
you're
saying
in
terms
of
like
who
can
modify
and
add
things
right.
A
C
Yeah
exactly
that,
just
the
risk
of
it
getting
neglected
or
missed
or
dropped,
whereas
in
the
node.js
documentation
there's
their
constant
eyes
on
it,
and
if
it's
something
that
people
see
changing
over
time
and
developing,
then
hopefully
more
process
can
be
built
around
that
yeah,
so
that
that's
the
kind
of
goal.
So
if
there's
a
dino
topic
is
the
kind
of
a
tipping
point
to
say
we
should
separate
it
already,
then
we
can
certainly
do
that.
It's
just
about
not
doing
too
much
work
up
front.
C
Basically,
so
you
know
maybe
this
maybe
maybe
this
doesn't
turn
into
such
a
big
effort,
it's
difficult
to
predict
what
the
future
holds
as
well.
C
Does
anyone
have
any
any
concerns
specifically
about
about
the
dino
listing,
or
is
there
any
kind
of
marketing
concern
there
that
we
generally
need
to
think
about,
and
I
can
completely
appreciate
if
that
is
the
case,
and
I
think
that
was
you
know,
jordan's
and
matteo's
point
that
there
is
this,
this
question
of
or
branding
perhaps,
and
if
anyone
feels
uncomfortable
about
it.
I
think
that's,
that's
that's
a
useful
wedge
to
kind
of,
say:
okay.
Well
then,
let's
split
this
out
into
a
new
open,
js
repo.
A
Like
that
was
the
point
that
resonated
with
me
like,
if
it's
not
something
that's
been
publicly
discussed
or
documented
in
the
project,
it
almost
seems
a
little
premature
to
include
it
in
in
the
list.
That's
where
I
was
coming
from,
like
you
know.
Ideally
there'd
be
some.
You
know
the
project
defining
one
of
these
things
would
actually
be
involved
in
adding
and
saying
yeah,
that's
something
that
we
actually
support
and
want
to
reserve
that
name.
Space.
C
Yeah,
if
it
would
help,
I
could
try
and
see
if
there
is.
C
Interest
from
the
dino
side
in
actually
pushing
for
this
to
actually
indicate
that
they
intend
to
to
see
this
definition
clearly
defined.
Does
that
help.
F
C
Yeah
I
mean
it's:
it's
bootstrapping
a
coordination
effort,
as
I
say
so.
The
the
first
few
people
aren't
aware
that
they
have
the
ability
to
create
the
to
to
engage
in
this
process,
and
I
think
some
degree
of
coordination
is
important,
because
types
could
mean
like
a
lot
of
things,
to
a
lot
of
people
and
and
the
by
making
sure
that
we
have
these
very
clear
definitions
that
are
maintained
and
are
very
carefully
considered
from
an
interrupt
perspective.
C
We
can
make
sure
we
avoid
confusions
down
the
road
where
things
are
not
clearly
defined
or
or
packages
end
up
in
situations
where
they
they're
not
behaving
correctly
in
different
environments
and
things
like
that.
So
types
we
do
have
on
the
review
of
that
pr.
At
the
moment,
where's
wigan
from
typescript
who's
been
working
on
the
esm,
integration
of
the
node
asm
integration
for
typescript
and
following
the
node
resolution
in
typescript,
so
he's
exactly
the
one
who's
been
on
that
and
he's
from
what
I've
seen
from
the
reviewer.
C
So
far,
okay
with
with
us
landing
it
he's
not
actively
pushing
for
it.
I
could
try
and
get
engagement
from
angular
as
well
to
get
an
okay
from
them
that
they're
happy
with
that
definition,
and
that
could
possibly
also
demonstrate
engagement
on
that
one.
C
I
I
mean,
I
think,
if
that's
the
criteria
to
to
see
that
there's
demonstrated
implemented
interest
of
the
people
who
are
actually
implementing
these
things.
That
sounds
like
a
perfectly
valid
criteria,
to
make
sure
that
we're
checking
off
on
in
these
prs
and
also
generally
as
a
process.
C
Right,
so
you
know
as
the
as
the
project
that
that
is
effectively
specified
the
these
resolution
behaviors.
It
was
the
natural
harm
to
shepherd
these,
these
community
conditions,
but
certainly
it's
as
I
say.
If
there's,
if
there's
a
strong,
wedge
argument
for
why
we
should
not
be
maintaining
this
in
node
core,
it
can
drive
a
separate
reaper.
So
yeah,
I'm
just
following
the
path
of
least
resistance,
as
it
were
to
try
not
to
over
engineer
anything.
D
C
A
browser
will
be
resolved
by
bundlers
when
building
for
the
browser
and
development
and
production
are
supported
in
webpack
and
were
coordinated
in
the
node.js
docs.
During
that
time,.
H
I
feel,
for
example,
browser
I
think,
that's
more
up
for
the
bundlers
to
decide.
You
know.
Okay,
we
we
all
agree
that
there
is
a
type
called
modul
browser
and
what
that
means
like.
F
H
C
And-
and
they
are
the
ones
who
define
it,
the
point
is
that
they
need
to
be
defined
somewhere
central
so
that
stakeholders
have
a
place
to
define
it,
and
if
everyone
defines
their
own
things
on
their
own
projects,
we
do
risk
the
coordination
problem.
Where
you
know
people
come
up
with
different
meanings
for
browser.
What's
the
browser
who
defines
what
a
browser
is
right,
so
we're
kind
of
trying
to
play
some
role
in
that.
H
C
Okay,
hey.
A
C
A
The
it
sounds
to
me
like
the
two
key
questions
to
answer
are,
like
you
know,
do
we
think
it
should
be
in
node
core
or
a
separate
repo
and
then
like
adding
the
criteria
of
having
like
some
feedback
from
the
project
to
say,
yeah
we're.
You
know
what
you're
defining
there
makes
sense,
because
in
the
places
that
define
it.
A
A
You
know
if
we,
if
we
added
that
criteria
and
got
some
feedback
from
you,
know
the
dino
and
from
the
types
projects.
Would
everybody
here
be
comfortable
landing
in
in
the
node
repo
to
start
or
is
it
you
know
something
we'd
prefer
to
explore.
You
know
putting
it
in
an
open
gs,
repo
or
something
like
that.
C
I'm
happy
to
go
with
that
and
and
to
say
that,
if
it,
if
it
grows
significantly,
that
it
then
can
move
out
to
its
own
project,
when
there's
significant
enough
momentum
to
sustain
that-
and
I'm
happy
to
have
that
as
there's
already
a
note
that
it
would
be
moved
out
to
its
own
place
in
future.
So
I
think
we
can
align
on
that
and
agree
that
that's
what
happens
eventually
and
then
for
now.
I
can
aim
to
get
implementer
validation
for
for
these
before
landing
further.
A
A
A
A
We
still
have
a
few
and
I
can't
I'm
not
sure
if
there's
been
any
progress
on
any
of
those,
I
haven't
had
a
chance
to
take
a
look
recently.
Anybody
else
have
any
updates.
They
want
to
share.
A
Okay,
no
updates
on
on
that
one.
The
next
one
is
three:
zero:
six,
nine,
seven
migration
of
core
modules
to
provide
primordials,
I
think
jarish.
You
were
leading
the
effort
to
define
a
vote
on
that
one.
I
We
have
come
around
three
viable
options
for
voting,
but
in
one
of
the
earlier
instances,
ruben
suggested
that
he
want
to
present
additional
cases,
for
you
know
some
of
the
views
that
were
missed
in
earlier
discussions
and
he
has
actually
come
up
with
a
number
of
options,
basically
concrete
options
for
the
dsc
to
consider.
So
that's
all
documented
in
the
issue.
I
My
viewpoint
to
this
elaborate
list
of
options
is
that
in
the
very
first
place
we
went
with
a
confined
discussion
with
smes
on
this
topic
was
to
basically
zero
down
the
options
to
one
or
two
most
meaningful
choices,
so
that
pc
can
deliberate
and
have
a
look,
and
you
know,
sway
on
either
side.
I
So
probably
the
most
reasonable
one
or
two
or
three
options
coming
up
for
voting,
looks
good
to
me.
If
we
are
not
yet
there,
we
should
do
some
more
work
and
present
top
three
options
to
the
dhc
forwarding.
I
Option
one
is
to
migrate
a
subset
only
whereby
the
subsidy
is
not
yet
fully
formed.
So
that's
where
we
wanted
assistance
from
people
like
bradley
and
jordan
etc,
who
were
advocate
for
this
option
in
a
strong
manner,
but
they
had
they
had
their
own
reasons
why
they
want
to
have
the
primordials
for
security
and
robustness
perspective
so
option
one
is
not
fully
formed.
I
While
I
can
agree
that
option
two
and
option
three
are
loose,
we
could
revisit
that
and
tighten
those.
But
all
my
point
is
having
10
options
for
tsc
to
vote.
I
can
very
well
see
how
the
outcome
is
going
to
be.
It
can
be
inconclusive.
B
In
other
words,
in
other
words,
it's
I
think
I
think
and
correct
me
from
wrong
great
that
that
grace's
point
is
that
that
expanding
it
to
10
or
12
options
is
not
going
to
have
a
it's
not
going
to
have
a
good
result
when
brought
to
the
tsc
people
won't,
engage
and-
and
it
will
take
a
long
time
to
come
to
a
decision.
If
we,
you
know
we'll
face
the
same
same
potential
for
for
for
impasse
and
deadlock
that
that
the
larger
community
has
faced
with
this
discussion
and
so
on
and
so
forth.
B
So
the
idea
was
that
you
know
subject
matter.
Experts
would
would
reduce
it
to
to
a
you
know
two
three,
maybe
four
of
the
most
compelling
options
and,
and
maybe
those
maybe
maybe
that
maybe
this
list
of
three
options
is
not
that
list
yet
and
it
needs
a
little
more
work.
But
I
I
definitely
I
definitely
agree
with
what
I
think
garish
is
saying,
which
is
that
we
do
not
want
to
bring
like
10
or
12
options
to
the
tsc.
D
Well,
there
is
also
the
fact
that,
if
we
vote
in
the
same
way,
we
voted
for
promises.
In
fact,
we
we
can
support
as
many.
B
D
D
B
I
mean,
I
guess
I
guess
we
could
vote
on
the
outcome,
but
but
part
of
part
of
deciding
the
outcome
is
deciding
whether
the
cost
of
the
outcome
is
worth
it
like
yeah.
I
want
tamper-free
modules.
Do
I
want
tamper-free
modules
at
you
know,
at
the
cost
of
of
you,
know
massively
more
complicated
implementation
and
much
worse
performance.
I
might
not,
or
maybe
I
would
I
don't
know,
but,
like
you
know,
it's
the
trade-offs
that
need
to
be
considered
and
that
those
are
going
to
involve
implementation
details.
I
think.
D
You
can
decide
that
you
want
tamper-free,
I
I
personally,
I
don't
understand
how
that
could
help,
because
we
have
you
could
basically
wreck
node.js
in
a
lot
of
ways,
even
though
the
internals
are
temporary.
Okay,
like
as
long
as
you
have
access
to,
I
think
hooks
and
a
few
other
things
all
bats
are
off.
Okay,
I
am
you
know
there
will
be
a
lot
of
pampering
like
it's
a
very
large
surface
area.
Okay,
that's
what
that's
what
I
meant
right
and
that's
the
first
one.
D
H
From
from
a
practical
perspective,
the
way
I
see
this
doing
everything
primordials
and
doing
nothing
as
primordials
are
not
viable
options,
because
it
shows
no
compromise.
So,
basically,
what
we
have
to
decide
is:
what
do
we
make
to
tamper
proof?
Not
if
we
make
everything
or
nothing
it's
more
about
what
do
we
do
tamper
proof?
Otherwise,
some
no
one
is
gonna.
We'll
have
people
that
are
very
unhappy,
so
we
need
to
find
a
compromise
solution
here.
I
We
stopped
somewhat
stopped
the
migration
work
because
we
came
across
the
performance,
ditches
and
probably
performance
is
not.
A
real
reason
is
where
we
are
going
to.
Instead,
the
tamper-free
modules
such
as
loaders
are
taken
very
seriously,
and
then
we
look
at
the
objective
as
which
are
the
critical
modules
that
should
be
migrated
which
are
not
so
much
critical
etcetera.
So
that's
that's
what
the
option
one
is
shaping
up.
A
A
That
might
be
one
question
then
separately.
I
could
see
like
okay.
How
do
we
want
to
achieve
that
through
primordials
or
moving
code
to
c
plus,
because
those
are
almost
like
two
different
dimensions
right
like?
What's
our?
What
what
do
we
want
to
set
as
a
goal
and
then
separately?
How
would
we,
how
do
we
think
getting
to
that
goal,
makes
sense.
H
No,
I
don't
want
to
push
these
two,
but,
although
of
those
fours
you
just
mentioned,
I
think
three
of
them
are
not
viable.
The
one
where
we
do
everything
type
of
free,
not
viable,
the
one
where
we
do
nothing
temper
free,
not
viable
the
one.
We
only
make
those
things
that
are
not
performance,
sensitive
time
for
free
the
amount
of
work
it
takes
to
ensure
it
doesn't
have
any
performance
impact
and
when
it
does
the
amount
of
work
we
need
to
do
to
figure
out.
H
I
Yeah
one
consensus,
or
a
good
number
of
folks
agreed,
is
that
performance
is
probably
not
a
big
reason
to
consider
here
so
eventually,
when
we
go
for
voting,
look
at
migration
with
performance
in
consideration.
I
B
I
I
think
gracious
are
you
saying
that
would
be
an
option
to
vote
on
or
that
performance
is
I'm
sorry,
I'm
having
a
hard
time.
I
Yeah,
that's
one
of
the
option
to
vote
for
her,
because
both
bradley
and
jordan
was
kind
of.
I
mean
they
were
quite
confident
to
say
that
if
you
are
looking
at
tamper-free
node.js
platform,
as
opposed
to
the
browser
and
certain
aspects,
if
they
are
coming
for
exposure,
then
security
should
not
be
a
consideration
or
a
comparison.
B
Right,
so
so
so
like
so
to
summarize,
what
I
believe
is
is,
for
example,
bradley's
position.
You
know
perform
basically
what
she
said.
Performance
performance
should
not
be
a
consideration.
B
This
is
if
people
want,
you
know,
hyper
performance,
whatever
they're,
probably
not
using
node
is,
is,
is
kind
of
the
general
argument,
and
I
don't
know
that
that's
true,
but
that
that
is
but
but
but
I
don't,
I
also
don't
think
he's
the
only
person
who
who
would
make
that
case
so
yeah
that
might
be
worth.
I
Yeah
I
mean
if
we
are
talking
about
the
performance
dates
which
we
are
measuring
from
the
currently
established
baseline,
that
baseline
is
actually
established
on
top
of
a
a
tampa
vulnerable
platform.
B
Yeah
and
then
jordan's
position,
as
I
understand
it
is
that
is
that
perform
is
that
is
that
correctness
is,
is
what
needs
to
be
given
primacy
over
performance
that
that
that
that
you
know
monkey
patching
something
you
know
tampering
with
protocol
with
prototypes
should
not
should
not.
You
know,
affect
behavior
of
node
core,
and
if
it
does,
that's
a
that's,
you
know
that's
a
bug
in
his
per
in
his
perspective,
not
now
both
of
those
positions,
though
I
don't
think
have
any
traction
on
the
tsc
someone.
B
B
I
B
Know
yeah
I
mean
I
and,
and
I
mean
has,
has
the
decision
already
I
mean.
Has
a
decision
already
been
made?
I
guess
is
a
question
which
is
that
you
know
it
is
a
decision
that
we
need.
You
know
we
need
to
decide
that
some
things
get
primordial
and
some
things
don't
and
and
then
the
question
in
the
heart
the
hard
day.
The
hard
question
is
like:
how
do
we
make
that
decision
like?
B
How
do
we
decide
because
the
way
we
were
doing
it,
which
is
implement
it
measure,
performance
and
hope,
really
really
deeply
wasn't
working
for
the
project?
I
see
antoine
has
his
hand
up
so
I'll
stop
talking.
So
he
can
say
something.
G
Thank
you.
So
if
I
remember
correctly,
bradley's
point
was
about
the
esm
module
system,
not
the
entirety
of
core.
So
I
don't
know
if
that
changes
what
you
were
saying,
but
his
point
was
we.
We
should
have
some
some
things,
temper,
proof
and
and
then
do
the
performance
baseline
for
and
yeah
it's
not
moving
everywhere.
Then
you
know
he
had
some
specific
modules
in
mind
when
you,
when
you
were
saying
that.
H
I
mean
I,
I
think
that
can
make
sense
like
in
the
module
loading
system
performance
there.
It's
not
the
end
of
the
world.
It
doesn't
affect
so
much
most
contributors,
so
I
would
be
neutral
on
that
specific
so
that
that's
what
I
mean.
G
The
the
thing
where
it's
complicated,
it's
the
module
system
uses
other
core
modules,
such
as
fs
and
other
stuff.
I
don't
have
the
full
list,
but
it's
all
the
dependency
of
the
module
system
would
need
to
be
temporary
as
well.
Otherwise,
it's
not
effective
security,
wise.
H
I
I
to
get
along
here.
I
would
like
to
have
like
a
list
of
modules
that
we
would
like
to
have
listed
and
then
it's
easier
to
discuss.
Okay,
it
makes
sense
here.
It
doesn't
make
sense
here
or
you
know,
module
systems
that
would
be
nice,
but
what
are
the
dependencies
that
also
need
to
be?
You
know
if
it's
not
so
many
okay,
no
problem.
If
it's
a
huge
a
lot
of
things,
then
maybe
that's
more
up
for
discussion
and
yeah.
A
I
I
believe
it
makes
sense
for
ruben
to
put
in
his
proposals
and
then
look
at,
which
are
the
modules
that
tsc
believes
are
supercritical
in
terms
of
correctness
and
tamper-free
behavior,
and
then,
with
that
we
can
revisit
the
options
with
the
ruben's
concurrent
concurrence
as
well
and
then
go
for
voting.
I
A
And
I'm
just
gonna
add
my
last
two
cents
that
I
really
think
it
comes
back
to,
and
I
think
this
bit
what
ronag
is
saying
too
is
like
it
comes
back
to
where
and
how,
like
those
are,
two
questions
that
are
key
like.
Where
is
it
that
we
think
it's
appropriate
and
then
how
would
we
do
that?
So
if
we
had
questions
that
basically
had
the
feasible
options
and
those
two
that
might
get
us
formed
sure,
okay?
So
let's
move
on
to
the
next
issue?
A
B
Yeah
I'm
trying
to
put
together
a
meeting
for
people
who
are
who
who
have
suggested
that
they
might
have
time
to
do
some
triage
and
I
I
think
I
got
replies
from
everybody
except
for
danielle
and
robert.
So
please
reply
to
the
doodle
poll
or
send
me
an
email
or
something
or
I'll
I'll,
follow
up
with
you
later
today.
If
you
don't
so,
don't
worry
about
it.
A
Okay
thanks
next
one
is
mini
summit
november
18th,
which
is
tomorrow,
so
it's
10
to
2
eastern
would
really
be
great
to
have
people
from
the
tsd
there
to
discuss.
You
know
what,
if
anything,
we
should
be
thinking
about
doing
for
types
and
for
single,
creating
single
binary
exes.
A
So
on
the
agenda
as
an
fyi.
I
don't
think
anything
anything
more
really
to
add
on
that
one.
The
issues
there
if
you're
interested
in
showing
up
at
this
point
we
have
five
minutes
left
and
I
would
like
to
spend
a
few
minutes
in
the
private
session.
So
I
would
suggest
we
skip
the
strategic
initiatives
unless
there's
anything
key
that
people
want
to
add
on
that
front.