►
From YouTube: Node.js N-API Team meeting - 11 March 2019
Description
A
A
A
B
C
A
A
B
B
C
B
Yeah,
it's
it's
fairly
crazy,
like
we
have.
We
have
a
class
definition
in
Napa
dot
H,
which
includes
a
static
method
right.
This
is
for
for
async
worker
right
and
the
static
method
is
the
one
the
pointer
of
which
you
take
and
pass
into
an
API
so
that
you
know
on
work
complete.
It
calls
you
back
right
and
then,
based
on
the
error
status,
you
decide
whether
to
call
on
on
OK
or
on
error
of
the
instance
of
the
class
that
was
created
using
node
on
API
now,
since
you're
taking
the
pointer
of
dysfunction.
B
There
is
no
way
this
function
can
be
inline
right,
but
but
the
funny
thing
is
that
the
function
is
declared
as
an
inline
right
and
for
some
reason
on
Mac.
It
makes
a
difference
whether
that
inline
keyword
is
there
or
not,
because
if
the
inline
keyword
is
there
and
you
compile,
you
know,
you
include
a
NAPA
dot,
h
from
like
all
the
different
tests
right
like
so
so
it
gets
included
multiple
times.
B
So
so,
actually
you
get
like
15
of
these
symbols
that
that
get
defined
right,
but
they're
all
defined
with
this
inline
keyword
and
therefore
it
seems
to
be
okay
on
Mac.
However,
if
you
remove
the
inline
keyword,
then
all
of
a
sudden
it
fails
to
link
because
every
object
file
has
the
same
symbol
and
that's
a
linker
error
for
some
reason
on
Mac
and
well.
I
can
imagine
why?
B
Because
you
know
you
can
only
have
one
symbol
since
it's
going
to
be
global
for
some
strange
reason,
and
so
so
basically
you
have
to
keep
the
inline
keyword,
because
if
you
put
the
inline
keyword
in
there,
then
the
symbols
are
okay.
But
but
if
you
take
the
address,
you
get
the
same
address
for
the
symbol
across
shared
objects,
which
is
really
weird
right
and.
C
B
The
only
combination
that
will
work
on
Mac
is
keep
the
inline
keyword
so
that
so
that
you
avoid
link
linker
failure.
If
multiple
translation
units
include
the
same
function
and
you
have
to
have
this
visibility
hidden
so
that
so
that
in
the
end,
the
symbol
doesn't
get
exported,
because
only
then
can
you
have
two
different
addresses
for
two
different
shared
objects
which
have
the
same
symbol.
B
So
it's
it's
weird
like
just
weird,
and
so
that's
why
I
wanna
I
want
to
float
this
idea
of
just
adding
it
to
to
to
all
the
add-ons,
because
I
want
to
see
what
everybody
else
thinks
like
have
they
run
into
this
problem?
Okay
is
I'd
like
to
know
if
this
is
something
know
that
on
API
specific
or
not
right,.
A
B
B
It's
and
we,
okay
and
you
know
you
don't
need
like
I
said
you
don't
need,
know
that
on
API
right,
like
the
the
the
test,
the
test
inside
no
Gipp
doesn't
include
no
doubt
on
API.
It
includes
nan,
right
and-
and
that's
only
because
you
know
no
jib
may
need
to
support
more
things
than
note
itself.
I
suspect.
That's
why
they're
doing
things
in
that
so
there's
no,
no,
they
an
add-on
API
in
there,
but
this
the.
B
But
the
structure
of
the
of
the
of
the
class
is
the
same
as
it
is
in
know
that
on
API,
in
that
you
have
a
header
file
which
declares
a
class
and
then
afterwards
it
declares
this
function
as
inline.
So
that's
what
we
do
in
and
know
that
on
API,
and
so
that
structure
is
the
same
and
I,
and
basically
the
test
asserts
that
the
the
two
pointers
of
the
function,
whose
pointer
you
take
and
pass
into
into
the
the
engine,
is
not
the
same.
If
they
are
the
same,
the
test
fails
or
obviously
it.
C
B
B
A
B
Doing
anything
right,
yeah,
it's
not
specific
to
us
and
and
we'll
see
what
what
people
think
I
I'm,
especially
I'm,
especially
interested
in
in
what
Matteo
would
think
about
that.
Because
he's
he's
he's
like
a
avid
Mac
sort
of
user-
and
you
know
he's
also
he's
always.
He
also
supported
that
that
attempt
to
to
you
know,
run
an
API
on
versions
of
nodes
that
didn't
ship
an
API.
So
he
tested
that
on
his
Mac
and
they
worked
through
him.
B
B
B
A
A
B
How
that
came
about
but
yeah?
So
so
that's
basically
I'm
I'm
almost
ready
to
submit
the
PR,
but
the
thing
is
like
organizationally
I'm,
hoping
that
I'm,
not
you
know,
hitting
it
off
on
the
wrong
note,
because
you
know
people
who
look
at
no
chip
aren't
the
same
people
who
look
at
note
core,
I'm,
hoping
there's
enough
overlap
to.
A
E
A
F
B
B
A
A
A
A
A
Sorry,
just
trying
to
navigate
back
okay,
escalates
I,
know
Jim's
working
on
that,
but
any
particular
issues
that
people
have
raised-
I
went
through
and
I
did
create,
did
land
a
bunch
of
stuff
early
last
week
and
I
opened
an
issue
to
suggest
that
potentially
we
create
a
new
release.
I
think
407
is
the
one
that
you're
that
we
were
mentioning
about
on
Mac,
that
Gabriel's
working
on
that
was
the
only
one
that
came
to
mind
that
I
thought
we
might
want
to
wait
on
yeah.
A
G
B
B
A
A
A
D
E
A
A
A
A
D
D
D
A
D
D
D
A
Yeah
I
mean
I.
Think
that's
the
the
question.
Let
me
just
see
so
I
think,
let's
so,
let's
loop
back
here,
so
this
separate
additional
package
on
top
of
Noda
napi
I
think
that's
the
one,
the
other
one
that
you
mentioned
is
like.
We
probably
need
to
we've
had
a
few
cases
like
the
ones
you
just
pointed
out
where
you
know
it's
additional
functionality.
That
could
be
useful,
but
it
goes
beyond
just
wrapping.
What's
in
know
that
on
like
in
the
the
napi
itself,
yeah
I.
F
D
A
D
B
Yeah
I
think
I
think
it's
pretty
good,
but
if
we
need
to
go
with
a
whole
different
package
right,
like
you
know,
we
could
just.
We
could
just
add
another
header
file
right,
which
includes
nap
eh,
so
so
as
to
not
make
things
on
wieldy
right,
because
nappy
DRH
is
getting
pretty
big
right
and
that's
not
the
in
line
dot
H
is
getting
even
bigger
as
a
result.
B
So
so,
if
we
do,
if
we
do
add
stuff,
that
is
not
absolutely
fundamentally
wrapping
napi
yeah,
we
could
do
it
as
another
add-on,
since
it's
all
header
only
anyway
right,
it
would
mean
it
wouldn't
actually
mean
adding
any
more
complexity
to
anybody's
project
right
other
than
another
dependency.
So
they
already
need
a
tool
chain
if
they're
using
know
that
on
API.
B
Maybe
some
people
don't
want
to
maintain
like
the
the
low-level
stuff
they
just,
they
just
want
to
add
functionality
or
they
want
to
debug
the
existing
functionality,
that's
kind
of
things.
So
if
the
packages
diverge
in
terms
of
who's
who's,
who's,
looking
at
them
who's
maintaining
them,
then
it
makes
sense
to
have
two
packages.
But
if
it's
just
a
stand,
I
think
you
know.
For
now,
we
can
just
start
with
another
header
inside
this
package.
A
The
other,
like
you
know,
differences
between
having
multiple
packages
can
come
down
to
one
like.
If
you
are
all
in
one,
you
force
everybody
to
install
and
load
the
whole
thing.
If
you've
got
a
binary
size.
You
know
you
can
end
up
with
more
bloat
and
stuff
like
that
now,
because
it's
in
line
that
that
may
not
matter
as
much
well.
D
A
Where,
like
you,
might
want
to
have
a
separate
package
to
say
like
if
you
really
want
the
core
and
API,
which
is
just
what
wraps
or
no
doubt
on
API
that
wraps
node
in
API,
you
get
this
package.
But
if
you
want
the
extras,
you
know
you
only
get
them.
If
you
include
the
second
package,
the
other.
The
other
thing
is
that
we
could
say:
well,
we
actively
maintain
the
core
one
and
the
other
one
is
just
a
place
where
we'll
accept
contributions,
but
you
know
they're
not
as
much
of
a
foot.
D
D
B
A
F
A
Me
that
it's
that
you
know
we
have
like
this
promise
contribution
is
a
significant
amount
of
code.
So
you
know
if
it
adds
like
20%
to
our
code
base.
That
means
potentially
20%
more
to
maintain
and
it's
it's
not
exposing
any
new
functionality
that
an
API
provides
but
providing
a
you
know
a
new
way
to
access.
Some
of
that.
F
A
B
Mm-Hmm
yeah
so
yeah.
That's
that's!
That's!
Basically
what
it
is
like
it's
it's
a
it's,
basically
adding
adding
functionality
that
may
be
useful
and
and
it's
there
is
there's
good
reason
to
add
it,
but
but
perhaps
not
to
n
API.
It's
that's
or
no
that
on
API
itself.
That's
the
thing
so
make
it
available
sure.
But
but
you
know
don't
don't
expect,
don't
make
it
look
like
it's
it's
a
you
know.
You
cannot
use
note
that
on
API
without
it
you
know
that
that
kind
of
thing
so.
F
B
Yeah
yeah
yeah
for
sure
for
sure
it's
just
it's
just
some
people
don't
need
the
the
extra
package
they're
fine
with
with
just
I
mean:
let's
not
forget,
you
can
use
an
API
directly
right
and
now
and
now
that
we've
exposed
these
these
macros
for
for
throwing
errors,
which
is
one
of
the
most
important
things
that
know
that
on
API
does
on
top
of
an
API.
You
know
not
what
now
that
we've
exposed
these
macros
you
can.
A
It
might
kind
of
come
down
to
the
philosophy
of
you
know.
Do
we
want
to
have
no
doubt
on
API
strictly
be
a
wrapper,
and
then
you
know
you
could
even
think
of
instead
of
having
a
separate
module
where
we
take
contributions,
we
try
and
encourage
a
you
know
a
a
set
of
mod,
an
ecosystem
for
modules
built
on
top
of
note,
on
a
add
on
API,
to
add
in
various
things.
A
So,
like
you
know,
you
could
have
a
promises
package
and
you
could
have
something
else
and
you
could
have
a
whole
bunch
of
them
now.
I,
don't
know
if
it
needs
to
be
that
complicated,
but
it's
kind
of
figuring
out
what
we
think
the
the
philosophy
or
or
the
you
know.
The
flip
side
is,
you
could
just
say:
well,
let's
pack,
everything
in
there,
so
it's
just
always
there
and
it's
deciding
between
those
one.
F
F
E
So
I'm
kind
of
conflicted
here
and
I
mean
I,
see
why
this
is
a
hard
problem.
Right,
I,
think
you're,
right,
Michael,
I!
Think
if
we
go
down
the
route
of,
we
need
a
separate
package
here,
we're
probably
heading
down
the
path
of
there
should
be
an
ecosystem
of
modules
are
built.
On
top
of
add
on
API
I
mean
we've
always
said
that
I
don't
API
is
the
mystic
is
the
way
for
you
know
people
to
consume
an
API
for
in
a
convenient
manner.
E
A
B
A
B
Well,
I
mean
you
know:
people
are
always
free
to
start
their
own
package
right.
So
you
know
that
depends
on
an
API.
If
we
don't
accept
it
that
that
that
is
not
a
death
sentence
for
for
their
contribution
right,
they
can
still,
they
can
still
float
it
on
their
own
right,
but
then
really
have
to
accept
maintenance
of
it.
So
you
know
it
doesn't
prevent
anybody
from
contributing
right.
A
B
Oh
and
another
thing
about
the
separate
headers
is
that
you
know
they
basically
like
since
we're
talking
about
native
code.
Each
header
file
acts
like
its
own
package,
because
if
you
don't
include
the
header
file,
if
it's
sure
if
symbols
do
end
up
showing
up
because
of
when
they
include
that,
if
you
don't
perform,
the
include
the
symbols
will
not
show
up.
So
so
so
the.
A
B
C
B
A
C
B
C
B
We
have
the
other
contribution
here
for
the
for
the
async
queue
for
what
is
basically
an
async
queue.
You
know
we
could
have.
You
know
a
nappy
async,
you
dot,
H,
which
are
which
are
common
patterns
that
people
need
and
which
can
be
built
on
top
of
an
API
and
know
that
on
API
right.
So
so
then,
so
then,
if
we
went
with
a
separate
package,
I,
don't
think
I
mean
I,
don't
know
it.
B
B
Yeah
yeah
yeah
I.
Don't
think
this
will
lead
to
to
a
big
ecosystem.
You
know
and
and
yeah,
if
we,
if
we
wish
to.
If
we
wish
to
provide
different
guarantees
for
for
for
the
different
headers,
then
then
yeah
we
may
want
to
put
them
in
different
packages
so
but
yeah
but
they'd.
You
know
the
in
the
other
package
the
headers
can
proliferate.
If
people
want
to
sorry.
B
Call
it
like
note
that
on
API
I
know
they
add
on
API
extras
and
I
know
that
on
API
extras
is
a
package
that
lives
on
NPM
and
consists
of
a
bunch
of
header
files,
just
like
an
API
does,
or
just
like.
No
dad
on
API
does,
with
the
difference
being
that
that's
know
that
on
API
extras
depends
on,
though,
that
on
API
and
and
may
make
an
API
calls
directly
from
inside,
because
who.
B
E
B
B
Like
it
could
also
be
like
I
like
it
like
a
recruiting
thing
right,
because
because
it
should
be
easier
for
people
to
contribute
to
that,
we'll
still
keep
a
close
eye
on
it,
but
but
there
is
in
principle
nothing
preventing
people
from
from
adding
headers
to
it.
You
know,
each
of
which
provides
some
sort
of
convenience
that
that
is
being
that.
That
is
seeing
some
amount
of
usage.
You
know
which
we,
okay,
the
the
flipside
of
that
is,
you
know,
we'd
need
to.
B
C
B
C
B
A
And
that's:
what's
going
to
you
know
we
could
have
encouraged
a
structure
where
we
say
you
know.
If
you
want
to
spin
out
a
package,
here's
how
you
do
it
will
will
have
a
links
or
the
people.
You
know
off
of
the
main
repo,
so
people
can
easily
find
it
it's
sort
of
like
support
and
ecosystem
as
opposed
to
to
do
it.
B
B
Part
of
version
3
yep,
so
so
yeah,
those
those
things.
Those
things
are
definitely
on
us
to
settle,
but
that's
that's
rapper
stuff.
So
yes,
that's
definitely
that's
by
definition
on
us,
but
but
then,
but
then,
like
this,
this
async
you
and
and
async
promise.
Yeah
I
mean
these
things.
I
mean
I
I,
don't
know
how
much
to
what
extent
they
depend
on
on
a
sink
worker
and
well
I
know
I,
know
the
the
the
async.
B
You
definitely
depends
on
threats
a
function
but
I
believe
Phillip
did
the
calls
directly
to
an
API
if
I'm
not
mistaken,
so
so
you
know
he
doesn't
depend
on
the
other
or
it
doesn't
depend
on
the
other
PR
which
implements
the
threats
a
function
wrapper.
So
so
in
that
sense,
that
async
you
stuff
is
is
it
goes
directly
to
an
API,
but
can
be
done
with
know
that
on
API
as
well,
you
know,
especially
if
you,
if
we
land
thread
safe
function,
it's
just
a
different
way
of
using
thread
safe
function.
C
B
E
A
E
E
A
B
B
A
B
B
Okay,
but,
like
you
know
the:
if
we,
if
we
simply
don't,
have
the
manpower
to
to
maintain
another
module
with
the
infrastructure
that
we
have
right,
I
mean
maintain
it
in
in
the
way
people
expect
node
modules
to
be
maintained,
then
you
know
we
would
we
couldn't
we
can't
always
say:
okay,
well,
you
know,
npm
publish,
go
ahead.
You've
got
our
blessing,
we
can.
We
can
look
in
on
it
every
once
in
a
while,
but
please
maintain
it
bring.
B
B
So
so
like,
for
example,
these
two
PRS
right
for
for
async
promise
and
and
for
the
async
you
you
know,
can
we
can
we
ping
some
people
and
say
hey?
Would
it
be
something
you
might
use
you
know
because
we
have
we
have
the
person
who
submitted
it,
presumably
is
using
the
code
right,
but
is
there
anybody
else
independent
of
this
person
who
would
say
like?
Oh,
my
goodness,
I've
been
looking
for
this
on
my
life,
you
know,
and
and
can
you
guys
please
land
this
immediately?
E
A
The
other
interesting
sort
of
thing
is
like
yeah.
First,
this
thinks
through
versus
an
experimental
flow
like,
as
you
know,
one
the
flow
we
have
in
core
is
like
okay,
something
lines
in
core,
but
it's
experimental.
We
then
you
know,
have
it
baked
and
when
we're
convinced
it's
it's
good
it'll
go
out
the
api's.
In
this
case
you
could
have
the
flow,
be
yeah,
you
publish
a
module.
B
A
B
We
could
we
could
use
like
we
could
use
like
an
NPM
keyword
and
then
and
all
right.
You
know
we
would
only
have
one
link,
which
is
you
know,
search
search
by
NPM
keyword
and
and
and
it
would
give
a
list
of
modules
that
that
provide
extra
stuff.
On
top
of
know
that
on
API
and
we'd
we
could
document
that
this
be
the
process.
A
Because,
like
in
core
one
of
the
tests,
we
kind
of
sometimes
we
well,
sometimes
we
use
is
the
like
by
being
in
core.
Does
it
let
you
do
something
that
you
couldn't
do
otherwise
or
significantly
remove
maintenance?
Or
you
know,
and
it
seems
like
you
know,
the
wrappers
are
no
brainer
in
this
case
and
that
you
know
they've
got
they
should
be
in
because
they
basically
wrap
what
we're
trying
to
expose
any
sort
of
helper
functionality
you
could
see
is
like
well,
is
being
in
or
like
if
there
is
significant
advantage.
A
B
B
B
No,
no,
not
for
those
reasons
right
but
but
but
for
for
four
reasons
of
you
know
having
having
it
in
one
authoritative
repository
right,
I
mean
the
NPM
package
itself
is
starting
to
become
authoritative
when
it's
getting
so
many
downloads
right.
So
so
so
then
you
know
I
mean
if
people
may
not
want
to
contribute
it
upstream,
because
they're
fine
with
the
way
it
is
and
and
if
the
packages
gets
gets
actually
maintained
and
remains.
You
know
what
is
that
called
vibrant,
then
yeah.
You
know
it's
all
good,
but.
A
B
A
A
I
think
we've
really
got
to
that.
We're
talking
about
one
is
like
so
maybe
we're
sort
of
saying
either
we
are
more
liberal
and
we
pull
things
into
the
core
logic
core
core,
no
data
on
API,
or
we
encourage
ecosystem
modules
to
be
built
on
top
of
it
and
do
what
we
can
to
make
them
discoverable
and
so
forth,
but
sort
of
encourage
encourage
that
if
you
have
a
utility,
that's
not
a
wrapper
to
start
there
right
so.
A
A
A
E
I
think
the
next
steps
here
are.
We
should
probably
collaborate
on
a
document
expanding
on
the
two
options
that
we
have
enumerate
the
pros
and
cons
and
then
identify
the
I
don
API
users
who
we
want
to
involve
in
this
discussion,
circulate
the
doc
with
them
and
then
right
there,
maybe
next
week
or
the
week
after
to
this
call.
Oh.