►
From YouTube: 2020-03-19-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
B
Yeah
two
small
ones,
node
api
eight
has
landed
on
on
12.
There
hasn't
been
a
release
yet,
but
hopefully
it'll
be
in
12.22.0
if
all
goes
well
and
the
add-on
file
name
patch.
Well,
that
adds
the
add-on
file
name.
Retrieval
api
has
also
landed
on
12
and
and
it's
now
on
master,
it
has
been
for
a
while,
so
hopefully
that'll
make
it
into
a
release
soon.
A
Okay,
so
let's
move
on,
I
will
share
my
screen
and
share
the
milestone
11..
So
the
first
one
is
our
effort
to
rename
to
node
api.
I
know
that
jim
did
some
work
and
he
messaged
me
that
there
is
a
pr
here
find
that
node
add-on.
A
Which
continues
to
do
some
updates
there,
so
if
people
have
a
chance
to
take
a
look
and
review
that
there's
a
good
number
of
changes,
that
would
be
great,
we'll
get
that
landed.
C
A
Okay,
I
don't
know,
do
we
need
to
talk
about
like
how
to
get
started
on
that
or
what
the
next
steps
are.
C
B
Yeah
in
core
in
core,
I
think
we're
we're
good
to
go.
There
is
one
thing
that
I
would
like
to
do,
which
is
to
backport
the
the
test
changes
to
to
to
14,
because
you
know
otherwise
we're
we're
buying
ourselves
a
free,
a
free
ride
to
having
all
an
api
prs,
be
manual
back
ports.
If
I
don't
make
that
change,
because
right.
D
B
And
it's
even
more
subtle
than
you
might
think,
because
it
actually
everything
still
builds,
but
then,
but
then
you
have
like
unresolved
symbols
because
like
node,
api
call
is
not
a
function
anywhere
and
we
don't
have
like
we.
It
doesn't
error
out
on
unresolved
symbols.
It
just
warns
about
unresolved
symbols.
B
C
Okay,
in
the
the
documentation
of
for
15
node
15
is
already
with
node,
so
yeah.
I
think
that
yeah
we
can
think
to
what
to
write
on
these.
This
blog
post
so
right.
C
And
in
the
blog
post,
so
we
can
say:
okay
in
the
next
version
of
of
14,
and
I
don't
know
yeah
for
sure
the
the
we
will
have
the
same
change.
No.
D
B
For
master
and
14,
although
yeah
14
being
the
the
leading
the
leading
lts
for
now,
it
might
actually
apply
so
so
yeah.
I
don't
know
this.
This
back
porting
business
is,
is
always
like
a
you
know:
it's
it's
not
stable,
so
to
speak
because
it
depends
on
if
the
pr
clashes
or
not.
C
So,
for
now
we
can
say:
okay
from
node
15.,
so
we
we,
we
changed
the
the
name,
but
essentially
it's
the
same
same
api.
A
A
I
guess
it
should
really
references
just
I
guess
the
test.
It
was
the
test
folder
that
we
changed.
Was
it
yep
test
yeah.
B
D
A
B
A
A
A
A
Sort
of
that's
kind
of
the
top
level,
not
not
the
right
words,
but
I
don't
know
if
there's
other
things
we
should
add
into
this.
A
C
A
A
Okay,
so
I
think
this
one
I'm
wondering,
should
I
take
it
off
the
once
we
have
prs,
I'm
thinking
we
can
take
him
off
the
stale
list.
Does
that
make
sense.
C
A
Context-
and
I
don't
think
I
don't
if
anybody
sees
any
issues
that
go
stale-
that
they
think
we
should
talk
about-
just
add
them
in
here.
I
think
a
couple
I've
seen
gone
stale
recently,
but
they
kind
of
look
like
things
where
you
know
conversation
is
tailed
out
and
didn't
need
to
be
didn't.
Need
us
to
do
anything.
A
A
A
So
see
express
this
down
a
little
bit
too.
I
don't
know
anyway.
I
don't
know
we're
nothing.
Significant
is
going
on
on
that
front,
oops,
okay!
So,
let's
move
on
to
the
next
issue.
A
So
looking
at
the
list
of
issues
are
there
any
first
before
we
sort
of
look
at
these
lists?
Are
there
any
ones
that
people
want
to
call
out?
We
should
talk
about.
A
I
saw
gabriel
was
it
that
the
the
one
on
node
that
had
to
do
with
finalization
landed
just
recently.
B
Yeah
on
master
and-
and
I
I
backported
it
to
14,
which
is
really
where
it's
needed
and
so.
D
B
I'm
just
like
yeah,
I
don't
I'm
just
waiting
on
on
the
the
14
ones,
because
there
were
like
there
was
a
recent
proposal
for
a
12
and
so
that
got
that
pulled
in
all
the
all
the
12
backboards
that
we
had.
But
for
14
we
still
have.
B
A
B
It's
37
802
is
the
is.
B
Over
but
oh,
oh,
oh
and
then
you
ran
into
the
node
node
api
call
thing
for
the
tests.
Unless
you
didn't
run
the
test.
A
B
Yeah,
there's
there's
no,
it's
just
everything
in
the
tests.
That's
know.
The
api
call
needs
to
be
changed
back
to
an
api
call.
That's
all
right.
Okay,
yeah!
So
it
doesn't
like
the
the
change
to
to
the
actual
core
is
exactly
the
same.
Like
forbid.
A
A
B
Yeah,
it's
probably
happening
on
12,
but
I'm
not
sure
that
that
12
is
sufficiently
similar
so
that
you
know
we
don't
need
to
do
another
intellectual
exercise
rather
than
just
the
porting
exercise.
Okay,
well
yeah!
I
I
can
check.
I
can
certainly
check
to
see
what.
A
B
You
know
I
let
me
just
check
out
12,
because
I
we
may
not
even
have
like
the
environment
tear
down
reference
cleanup
in
12
at
all
kind
of
what
I
was
thinking
like.
I
didn't
know
whether
it
made
it
back
yeah.
Let
me
get
check
out
v12
point
x,
staging
and
and
edit
js
native
api
v,
a
dot
cc.
B
Actually,
that's
not
the
one
I
want
to
edit.
I
want
to
edit
the
h.
Oh,
we
do
have
ref
tracker
well
well,
well,
well,
well,
well,
all
the
way
back
yeah!
We
have
finalized
all
in
12.
So
so
then
this
may
be
worth
back
porting
further
still
before
12
sort
of
petrifies
into
a
maintenance
version.
A
A
C
A
B
B
B
A
B
Yeah,
this
is
it's
kind
of
a
proposal
for
how
we
might
handle
the
the
distinction
between,
like
an
exception
throne,
and
the
inability
to
execute
javascript
in
a
similar.
D
B
Way,
yeah,
it's
a
bit,
it's
a
bit
roundabout,
but
it
has
to
be
if
it's
going
to
be
somewhere
minor.
A
Do
give
me
different,
you
know,
responses
right.
B
Yeah:
okay,
yes,
yes,
you're
right,
you're
right!
So
so,
instead
of
instead
of
like
instead
of
is
exception
pending,
you
would
say
like
was
javascript
to,
or
was
the
exception
because
of
in
the
ability
to
execute
javascript
only
in
a
more
succinct
api
name,
yeah.
Okay,.
A
A
B
B
A
D
I'm
thinking
about
that,
and
it's
similar
to
the
case
that
causes
a
crash
on
the
finalizer
when
tearing
down
yeah
so
in.
Currently
the
developers
have
to
determine
that
if
the
finalizer
can
be
run
during
teardown,
since
we
cannot
execute
javascript
during
codon
right
so,
but
the
partner
finalizers
in
node
api.
D
They
do
accept
a
node
emv,
not
emv
as
a
argument.
So
that
might
be
indicating
that
we
can
safely
calling
javascript
during
during
the
finalization
and.
C
D
If
we
can
like
say,
promote
these
finalizers
before
the
environment
in
being
terran
or
the
developer
have
to
distinguish
the
these
situations
in
their
code.
Let's
say
there
might
be
we
the
time
we
might
be
able
to
call
javascript,
but
there
are
time
we
cannot
execute
the
javascript
in
the
same
place
right.
B
Yeah
yeah,
one
thing
we
might
be
able
to
do
is
is
maybe
maybe
move
this
move
this
up
in
the
environment,
tear
down
sequence
so
so
yeah
make
it
like
the
first
step
of
environment.
Tear
down
is
to
is
to
get
rid
of
the
the
node
api
references
and
while,
while
you
can
still
execute
javascript
yeah.
D
B
Thing
is
the
thing:
is
the
environment
is
in
the
finalizer,
because
there
are
still
some
things
you
can
do
it's
just
you
know
you
cannot
set
properties
on
objects
or
or
or
delete
properties
from
objects.
That
kind
of
thing
you
cannot
do,
because
that
requires
javascript
execution,
but
there
are
still
many
apis.
You
can
use
so
so.
On
the
other
hand,
we
could
just
restrict
ourselves
to
documenting
and
and
pointing
out
that
inside
a
finalizer
you
may
or
may
not
be
able
to
execute
javascript.
D
But
that
level
be
a
option,
but
since
the
the
latest
ecmascript
introduced
a
reference
like
a
weak
reference
in
javascript
natively,
so
there
might
be
a
intuition
that
in
node
and
node
api,
these
finalizers
can
also
execute
arbitrary,
javascript
javascript
code
right.
So
I
was
thinking
that
if
the
we,
if
we
are
making
the
finalizers
and
okay
unable
to
go
into,
javascript,
will
be
not
intuitive
to
developers.
B
B
Differences
are
are
unavoidable.
However,
I
do
believe
that
it's
worth
exploring
whether
it
is
possible
to
set
it
up
in
such
a
way
that
you
can
execute
arbitrary
javascript
by
changing
the
environment,
tear
down
sequence.
So
yes,
let's
have
a
look,
but
if
not,
then
we
have
no
choice
but
to
say
that
yes,
yes,
I
know
you
can
do
it
in
javascript,
but
this
isn't
javascript
right.
This
is
native.
So
you
know
the
engine
behaves
differently
on
the
native
side
than
on
the
javascript
side.
B
Yeah
yeah,
but
I
mean
if,
if
we
move
things
up,
I
mean
you
know,
there
is
a
point
during
threat
termination
where
it
is
determined
that
oh,
this
is
threat
termination.
Therefore,
I
should
tell
the
engine
to
you
know:
stop
executing
javascript.
Now
the
question
is:
is
it
is?
Is
it
possible
to
to
hook
into
that
decision
and
precede
that
decision
with
the
cleanup
of
all
the
all
the
node
api
references?
That's
what
we
need
to
find
out.
A
Like
for
regular
like
when
a
thread
finishes
normally,
yes,
I'm
thinking
of,
like
the
actual
there's,
a
call
on
a
worker
thread
to
say,
stop
like
terminate
yeah.
I
can
that
can
happen
in
the
middle
of
you
running
any
code,
whereas
the
regular,
the
regular
thread
termination
should
be,
you
know,
should
be
easier
to
handle.
A
B
A
Yeah
because
yeah
we'd
want
to
document
like
if
we
could
only
do
one,
it
might
still
be
worthwhile
because
you
know
if
you
can
do
an
easier,
better
cleanup
most
of
the
time
that
would
make
sense,
yeah,
yeah
but
documenting
it
either
way
to
say
but
be
forewarned.
There's
this
case.
Where,
like
you
know,
you
may
want
to
be
able
to
say
if
you
get
a
you
know,
maybe
at
the
you
know,
if
you
get
this,
I'm
I
terminating
error
code.
You
should
basically
just
bail
completely
because
you
can
now
no
longer
do
any
javascript.
B
Yeah
yeah
yeah
definitely
yeah,
so
so,
basically
identifying
the
precise
conditions
under
which
javascript
can
and
cannot
be,
executing
and
pushing
for
like
maximizing
the
conditions
under
which
it
can
be
is
seems
to
be
like
the
the
sort
of
the
the
research
we
have
to
do.
A
B
Well
and
anna
correctly
pointed
out
that
that
during
a
gc
pass,
things
are
pretty
unstable
as
they
are,
and
so
so
that's
why
she
added
set
immediate
to
the
buffer
finalizer
right,
which
is
causing
that
issue.
Where
you
you,
you
try
to
just
create
buffers
in
like
in
like
a
busy
loop
and
they
never
go
out
of
scope
so
to
speak
at
least
not
on
the
native
side.
B
So
there
is
that
issue,
and
I
don't
believe
we've
ever
run
the
experiment
with
with
with
regular
references
that
are
not
to
buffers
or
array
buffers
as
to
whether
you
know
those
finalizers
get
called
because,
unlike
buffer
and
array
buffer
finalizers
regular
reference
finalizers
are
called
using,
like
the
the
second
pass
callback
right.
A
A
B
A
I
think
that's
kind
of
a
different,
like
that's
kind
of
a
different
issue,
whether
versus
whether
you
can
call
javascript
or
not,
which
is
pretty
fundamental
like
if
I
write
a
finalizer
and
it's
trying
to
free
up
some
stuff,
yeah
yeah
yeah.
And
it's
going
to
error
out.
Sometimes
like
that's
the
thing
that
we
would
want
to
document
versus.
Like.
B
You
know
it
sounds
like
it
sounds
like
that.
We
will
be
unable
to
completely
avoid
the
inability
to
call
javascript
from
a
finalizer
right.
There
will
always
be
a
case.
It
sounds
like
where
we
will
not
be
able
to
call
into
javascript,
and
so
I
think
it
might
be
worth
implementing
the
bit
where
we
handle
that
and
or
we
provide
users
with
the
means
to
handle
that
by
way
of
this
issue
on
the
screen
and
then
and
then
we
can
maximize
the
cases
where
you
can
execute
javascript.
A
A
Javascript
and
here's
how
you
can
you
know
you
can
you
can
opt
into
this
to
get
better
return
codes
and
if
you
get
this
return
code,
that's
what
it
means.
So
at
that
point,
do
it
without.
A
A
Okay,
so
sorry,
I'm
just
trying
to
get
back
to
do.
I
have
one
here:
okay.
Well,
no,
maybe
I
shouldn't
have
closed
that
issues
here.
Okay,
here!
No
here
we
go
right.
I
guess
I
don't
see
anything
else
too
new
there
to
discuss.
Let's
look
at
node
add-on.
A
Api,
so
here
I
see
jack,
you've
opened
a
few
issues
for
test
coverage
for
different
objects
and
stuff
yeah,
and
also
added,
like
some
tests
for
these
missing
yeah
excellent.
So
do
you
have
questions
for
us
or
anything?
We
want
to
sort
of
dive
into
there
or
things
just
you're
working
away,
and
things
are
good.
Yeah
things
are
good.
D
A
Okay,
let's
see
what
else
we
got.
A
Here
this
one,
I
think
I
left
it
open
only
because.
A
A
We
talked
a
bit
about
last
time.
I
think
kevin
wanted
to
take
a
closer
look,
but
okay,
that
the
one
thing
I
did
I
I
will
mention
is
I
actually
came
across
what
could
be
a
real
life
situation.
B
Of
it's
throwing
something
other
than
a
an
error
object.
Is
that
what
this
is
well.
A
B
A
Okay
and
it's
sort
of
like
so
I
don't
know
it
could
be
like
this-
is
the
this
says?
Oh,
this
is
why
we
want
to
have
the
fatal
error,
because
it
shows
that
somebody
made
a
mistake,
or
it
could
be
the
case
that
it's
like
hey
there
there
you
know
there
couldn't
have
been
anything
they
could
do
so
it
would
have
been
better
to
say,
yeah,
we're
shutting
down.
B
Let's
just
yeah
yeah
yeah
yeah
this
yeah.
It
would
be
good
to
know
what
what
the
non
an
api
okay
status
call
was,
because
I
have
a
strong
suspicion.
It
was
an
api
pending
exception.
A
Right
there
was
already
exactly
yeah,
so
it's
kind
of
like
figuring
that
out
to
say,
but
I
I
came
across
this
and
I
think
it's
like
at
least
another
real
world.
It's
a
real
world
thing
that
might
help
us
inform
what
we
want
to
decide
to
do.
Yeah
it's
kind
of
like
yeah.
There
was
nothing
they
could
do
or
well
yeah
it's,
and
this
is
the
one
I'm
also
going
to
check
to
see.
If
that
other
fix
fixes,
it.
A
A
A
B
A
But
worth
testing
so
yeah
good
good,
that's
the
only
one
I
kind
of
had
on
my
list.
I
don't
know
if
anybody
wants
to
talk
about
any
of
the
other,
any
other
ones.
D
So
this
pr
is
pending
to
fix
the
to
ensure
that
we
fix
and.