►
From YouTube: Node.js N-API Team meeting - Oct 18 2018
Description
Google Form for Questions: https://docs.google.com/forms/d/e/1FAIpQLSea-eYU11_GYrJJCAXPX7hUM-CWsDPgTdFt0Xse64OzU0OHRA/viewform
A
So
welcome
to
the
no
GS
community,
an
API
team
meeting
for
October
18th
2018,
we're
gonna,
follow
our
standard
approach
of
going
through
our
current
milestone,
and
then
we
also
have
Gary
for
Microsoft
who's.
Gonna
talk
a
little
bit
about
one
of
his
use
cases
where
her
test
mentioned
that
you
know
napi
might
be
a
good
fit
and
hopefully
we'll
we'll
go
through
that
and
sort
of
see
that
I
guess
the
match,
mismatch
and
get
a
better
understanding
of
how
it
would
apply
in
that
case.
A
A
A
D
C
Think
you
know
more
pretty
much
all
except
like
one
of
these
modules
is
a
good
candidate
for
an
API
and
in
many
cases
you
know
they're
already
in
progress,
the
porch
and
imperium
progress.
So
I
don't
know
if
we
should
read
this
any
different
than
our
general
evangelism
strategy
for
any
API,
which
is
we
reach
out
to
module
authors
when
we
can-
and
you
know,
offer
ports
as
part
of
workshops
and
otherwise
just
be
available
for
people
who
need
help
with
porting
the
modules
right.
C
A
A
A
Yeah
no
problem
and
sorry
for
not
seeing
you
right
away.
It's
just
just
pointed
it
out
and
also
welcome
to
Shelley
I,
don't
know
if
everybody
well,
probably
not
everybody,
but
a
number
of
people
may
have
met
Shelley
at
the
collaborator
summits
but
she's
on
the
elektron
team
and
is
sort
of
joining
us
to
help
in
terms
of
helping
us
work
on
the
napi
story
and
in
an
electron
context.
A
So
so
for
your
benefit,
Shelley.
What
we
usually
do
is
we
go
through
our
milestone,
review
for
the
milestone
of
things,
we're
working
on
and
so
I'm
thinking
we'll
just
well
we'll
go
through
that
and
then
at
the
end
we
can
then
talk
a
little
bit
about.
You
know
electron
issues
and
you
know
potential
collaboration
going
forward
and
similarly
we
also
have
somebody
for
Microsoft.
That's
going
to
talk
a
little
bit
about
one
of
the
use
cases
that
that
they're
there
and
looking
at
does
that
make
sense.
A
A
B
A
E
A
A
F
A
A
So
SQL
ate
nappy
port
again
sorry,
but
Anita
still
pulled
heavily
from
school
I
think
she
had
three
midterms
last
week,
so
not
making
any
progress
on
that
last
update
was
just
we
have
to
sort
of
loop
back
because
there
was
some
directly
usage
of
UV.
We
need
to
take
out
so
she
said
she'd,
hopefully
get
to
that
or
early
next
week
and
then
I'll
meet
with
her
on
that
again
burning
down
the
list
of
issues
raised
by
module
owners
and
those
two
issues
in
the
node
repo
I.
A
If
there
aren't,
if
nobody
else
hasn't,
he
I,
don't
I,
don't
have
any
other
than
saying,
there's
been
a
few
which
are
good
to
see,
I'll,
probably
go
and
trial,
and
a
few
of
the
ones
in
no
dad.
No
dad
on
API.
For
you
know,
for
example,
things
like
adding
the
callback
scope
and
so
forth.
So
it's
good
to
see
that
and
some
other
additional
testing,
which
is
which
is
good
topics
for
na
VI
a
collaborator
summit.
This
I
think
we
can
just
close
since
we've
had
the
collaborator
summit,
except
that
I
know
Jim.
G
B
A
There
we
go
okay,
so
create
metrics
of
tested
methods.
I,
don't
think
we
have
anything
on
that
other
than
we
probably
have.
A
few
updates
in
terms
of
people
have
contributed
some
additional
testing,
so
we
probably
need
to
take
another
look
at
what's
missing
unless
so,
unless
anybody
else
has
something
to
add
on
that
I'd
say
you
know,
we
just
need
to
continue
to
push
on
looking
at
adding
those
stat
tests,
but
otherwise
let's
push
it
back
and
just
leave
it
on
the
agenda.
G
Status
quo
there
unfortunately
I'm
not
exactly
sure
how
to
proceed
with
with
that
PR,
because
it's
just
sitting
there
and
and
the
author
hasn't
has
an
answer.
So
I
don't
want
to
like
copy
copy
their
blurb
and
just
add
it
to
our
readme
and
then
mark
myself
as
author,
because
I
mean
I
could
refer
back
to
the
to
the
original
PR.
If
nothing
happens,
but
I'm,
not
a
hundred
percent
sure
how
to
handle
that.
You
know
how.
A
E
A
A
A
G
Oh
yeah
yeah
this
this
issue
I
think,
can
be
closed
because
we've
landed
everything.
We
were
gonna
land,
excellent,
okay,
so
so
the
so
that
sort
of
detailed
explanation
has
now
landed
I
guess
maybe
we
need
to
make
one
more
link
to
that
from
from
no
dad
on
API
I.
Think
Nicola.
Do
you
remember
where
we
were
gonna
link
from.
E
E
A
A
H
A
Well,
there
was
only
a
few
people,
so
I
think
it
was
an
opportunity
to
broaden
the
number
of
people
who
were
aware
of
what
it
was,
because
when
cuz,
when
we
asked
how
many
people
knew
what
it
was
already,
there
wasn't
a
huge
number
so
I
think.
But
my
perspective
is,
we
might
have
been
better
off
with
like
a
shorter,
tighter
intro
yeah
had
a
bit
more
time
for
discussion
and
like
tried
to
use
that
as
a
as
an
interactive
session.
Yeah
I
mean
we
didn't
we
didn't
plan
for
that.
E
G
Come
to
think
of
it,
I
actually
got
some
good
use
out
of
this
session,
because
I
was
able
to
I
was
able
to
help
Jim's
colleague
get
started,
so
it
was
like
a
very
very
specifically
I
know.
It
doesn't
scale
very
well,
especially
not
with
a
short
session,
but
but
it
was
kind
of
like
a
like
a
mini
code
and
learned
as
far
as
I
was
concerned,
right.
E
G
A
E
G
We
really
promote
the
collaborator
summit
session
right
because
that
that's
that's
one,
another
thing
that
we
can
do
or
sorry
yeah,
even
even
the
code
and
learn.
Maybe
although
that's
more
about
the
core
repo,
so
100%
sure,
but
basically,
which
we
should,
because
it,
the
the
I,
think
the
community
corner
session.
If
we
want
to
make
it
interactive,
then
there's
there's
not
much
opportunity
to
actually
dive
into
it,
because
it's
only
half
an
hour.
Yeah.
E
G
So
so
he's
kind
of
too
short,
it's
kind
of
too
short
for
a
code
and
learn,
but
but
it's
it's
it's
too
long
for
for
a
presentation,
given
that
we
want
to
make
it
interactive
right,
so
I'm
not
sure
how
how
quickly
we
can
dive
how
deeply
before
we
need
more
time.
You
know
so,
at
the
very
least
we
can,
we
can
use
it
sort
of
like
us
more
to
do
to
direct
people
to
the
rest
of
our
sessions,
but
that
of
course
assumes
that
it
comes
early
in
the
problem.
True,
so.
E
E
A
E
A
H
A
Didn't
talk
too
much
about
the
core
stuff.
One
thing
we
did
talk
about
was
embedding
which
shelli's
you
know
interested
in.
Also
in
just
there
was
you
know,
one
of
the
people
pointed
out
that
they've
had
some
challenges
using
any
peer
modules
with
electron,
so
I
think
on
the
embedding
front,
though,
the
the
conclusion
that
we
kind
of
came
to
I
think
maybe
I'm
not
sure
100%
agreement
was
that,
instead
of
going
directly
the
napi
api's,
we
should
iterate
a
bit
more
and
what
we
have
in
core.
B
A
There's
a
good
discussion
on
that
front.
There
was
a
discussion
a
bit
about
the
documentation,
so
Nicola
talked
to
us
about
some
proposals
on
documentation.
There
was
some
suggestion
that
you
know.
Maybe
we
should
be
trying
to
move
some
of
the
dock
back
into
the
header
files
and
then
extracting
that
for
our
external
dock.
So
that's
something
we
should
think
about.
A
Ali
is
Aaliyah's,
wants
to
sort
of
get
some
people
looking
at
wasum
add-ons
and
his
question
is
I.
Think
because
kind
of
question
is
is
like.
Is
this
group
interested
and
I
think
that
if
people
were
that
we
said,
you
know
sure,
come
and
come,
and
let's
talk
about
that
as
a
group
here,
that's
interest
in
add-ons
and
if
it
grows
to
something,
that's
big
enough
or
different
enough,
that
it
should
have
its
own
team,
then
sure,
but
for
now
maybe
it's
good
to
start.
Having
closing
those
discussions
here.
H
D
H
H
A
B
A
B
A
E
A
A
C
A
B
A
We
probably
need
like
2030
just
you
know:
okay,
Laura
Keene
and
that's
a
no
good
next
step.
Okay,
that's
something
we
can
hand
out.
So
all
right.
Okay,
like
Koteshwar,
coordinate
with
Jim
to
pass
on
the
list
and
then
Jim
you
can
bring
that
okay
sounds
great.
Now,
I'm,
just
gonna.
Look
at
the
milestone
overview,
because
I
wasn't
sure
we
had
everything
I
think
we
do
so.
We
still
need
to
get
back
on
some
focus
on
async
work
or
so
to
open
an
issue
for
that.
A
G
E
G
I
kind
of
went
through
them
and
and
and
some
of
them
I
don't
know
that,
there's
just
nothing
really
much.
We
can
do
there
like
open,
open
issue
that
just
kind
of
died
out,
I
I,
close
I
closed
a
bunch
of
them.
As
you
know,
it's
just
if
you
still
see
this
problem
that
it
is
an
open
kind
of
thing.
Okay,.
H
H
E
A
H
A
A
Yeah,
okay,
thank
you.
Okay,
so
I
think
we're
through
our
regular
agenda,
I
thought.
Maybe
next
we
could
sort
of
talk
a
little
bit
with
Shelley
about
electron
and
an
N
API
integration,
because
I
suspect
that
won't
take
too
too
long,
and
then
we
can
move
on
to
the
to
Gary's
use
case.
That
makes
sense.
D
There
aren't
too
many
things
that
are
broken
right
now
in
any
pair.
The
electron
specifically
there's
like
only
one
issue-
that's
really
opened
for
us
right
now,
just
like
there's
a
pairing,
some
weird
issues
with
call
thread-safe
function,
I,
don't
really
know.
What's
going
on
with
that,
I
wanted
to
dig
into
that
soon,
but
really
how
we'd
like
to
sort
of
help
and
contribute
upstream?
Is
we
just
like
to
help
and
I
by
just
working
on
a
yeah
just
busy
like
a
set
of
them
better
api's
for
an
API?
That
and
better?
G
A
The
other
thing
I
thought
we
might
chat
about.
Is
it's
good
to
get
you
connected
in?
So
if
we
have
people
reporting
issues
with
electron,
we
can
make
sure
we
loop
you
in
to
help
get
them
resolved.
The
other
thing
I
was
wondering
is
like.
Is
there
anything
we
can
do
on
the
testing
front
either
by
having
testing
like
in
your
environment
that
then
reports
issues
with
latest
versions
of
node?
You
know
any
PI
and
no
down
on
API.
So,
for
example,
today,
before
we
do
a
new
release,
we
have
a
set
of
runs.
D
That's
a
good
question:
I
can
look
into
that.
What
the
most
efficient
way
to
do
that
I
think
would
be.
I
would
probably
lean
towards
just
like
something
that,
like
you'd,
build
like
you
just
build
like
some
version
of
electron,
rather
than
kick
off
a
job
just
cuz.
We
don't
really
have
like
manual
CI,
which
is
sort
of
a
donor,
but
yeah
I
can
probably
think
about
the
little
more
and
then
get
back
to
user
and
also,
even
though
I
dumped
the
issue
into
chat.
D
D
G
D
G
D
G
G
D
That's
good
and
then
I
was
like
in
a
better
API
goes
or
like
anything
of
that
nature.
I,
don't
think
any
of
us
have
particularly
strong
opinions
about
what
it
looks
like
in
the
sense
that
sort
of
similar
to
what
I
said
in
the
breakout.
We
had
the
collaborate
or
something
it's
just
anything,
that's
better
right,
so
just
anything
that
we
can
use
this
sort
of
folks
formalizes
streamline
the
process
for
a
better.
It
would
be
great
so.
A
In
my
mind,
I
think
actually
coming
up
with
the
like
I
I'm
sort
of
the
same
with
you
I,
don't
have
any
specific
views
and
what
it
should
look
like.
But
if
we
came
if
we
could
help
build
the
use
cases
that
we
can
test
it
against,
that
would
be
useful.
So
you
know
people
propose
here's.
Here's
the
api's
it's
like
can
I
easily
use
that
in
this
particular
use
case.
A
That's
the
kind
of
thing
we're
like
your
experience
and
the
electron
view
would
definitely
help
would
be
good
to
help
inform
that
okay,
I
just
shared
these,
so
just
to
give
you
a
little
bit
of
an
insight
what
we
already
have
in
terms
of
testing.
So
when
you're
thinking
about
it,
we
have
some
tests
which
don't
work
so
consistently,
but
we
try
and
run
some
modules
the
base,
one
that
does
run
every
night
across
versions.
A
So
getting
something
like
that,
where
you
know
if
there
was
a
simple
set
of
steps
where
we
would
like
build
electron
and
then
build
know
that
on
API,
which
which
builds
a
module
and
then
uses
electron
to
run
the
test
versus
right
using
node.
If
that's
possible,
I
don't
know,
but
if
something
like
that
was
possible
would
be
nice
to
have
that
in
here
to.
A
D
A
Can
help
like
today
the
the
the
main
there's
a
couple
things
like
if
you
want
to
actually
jump
in
and
do
specific
things,
we're
were
focused,
as
we
mentioned,
on
building
out
test
coverage
for
no
doubt
on
API.
So
that's
an
area
where
you
know
and
probably
not
a
bad
way
to
you
know
it
to
you
have
to
build
it.
You
can
to
write
the
test
all
that
stuff,
so
that
there's
also
some
pieces
in
that
are
in
the
node
core.
A
In
terms
of
we
have
any
the
core
CN
api's,
but
we
don't
have
the
C++
wrapper
API.
So
that's
another
area
and
then
otherwise
is
just
the
general
like
people
have
reported
issues
in
the
repo.
So
looking
at
an
understanding
of
understanding
those
and
then
that
the
other
things
like
as
we
as
you
saw,
we
get
together
and
sort
of
talk
through
the
main
things
we're
trying
to
push
on
the
sort
of
meta
scale.
A
A
Okay,
so
the
next
thing
we
had
was
Gary's
here
and
I
think
a
lot
Gary
I'll,
let
you
frame
it
a
little
bit
more,
but
my
understanding
is,
you
know
you
have
a
use
case
where
any
PRI
might
be
the
right
thing
to
use
attached
mentioned
it
to
you.
So
you're
gonna
give
us
a
little
bit
of
a
context
on
what
you're
doing
and
we'll
go
from
there.
A
F
It's
similar
to
that
kind
of
mechanism,
and
we've
been
trying
to
host
babylon
GS
in
a
native
environment,
similar
to
hell,
node
hosts,
JavaScript
stuff
and
no
and
I've
been
looking
at
how
people
are
doing
cross-platform
across
different
JavaScript
engines.
How
to
sort
of
unify
that
and
I
found
a
chakra.
F
The
chakra
shim
was
like
hey,
it
looks
good
I
can
use
a
v8
API
and
then
talk
to
either
chakra
or
v8,
and
then
I
found
the
names
of
the
guys
that
working
on
it
and
I
pinged
them,
because
they're
all
some
a
couple,
microcell
guys
and
and
so
I
picked
them
in
here-
said:
hey,
maybe
issues
any
API
and
I'm
like
I,
never
heard
of
that.
So
let
me
look
at
that
and
effectively
I
looked
at
it.
The
only
thing
that's
sort
of
a
problem
for
me
is
I.
A
F
A
Okay,
so
you
took
like
NEPA
node
underscore
API
and
node
underscore
like
dot,
CC
and
dot
h
come
to
the
bunch
of
stuff
out
and
then
that's
what
you
built
into
your
project.
Correct,
okay,
yeah,
that's
an
interesting!
So
it
so.
What
you'd
really
like
is
you'd
like
two
files,
one
which
would
be
like
no
to
API,
I
I'm,
making
up
a
bad
name
but
like
node,
API,
underscore
es6
and
then
node
underscore
api
node
right
exact.
If
those
were
two
separate
files,
you'd
be
happy
right.
That's
great
I.
A
F
A
Think
that's
a
good
day.
You
forget
it's
work.
What
defines
be
enough
for
you
like?
If,
basically,
we
had
a
define
in
those
two
files
that
stripped
out
everything
that
wasn't
ESX
now
that
would
work
if
it
compiles
like
that
yeah.
Definitely
because
I'm
just
thinking
we,
we
would
have
difficulty
today
changing
the
dot
H
file,
because
that's
part
of
what
people
compile
against
right
the
CC
file.
We
might
be
able
to
split
into
two
things.
Why.
C
A
A
F
G
But
the
spec
is
the
same
in
all
cases
and
we've
we've
sort
of
come
up
with
an
API
that
everybody
seems
to
like
which
covers
the
spec,
not
so
much
the
implementation,
and
so
so
so
so
to
have
this
API,
easily
accessible
and
sort
of
you
know.
Detachable
is
I,
think
a
very
good
idea.
It's
it's
I
mean
we've
called
it
an
API
because
it
started
its
life
in
node
right,
but
but
a
lot
of
it
is
not
note
specific
at
all.
G
A
We
could
come
up
with,
like
you
know,
just
thinking
out
loud.
It
would
be
like
jeaious
underscore
API
yeah,
then
and
then,
like
I,
don't
know
if
there's
like
a
JSX,
node
extensions,
but
you
know
yeah
I,
think
something
that
says
here.
The
pieces
which
are
just
JavaScript
and
and
and
I
can
see
like
I,
don't
know
for
Jerry
script
or
whatever
that
might
even
have
made
your
life
a
life
a
little
bit
easier.
If
it
was
like
here's
the
things
you
would
implement
for
JavaScript,
but
aren't
note
specific
right,
yeah.
G
A
E
A
Idea
if
we
can
get
that
to
happen
so
yeah
yeah,
it's
it
sounds.
You
know
as
long
as
we
don't
change
the
the
shape
so
that
you
know
we
can't
make
a
breaking
change,
Ram,
but
otherwise
I
think
some
restructuring
and
it
makes
it
to
me
it
makes
total
sense
does
have
some
like
have
a
structure
which
is
like
your
the
things
that
are
pure
JavaScript
to
here,
the
things
that
are
node
and
and
I
guess.
Those
would
include,
like
our
extensions,
like
the
async
support
and
stuff
like
that,
but
yeah.
A
F
G
G
Well,
there's
there's
yes,
but
but
there's
also
some
some
things
that
all
engines
have
in
common
things
like
persistent
references
and
stuff
I
mean
that
that's
that's
not
part
of
the
s,
but
it
is.
It
is
an
indispensable
part
of
the
native
interface
that
that's
not
note
specific,
like
every
engine
has
to
have
references.
Otherwise
you
can't
really
use
it
because
you
have
to
store
everything
in
JavaScript,
yeah
and
I
be
yeah
and
things
like
external
external,
isn't
part
of
the
spec.
G
But
it's
pretty
much
part
of
the
spec
for
the
native
side,
like
again
indivisible,
right,
no
and
and
wrap
is
also
something
that
is
not
necessarily
specific,
because
you
know
attaching
or
or
sort
of
yeah
attaching
a
native
pointer
to
a
JavaScript
object
and
having
their
lifetimes
coincide.
That
is
also
you
know.
It
goes
beyond
a
single
engine
there
to
be
honest.
He
and
I
at
the
conference.
G
We
were
talking
about
about,
maybe
even
even
coming
up
with
with
like,
like
a
like,
a
like
a
body
that,
like
a
standards
body
that
that
maintains
an
API
like
that,
because
it's
it
seems
to
be
sort
of
heading
into
that
direction.
I
mean
we're
not
there
yet
I
mean
this
is
way
ahead,
but
basically
basically
have
a
standard
way
of
exposing
a
JavaScript
engine.
True
native
code
makes.
E
G
G
Yeah
yeah,
so
so
so
that
sort
of
shape
the
shape
of
an
API
seems
to
be
well
liked.
And
so
so
you
know
it
just
makes
sense
and
then
and
that
this
is
something,
and
you
know
if
we
do
get
if
we
do
get
buy-in
from
from
from
VN
maintain
errs
for
this,
that
we
get
the
additional
benefit
that
that
we
do
not
have
to
pay
as
much
of
a
performance
penalty
either,
because.
E
G
E
G
So
but
of
course
it's
it's
it's
a
huge
uphill
battle,
but
but
giving
them
giving
them
something
easy
to
do
to
implement
would
would
make
sense
and
and
and
separating
out
the
nodejs
parts
which,
which
VMs
are
almost
never
going
to
enjoy,
and
unless
we
go
through
tc39
you
know
you
would
probably
make
their
lives
easier,
yeah.
It
seems.
G
A
B
G
G
A
G
A
A
So,
like
you
know,
the
sorry
I
didn't
quite
catch
which
projects
you
want
to
use
this
in
it
was
for
it
was
for
Babylon
areas
right,
okay,
I
mean
again
just
you
know,
like
the
similar
question
that
I
had
for
Shelley
is.
It
would
be
good
to
have
some
sort
of
integrated
testing
so
as
we
land
changes
into
an
API
and
know
that
on
API,
we
know
whether
we're
breaking
anything
in
these
external
users
of
n
API,
and
we
can
at
least
that
very
least
pull
you
in
to
say
hey
by
the
way.
F
G
G
So
the
N
API
test,
suite
that
is
currently
a
part
of
node
I,
think
is
also
naturally
split
up
that
way,
because
because
we
we
tend
to,
we
tend
to
have
one
subdirectory
of
add-on,
add-ons
Nappi
error.
I
forget
what
we
called
it,
but
anyway
we
tend
to
have
one
subdirectory
test,
one
one
thing
yep,
and
so
so
the
note
specific
things
are
tested
in
node
specific
sub
directories,
so
so
I
think
we
have
a
natural
split
there.
Yeah.