►
From YouTube: 2020-01-08-Node.js N-API Team 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
we're
live.
Welcome
to
the
node.js
napi
team
meeting
for
the
8th
of
january
2021,
I
always
got
to
remember,
say
2021.
Now
we
have
a
special
guest
darshan
who
here,
who
we're
going
to
talk
about
a
couple
of
issues
that
he's
opened
and
we
haven't
had
a
chance
to
to
get
with
get
to
take
a
look
at
so
we're
hoping
that
we
can
help
that
will
help
us
close
on
them
more
quickly
and
then
we'll
get
back
to
the
the
regular
agenda.
A
B
A
A
Maybe
we'll
just
go
back
to
the
things
we
have
tagged
and-
and
we
can
do
that
and
then
switch
back
once
he's
rejoined.
Let
me
get
back
over
there.
A
C
A
D
A
About
so,
okay,
sorry,
which
which
piece
is
being
done
in
both
the
child
and
the
parent
process,.
D
The
test
module
generation,
this
one
it's
being
com
here
and
then,
based
on
the
note
version,
the
files
are
getting
removed.
A
A
E
F
E
E
A
F
Exactly
but
there's
no
point,
there's
no
point
in
in
in
in
splicing
and
slicing
and
dicing
the
tests
to
run
if,
if
you're,
not
gonna,
run
them
in
the
process
that
you
are
so
okay
yeah.
It's
basically
like
replace
yourself
with
the
with
the
process
having
the
correct
command
line
arguments
even
earlier
before
you
start
munching
on
the
on
the
test
list
right:
okay,
yeah,
that
makes
total.
A
A
A
That
and
I
think
you
had
a
second
one-
yes.
D
It's
kind
of
based
on
what
the
comments
said
previously
and
over
here
before
the
test
module
start.
It
says
that
fix
me.
We
might
need
a
way
to
load
test
modules
automatically
without
explicit
declaration
as
follows.
So
I
just
got
rid
of
this
whole
list
and
added
my
own
code
to
just
load
all
the
file
names.
E
A
A
E
E
E
Yes,
I
think
my
only
change
would
be
the
removal
of
the
depth
requirement
and
then
I
think
it
would
be
good.
F
If
the,
if
we
don't
have
one
yeah,
we
don't
okay,
so
if
the
depth
is
one
doesn't
it
currently
skip
all
the
stuff
in
thread?
Save
function
because,
like
if
I
look
at
test
it
has
a
subdirectory
called
threadsafe
function,
which
has
several
js
files.
So
if
the
depth
is
one
then
does
it
not
skip
like
say,
function,
ctx,
dot,
js
and
thread
say
function,
existing
tsfn
js
and
all
those.
F
F
F
So
yeah,
I
think
I
think
I
think
we
need
like
we
need.
We
need
the
multi-level
thing,
so
I
mean
basically
recursion
and.
A
F
F
Okay,
I
see
I
see
so
so
it
assumes
that
if
it's
a
directory,
then
the
director
will
have
an
index.js,
which
is
the
thing
to
test
right,
so
so,
okay,
so
if
if
one
of
the
entries
in
the
in
the
directory
is
itself
a
directory,
then
it
assumes
that
its
structure
is
such
that
it
is.
It
is
a
self-contained
test
with
entry
point
index.js,
which
is
not
the
case.
I
don't
believe
right
because
we
don't.
We
don't
have
anything
like
that.
Let
me
go
into
test
and
see
the
subdirectories.
F
F
E
F
F
A
I
guess
sorry
there
is,
I
mean
I
guess
there
is.
B
F
A
G
B
F
So
so,
basically,
looking
looking
at
at
your
code
that
that
handles
each
entry
given
by
read
their
sync,
the
top
level
read
their
sync.
It
looks
like
you
handle
the
the
entry
in
in
one
of
three
ways:
either
it
matches
either
it
matches
one
of
those
file
names
in
the
long,
if
statement,
and
then
you
skip
it
or
it's
a
directory
in
which
case.
F
If,
if
the
directory
has
an
index.js,
then
then
you
consider
that
to
be
the
entry
point.
Otherwise
you
look.
Otherwise
you
you
iterate
the
directory,
the
subdirectory
and
you
take
all
the
you.
Take
all
the
you
seem
to
take
all
the
files.
Is
it
substring,
okay,
yeah,
so
you
should
probably
for
for
the
second
case,
like
lines
28
and
below.
You
should
probably
filter
for
js
files,
because
there
may
be
cc
files
in
there
as
well
in
the
subdirectory,
and
I'm
not
seeing
the
place
where
you
can.
D
Get
rid
of
the
extension
at
9.32
and
I'm
getting
rid
of.
I
mean.
D
F
Okay,
so
that's
okay,
but
I
would
still
rather
you
search
for
you'd
skip
non-js,
because
it's
conceivable,
it
doesn't
currently
happen,
but
it
is
conceivable
that
there
are
cc
files
which
do
not
match
any
of
the
js
files,
in
which
case
you
will
assume
that
there's
a
js
file
by
that
name,
even
though
there
isn't
so.
I
think
it
would
be
safer
to
to
just
filter
for
js
files
and
not
and
not
assume
that
for
for
every
js
file,
there
is
an
equally
named
cc
file.
B
F
A
Yeah,
I
think
that's
good,
so
yeah.
I
think
we
all
it
sounds
like
everybody
agrees.
This
is
a
good
concept
and
just
a
few
suggestions,
the
one
that
you
know
doesn't
necessarily
need
to
be
done
in
this
pr,
but
it
might
be
good
for
us
to
actually
add.
A
A
naming
construct
into
this
so
that,
like,
for
example,
everything
which
is
a
test
starts
with
test
underscore
so
that,
like
in
the
future,
if
we,
if
we
need,
like
you,
know
javascript
files
which
are
supporting
files
and
which
aren't
tests,
we
don't
actually
try
and
run
those
yeah.
We
have
that
in
core,
so
you
know,
I
think
I
think
it
doesn't
need
like.
I
said
this.
A
D
A
Right,
like
the
c,
the
c
files
will
be
what
build
an
add-on,
but
the
add-ons
are
only
accessed
through
the
javascript
test
files
which
require
them
and
then
run.
You
know.
Methods
on
on,
you
know
require
them
which
causes
the
c
plus
plus
add-on
to
be
loaded,
and
then
we
call
methods
on
that
on
that
add-on.
A
So
I
yeah,
I
think,
if
you
know,
if
we'd
named
them
test
underscore
and
then
the
the
currentname.jet.js,
then
it
would
be
clear
like
what's
the
thing,
what
what
are
the
tests
that
you
run
would
avoid
us
from
getting
into
trouble
in
the
future,
but,
like
I
said
that
could
be
a
follow-on
it
doesn't.
I
don't
think
that
this
needs
to
be
part
of
this
specific
one.
F
A
So
those
two,
those
two
things
like
there's:
no
reason
to
artificially
limit
it
to
one
level
yeah
and
then
to
filter
to
js
files.
Then
then
I'd
be
happy
with
this
one
too
yeah,
and
then,
if
you
want
to
do
a
follow-on
that
you
know
renames
them
to
be
test
underscored
at
the
start
and
filters
it
to
that.
That
would
be
super
great
too
sure.
I
can
do
that.
Okay!
Well
thanks.
A
A
Everybody
should
have
gotten
the
email
that
was
forwarded
from
the
mentoring
team,
who's
who's
working
to
to
find
a
mentoring
candidate
to
work
with
us
and-
and
you
know,
kind
of
the.
The
idea
I
had
is
that
we'd
all
help
mentor
that
person
as
a
team
we
could
talk.
You
know
we
could
use
part
of
the
meeting
that
we
have
weekly
to
to
discuss
any
issues
that
they
have
sort
of
provide
direction
and
guidance
as
well
as
being
available
through
you
know.
A
You
know
offline
chat,
one-on-one
and
kind
of
stuff,
but
I
wanted
to
make
sure
everybody
thought
that
was
a
reasonable
idea
had
any
concerns
questions
about
the
the
stuff
that
they
forward
us
in
terms
of
like
the
they
had
an
example,
a
sample
task
to
try
and,
like
you
know,
find
look
to
figure
out
good
matches
for
candidates
and
stuff
like
that.
I
A
Me,
okay,
okay,
sounds
good
this
and
you
know,
of
course,
if
you
have
any
ques,
you
know
specific
comments
on
the
the
the
dock
there
you
can,
you
can
add
them
and.
C
A
A
A
Okay,
so
I
don't
know
if
people
had
had
caught
this
one
but
there's
a
suggestion
that
we
rename
an
api
to
something
else.
You
know,
I
guess
nappy
is
a.
Is
a
term
that's
potentially
derogatory
and
napi
sometimes
gets
you
know
just
from
the
spelling.
People
use
that
at
times,
instead
of
an
api,
although
we
have
been,
we
have
been
working
to
try
and
make
sure
people
use
napi
versus
anything
else.
A
F
I
for
one,
I'm
concerned
with
putting
the
word
node
in
there,
because
part
of
the
api
has
nothing
to
do
with
node
and
everything
to
do
with
the
with
the
engine
itself
right
and
we've
already,
where
the
files
already
reflect
that.
So
in
a
sense,
that
is
an
opportunity
to
to
detach
the
the
non
node
specific
stuff
from
node
right.
So
we
can
start
with
a
letter
other
than
n
at
least
those
portions
of
the
api.
F
A
I
I
was
kind
of
thinking
that
node
api
does
match
like
we've
and
we've
actually
got
includes,
which
are
node
api,
like
our
includes
in
node
our
node
api,
which
then
include
the
js
native
api.
So
if
we're
going
to
refer
the
two
things,
there's
like
a
js
native
api,
which
is
a
subset
of
node,
api,
yeah
and-
and
so,
but
but
we're
mostly
like
in
our
docs,
we're
basically
talking
about
the
node
api
because
we've
we
have
subsetted
it,
but
we
don't
really
talk
too
much
about
the
js
subset.
B
F
A
F
We
so
far
for
some
length
of
time,
which
is
probably
counted
in
years.
We
would
have
a
a
great
big
number
of
new
symbols
on
the
node.js
binary.
Actually,
I
was
I
was
wondering
like.
A
A
All
the
symbols
are
named
that
I
had.
I
was
thinking
that
we'd
said
because
the
name
the
file
is
node
api
yeah,
but.
E
H
Is
the
concern
primarily
the
public,
how
it's
publicly
known,
does
the
concern
extend
into
the
the
naming
of
the
symbols
like.
A
Yeah,
well,
I
think
it
does.
If
you,
you
know,
if
you're
gonna
in
terms
of
you
know
other
things
like
a
blacklist
and
whitelist
and
stuff
the
it's
been
an
effort
to
remove
those
from
the
code
base.
F
F
The
fact
is
that
that,
in
discussion,
when
you're
talking
about
and
and
I'm
and
I
know,
discussion
is,
is
not
something
that
happens
often
these
days
because
we're
all
far
away
and
we're
mostly
talking
asynchronously
to
each
other,
but
I
believe
that
if
you're
having
a
face-to-face
discussion
and
talking
about
calling
various
functions,
you're
gonna
call
them.
You
know
you
know
you're
gonna
say
something
like
you
know.
F
You
need
to
use
nappy,
create
the
async
work
yeah,
you
know,
and
you
you
need
to
you
know
you
need
before
you
call
you
know
before
you
can
assume
the
threat
say.
Function
is
dead,
you
need
to
call
nappy,
release,
threat,
safe
function,
and
so
that's
what
the
discussion
will
sound
like
with
with
the
symbols
as
they
are
right,
even
even
if
you
make
an
effort
to
call
the
whole
thing
an
api,
it's
just
too
too
cumbersome,
I
believe
to
say
you
know
an
api
create
boolean,
an
api
call
thread
say
function.
F
People
won't
say
that
it's
just
too
convenient
not
to
so.
On
the
other
hand,
I
I
don't
know
how
cumbersome
it
will
be
to
say
you
know,
node
api.
You
know
great
threat,
safe
function,
right.
A
A
F
Yeah,
okay,
so
let's
let's,
let's,
let's
ask
the
question:
I
think
right,
like
yeah.
Is
this
going
to
go
down
to
the
symbols
or
not
right.
A
A
F
Well,
I
I
was
thinking
like
you
could
probably
well
one
way
to
do
it
would
be
to
have
the
new
new
function
called
the
old
function,
but
that's
that's.
An
extra
function
call
right,
so
you
you
wanna,
make.
B
F
As
as
as
as
as
cheap
as
possible,
so
the
other
solution
that
I
thought
about
would
be
to
to
just
have
have
them
all:
be
v8
v8
impul,
all
the
implementation,
they're
just
v8,
impul
and
then,
and
then
both
of
them
called
that
and
we
make
them
in
line,
and
so,
but
that
would
duplicate
the
code
that
would
that
would
double
the
code
size
right,
because
you
know
now
now.
If,
if
it
got
in
line
in
two
places,
then
that
would
be
twice
the
code
right
so
could.
F
Yes,
we
could.
We
could
use
c
preprocessor
macros
that
that's
true,
but
then
you're
not
really
changing
the
symbols
so
but
yeah.
F
Yeah
so
yeah-
I
I
guess
I
guess
yeah
providing
a
duplicate
set
of
symbols
is
is,
is
not
trivial
if
we
want
to
keep
the
performance
and
and
for
us
for
us,
every
call
counts,
because
it's
already
so
expensive
to
cross
the
boundary
from
javascript
right.
So
right.
F
Add
any
overhead
if
we
can
avoid
it
now,
the
question
is
how
important
is
saving
space
right
I
mean
node.js
is
usually
used
on
servers
where
disk
space
well,
but
I
guess
it's
also
memory
space
is
is
quite
an
issue
right,
so
so
in
terms
of
in
terms
of
having
like
what
is
that
called
the
density
density
of
node.js
processes
on
any
given
server
would
be
reduced
if
we
greatly
increased
the
code
size
right.
So
we
would
also
have
to
check
how
much
this
increases
the
code
size
because
it
would
affect.
F
I
I
don't
know
if
there's
a
I
don't
know
if
there's
sort
of
like
a
like
a
tooling
level
solution,
like
some
some
kind
of
a
new
extension
or
something
where,
where
you
can
alias
a
function
and
it
will
create
two
symbols.
F
But
but
it
will
create
like
a
very
cheap
sort
of
assembly
level,
jump
to
to
the
old
symbol
rather
than
rather
than
a
full-fledged
function.
Call,
and
I
also
don't
know
if,
if,
if
you
know
having
a
function,
body
that
consists
of
a
single
call,
will
be
optimized
down
to
that
or
not.
B
F
We
could
we
could.
We
could
do
like
a
test
to
to
alias
one
of
the
apis
and
see
how
much
of
a
performance
hit.
It
is
to
just
have
a
a
symbol.
Call
another
call
another
method.
If,
if
it's
not
too
much,
if
it's
like,
maybe
like
point
five
percent
because
it
gets
optimized
so
heavily,
then
we
might
be
fine
to
just
create
the
whole
new
api
and
and
just
and
just
have
the
functions
called
the
old
functions.
F
F
A
F
A
F
A
If
we
actually
went
to
one
of
those,
I
don't
think
like
having
something
always
referred
to
c
api.
But
then
you
go
and-
and
you
know
include
something
called
node
api-
isn't
as
intuitive
as
like
any
pi
and
node
api.
Or
you
know,
okay,
they
both
have
n
in
them
right.
F
F
F
B
F
A
H
I
I
would
support
that
michael
it
it
it's
much
more
descriptive,
the
c
api
or
s
api,
don't
really
convey
any
specific
meaning,
and
you
know
in
the
google
world,
if
you
were
to
do
a
like
a
google
search
for
c
api.
A
H
Yeah,
because
I'm
thinking
like
what
I
would
do
is
go
back
to
the
tooling
projects
that
I
did
to
update
the
documentation
and
the
the
new
name,
the
way
I
envision
it
would
be,
it
would
say,
node
dash
api
and
then,
in
parentheses,
I
could
put
formally
n
dash
api
as
as
a
transition
right.
So
I
I
think
it's
much
more
natural.
A
F
Kind
of
I
I
kind
of
see
this
as
a
missed
opportunity
to
to
sort
of
let
the
that
the
js
native
api
sort
of
come
into
its
own,
but
I
do
have
to
recognize
that
it
is
part
of
node
api.
So
we
might
end
up
calling
you
know
like
node
api
create
boolean,
even
though
it's
not
node
specific.
F
It'd
be
it'd,
be
nice
if
we
could
find
a
name
that
distinguishes
the
fact
that
that
it's
that
it's
it's
not
note
specific,
yet
retains
sort
of
the
the
the
node
origins
of
it.
But
I
I
don't.
I
mean
aside
from
having
a
really
long
prefix.
I
don't
see
how
we
could
do
that
in
a
in
a
short
and
succinct
way.
A
F
I
Oh,
I
I
because,
if
you
want
to
create
an
api
function
for
other
runtime,
you
have
only
the
javascript
part
in
common
yeah
and
and
that's
it
so
we
need
the
other
stuff.
What
to
now.
We
have
on
node
api
and
underscore
api
yeah.
I
depend
on
on
on
the
runtime,
specifically
so
yeah
it's
right
to
have
these
difference.
I
I
I
know
that
we
provide
the
api
stability,
it's
okay
and
but
a
problem.
It's
a
quality
of
an
api,
so
yeah,
I'm.
I
Yeah,
I
agree
with
with
with
gab
with
the
the
idea
that
gabriel
say.
I
A
E
That
I
don't
think
that
it
should
be
renamed.
Personally,
I
don't
like.
I
think
this.
This
last
comment
here
of
saying
how
it's
being
napi
is
so
ingrained
in
in
in
the
infrastructure
everywhere
that
we
have
it.
I
don't
you
know
like
we
have
an
api
resource
domain
names.
We'd
have
to
change
any
of
all
of
those.
E
I
Node
underscore
arrest,
that
is
a
russ
wrapper,
for
example,
leon
that
is
a
rust
wrapper,
so
iot.js
yeah.
So
what
do
you
want
to
do
to
support
this
project?
No,
because
I
don't
know
if
we
need
to
have
the
hand
to
to
maybe.
F
Yeah,
so,
okay,
so
two
points
to
that.
This
is
this
is
all
true
in
terms
of
what
you
just
wrote
the
other
day
is
that
when
it
would
run
around
on
older
node
versions,
we
never
promised
backwards
compatibility
right
only
forward,
so
so
this
may
not
be
relevant
right.
F
At
least
right,
so
the
the
other,
the
other
concern
that
that
came
to
my
mind,
because
of
what
kevin
and
nicola
were
saying,
is
that
you
know
changing
the
api
would
invalidate
in
some
some
sense,
all
the
blog
posts
that
all
the
explainers
all
the
stuff
that
has
appeared
on
the
web.
You
know
you
know
guiding
people
in
the
way
they
use
an
api.
You
know,
because
now
all
the
things
that
they
mentioned
there,
you
know
they
would
go
to
the
node.js
documentation
for
further
for
further
depth,
and
they
would
not
find
it
anymore.
F
You
know-
or
at
least
they
would
they
would
find
methods
which
have
a
completely
different
name,
although
similar
to
what
they
saw
in
the
blog
post,
and
then
they
would
have
to
notice
that
it
says
in
brackets.
You
know
formerly
blah
blah
blah
right
so
so
it
would
definitely
make
it
more
difficult
to
follow.
Whatever
material
has
appeared,
sort
of
like
like
quote-unquote,
like
prose
material,
that
has
that
has
appeared
about
an
api.
F
A
A
I
F
Master
change
your
domain,
for
example,.
F
A
H
H
Counter
a
counter
example
to
this
is
can
also
be
pronounced
as
jip,
which
is,
can
also
be
construed
as
being
derogatory.
But
I
don't
see
any
efforts
there
to
rename.
H
F
F
Yeah
I
mean
to
me
to
me:
that's
the
first
thing
that
came
to
mind.
I
mean
that
is
the
only
permanent
artifact
that
that
that
that
sort
of
captures
this,
and
it
is
the
only
artifact
that
doesn't
have
to
dash
in
it
because
in
documentation,
it's
very
easy
to
add
the
dash
yeah.
A
A
F
A
F
A
I
think
I
I
you
know
it
was,
and
that
and
you
see
the
suggestions
are
like
sabi
and
c
api,
so
I
think
it
was
coming
from
the
we
use
n-api
in
all
the
docs
right.
I
and
I
wouldn't
be
surprised
if
the
symbol
part
you
know-
maybe
maybe
that
was
included,
but
it's
certainly
not
called
out
right.
F
Yeah,
honestly,
honestly,
it's
it's
the
symbols
that
are
most
conducive
to
pronouncing
it.
You
know
as
a
word,
rather
than
as
a
sequence
of
letters.
Yes,
so
in
in
a
way
the
symbols
are
the
ones
which
perpetuate
this
more
than
anything
more
than
any
other
part
of
the
project,
so
correct.
So
in
that
sense,
I
would
think
the
symbols
are
the
most
important
things
to
change,
but
on
the
other
hand,
they
are
also
the
the
deepest
and
and
and
hardest
to
change
so
yeah
anyway.
I
I
have
to
go
sorry.
It's.
A
A
You
know
we'll
we'll
need
to
discuss
we'll
continue.
The
discussion
in
the
next
meeting
right.
F
H
A
Yep,
okay
and
I
did
change
two
to
say
you
know
in
terms
of
renaming,
if
there
is
a
rename
we'd
prefer
that,
as
opposed
to
like
we
prefer
that
name:
yeah:
okay,
okay,
okay,
well
thanks
for
everybody's
everybody's
time,
we
did
have
some
have
some
other
things
that
I
typed
for
discussion,
but
I,
but
hopefully
I
forget
what
some
of
those
are,
but
we
can
look
at
them
next
time.