►
From YouTube: 2021-11-18- Next 10 mini summit - types and exes
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
We
have
the
agenda,
which
is
tagged
in
in
the
issue
as
well
at
which
was
issue
number
99
in
the
next
10
repo.
We
also
have
a
minute
stock,
which
is
in
the
issue
I
posted
this.
So
if
people
people
want
to
follow
on
there,
we
have
two
topics.
So
we've
got
the
schedule,
which
is
suitable
types
for
end
users
and
the
second
topic,
which
is
single
executable
applications.
A
I
think
I
thought
it
would
make
sense
for
us
all
to
just
do
a
mini
round
table
just
to
introduce
who
we
are
and
what
our
interest
is,
so
that
we
we
know
who
who
everybody
is,
and
then
we
can
dive
into
that.
So
maybe,
if
it's
okay
I'll
call
on
people
in
the
order
that
I
see
them
in
my
screen
and
we
can
go
with
that.
Does
that
sound
good
to
everybody?.
A
B
There
we
go
hey
everybody.
I
work
on
the
typescript
team,
so
I
work
at
microsoft.
I'm
also
sort
of
one
of
the
people.
That's
done
a
lot
of
the
process,
work
on
definitely
typed
that
has
sort
of
allowed
it
to
scale
to
the
amount
of
contributors
that
it
has.
I
obviously
care
about
what
the
types
for
node
are,
because
we
use
node
everywhere
and
have
a
good
sense
of
like
kind
of
what
the
typescript
team
wants
out
of
node
types
as
well
as
what
users
want,
though
I
don't
maintain
the
node
types.
D
Hey
tony
styron
I
developed
for
advocate
at
microsoft.
I
do
a
bunch
of
things
on
the
project.
I've
been
trying
to
do
a
lot
of
docs
improvements
recently
or
as
many
as
I
can
yeah.
I
I'm
interested
in
both
types.
I
I
have
an
ideal
world
of
of
how
that
gets,
done
and
understanding.
That's,
probably
not
the
reality
of
how
it
happens,
but
yeah.
So
I
I'm
interested
in
types
I'm
also
very
interested
in
the
single
binary.
A
F
Yeah
I
often
times
like
at
the
coffee
shop
they'll,
ask
my
name
and
I'll
say
joe
and
they'll
say:
jill
yeah,
I'm
joseppi.
I
am
opentech
program
director
at
ibm
and
have
been
in
the
node
space
for
a
while
and
currently
the
one
of
the
two
representatives
at
the
open
js
foundation,
which
is
where
I
spent
some
of
my
time
as
well,
yeah
and
just
curious
about
both
these
topics.
G
H
I
J
J
K
A
L
M
O
Q
A
R
A
If
not
I'll
go
last,
I'm
michael
dawson
member
of
the
tse
as
well,
and
helping
to
to
sort
of
guy,
basically
working
with
the
the
next
10
team,
to
look
at
what's
important
for
the
future
of
node.js.
You
know:
we've
come
up
with
a
number
of
topics
which
is
the
you
know.
Two
of
the
topics
are
the
the
subject
of
the
mini
summit
today
and
so
yeah.
A
So
I'm
I'm
involved
in
the
node
project
in
a
bunch
of
different
places,
also
work
at
red
hat
along
with
a
few
of
the
other
people
who
are
here
as
well.
So
thanks
for
everybody
for
coming
and
for
those
introductions,
I
think
at
this
point
we
can
dive
into
the
the
particular
sections
we
have
breaks
set
for
you
know
between
the
90
minute
sessions.
P
A
Figure
out
where
we
go
from
there,
so
maybe
I'll
just
frame,
you
know
what
what
I
thought
we'd
cover
in
the
suitable
type
section
and
people.
It
would
be
great
if
other
people
would
fill
in
round
that
out.
You
know
make
sure
we
don't
have
things
you
know.
From
my
perspective,
you
know,
I
think,
from
our
our
discussions.
The
next
10
there's
sort
of
general
consensus.
That
types
are
important,
not
all
developers
like
them.
Of
course,
some
developers
don't
want
to
use
type.
A
Some
do
but
there's
a
big
enough
portion
that
it's
important
thing
that
we
want
to
make
sure
no
developers
can
effectively
use
types
and
the
my
personal
goal
out
of
this
is
that
we
as
a
project
understand
you
know
what,
how
good
a
shape
are.
We
in
terms
of
types
for
node.js
is
everything
going
perfectly.
We've
got
a
great
process.
A
You
know
we
don't
need
to
do
anything
at
all
because
everything's
just
ticking
along
and
we
get
the
types
that
we
need,
or
are
there
some
things
that,
like
within
the
project
that
we
could
consider
doing,
that
would
help
make
that
process
better,
and
so
it's
it's.
It's
to
come
out
of
that
with
the
do.
We
have
some
action
items
or
can
we
confidently
say
that
nope
on
this
particular
topic,
which
we've
identified
as
important
we're
good
any
do
people
have
thoughts
additions
to
that?
B
But
I
think
there
is
some
arguments
that
there
are.
There
are
ways
in
which
maybe
automation
can
be
that
can
improve
the
way
that,
like
the
types
that
are
generated
and
put
into
dt,
could
be
improved.
I
think
simon
has
something
that
pulls
out
that
actually
extracts
documentation
from
node.
I've
seen
him
make
prs
that
look
automated
in
some
sense,
but
I'm
not
quite
sure
what
the
process
behind
that
is.
S
Yeah
I
can
give
some
info
on
that
effectively
the
tool
I
wrote
tries
to
match
our
existing
types
to
the
json
documentation
that
is
generated
and
hosted
on
the
official,
node.js
website
and
kind
of
tries
to
pull
them
in,
because
our
the
primary
goal
behind
this
was
to
kind
of
improve
the
user
experience
there
and
avoid
them
having
to
you
know,
switch
between
the
official
node
docs
and
the
typescript
docs,
because
we
already
had
some
documentation
pulled
in
there.
That
includes
you,
know
the
adsense
tag
versions
and
so
on.
S
S
B
An
interesting
sort
of
analog
analogy
here:
it
could
be
to
how
the
types
work
for
the
the
the
web.
You
know
the
dom
types
effectively
what
we
have
over.
There
is,
first
of
all,
you
know
webs
all
have
specifications
and
they
and
we
work
with
those
specifications
and
sort
of
auto,
generate
types
from
that.
B
But
after
that
we
sort
of
reach
into
the
mozilla
sort
of
documentation
repos,
and
they
have
these
big
json
dumps
of
all
the
different
bits
of
documentation,
and
we
just
sort
of
extract
out
the
useful
bits
of
documentation
that
you
would
want
in
line
and
then
effectively
allow
the
the
the
code
gen
sort
of
come
from
a
standardized
system.
And
then
we
extract
extra
documentation
from
like
known
good
documentation,
sources
and
append
those
to
the
types.
D
D
Yeah
yeah,
so
electron
has
a
tool
called
box
parser
this
tool
here
I'll
put
a
link-
it's
not
particularly
descriptive
in
the
readme,
but
this
tool
parses
their
documentation.
So
they
have
a
markdown
documentation
structure.
That's
relatively
structured
after
nodes
nodes,
documentation
structure,
they
parse
out
the
dark,
the
documentation
and
basically
convert
mark
down
into
an
ast
that
represents
like
a
markdown
asc,
that
represents
the
api
surface
area
and
then
they
convert.
D
I
don't
know
if
we
are
too
far
off
with
that
or
not
and
and
frankly
I
I've
spent
some
time
working
on
getting
doxperson
to
work
with
node.
It
doesn't
right
now
so
that
it's
not
something
that
we
could
just
kind
of
use
the
surface.
The
api
surface
area
between,
though
and
electron
are
very
different.
Node
has
a
lot
more
legacy.
Grossness
than
electron
does
they've
been
very
strict
with
their
api,
so
yeah.
B
Yeah
one
of
the
things
that's
a
little
bit
of
attention
is
that
you
know
the
the
deeper
that
the
integration
lies
on
your
side
in
the
sense
of
node
side
versus
dt
side
is
that
you
have
to
like
the
maintainers,
have
to
know
more
about
sort
of
the
in
the
internal
z,
library,
style,
writing
of
typescript
right
like
when
people
start
adopting
typescript
the
first
things
they
do.
Is
they
they
write
a
few
apps
and
they
put
types
in
a
few
different
places,
and
that's
usually
enough.
B
You
get
a
bit
bigger
and
a
bit
bigger
and
then
suddenly,
you
start
realizing,
there's
always
advanced
syntax
that
you've
never
even
heard
of,
like
you
know,
template
literal
syntax
that
goes
across
maps
types
that
do
conditionals.
All
this
stuff
exists
basically,
but
definitely
typed
for
people
trying
to
type
really
pretty
complicated
to
type
javascript,
because
javascript
is
so
dynamic
and
ideally
node
contributors.
B
So
that's
why
I
think
a
good,
a
good
match
is
that,
like
leaving
dt
to
handle
a
lot
of
the
sort
of
complicated
type-c
stuff,
but
making
it
easy
for
the
complicated
types
of
stuff
on
dt
to
be
able
to
get
like
to
know
that
they're
missing
a
function
for
a
particular
version
of
node
to
be
able
to
extract
useful,
markdown
and
metadata.
And
if
you
have
stuff
like
examples
of
the
usage
of
that
api
being
able
to
extract
that
out
of
that
metadata
as
well.
That
just
makes
really
great
doc
comments.
D
A
A
In
a
few
words,
what
that
looks
like
which
we've
talked
about
a
little
bit
and
then
go
into
like
how
would
we
get
there
right,
because
I
think
for
me
it's
useful
just
to
know
where
would
we
like
to
be
even
if
it's
impossible
right
but
like
that,
gives
you
a
good
sort
of
frame
of
what
what
everybody
thinks
would
be
a
good
thing
to
work
towards,
and
then
we
could
figure
out.
Does
that
make
sense
to
people?
A
A
S
S
There
would
need
to
be
some
improvements
made
primarily
around
the
accuracy
of
the
documentation,
like
the
the
precision
of
the
documentation,
such
as
specific
overloads,
return,
types,
generics
and
so
on
and
yeah,
so
this
is
kind
of
that.
So
I
I
think
the
overall
mechanism
that
already
exists
is
pretty
good
because
all
of
these
documentation,
all
of
these
json
blobs,
are
downloadable
directly
by
everyone
and
can
easily
be
integrated
in
our
tooling,
which
is
what
I
did.
S
A
S
A
A
D
D
A
A
A
S
Yeah
so
effectively
the
the
tool
tries
to
match
the
tree
like
the
documentation,
trees
together,
like
of
what
we
already
have
in
typescript
as
in
the
individual
module
declarations,
globals
libraries
classes-
and
you
know
everything
that
is
nested
kind
of
like
tries
to
match
these
trees
together
and
then
pulls
out
the
information
out
of
the
out
of
the
node.js
documentation,
and
by
doing
that,
it
compares
the
trees
like
what
entries
are
missing
on
either
side.
So,
for
example,
do
we
have
methods
documented
that
are
not
in
the
official
node.js
docs?
S
One
of
my
versions
also
had
some
types
checking
where
it
was
checking
the
arguments
against
each
other
was
checking
that
the
arguments
have
the
same
name
etc.
So
not
like
super
deep
stuff,
and
it
was
not
necessarily
generating
individual
docs.
Based
on
that,
it
was
more
like
outputting
warnings
to
the
user
yeah,
so
that's
kind
of
what
that
does.
A
S
A
E
E
A
S
B
B
S
A
B
S
Sorry
go
ahead,
yeah
so
so
generally
at
least
the
way
I
have
approached
it
and
some
others
have
approached
it.
The
general
contributions
to
node.js
have
always
been
version
based,
like
node.js
released,
a
new
version
say
I
don't
know
16.9,
because
I
haven't
gotten
around
to
do
17
and
I
usually
look
at
all
of
the
changes
that
were
included
in
that
release
and
try
to
apply
them.
This
is
a
fairly
manual
process,
though.
S
A
B
J
A
B
B
G
A
A
B
A
A
A
A
A
S
A
Okay,
so
maybe
we
could,
like,
I
don't
know
the
best
way
to
to
go
into
that.
You
were
sorry,
you
were
listing
some
challenges,
so
maybe
I
I
didn't
want
to
cut
you
off
on
that,
because
that's
really
interesting.
Maybe
this
is
the
right
time
to
go
back
for
you
to
go
to
kind
of
go
over
some
of
the
challenges
now
that
that
there
is
with
the
existing
flow.
S
Sure
so
the
current
json
documentation
is
often
fairly
inaccurate.
The
documentation
itself,
like
the
written
words,
are
fairly
accurate.
However,
the
structure
is
often
wrong.
I
have
a
link
that
should
demonstrate
this.
It's
a
little
bit
code
heavy,
but
basically,
this
function
tries
to
realign
the
two
trees,
which
was
also
fair,
like
the
two
documentation
trees
or
like
rather
trying
to
match
our
tree
to
the
typescript
definition,
three
to
the
node.js
documentation
tree
and
often
things
are
incorrectly
nested.
S
S
If
that
makes
sense
like
sometimes
things
are
marked
as
objects
and
they're,
in
fact,
classes
or
they're
classes,
and
then
they
have
sub
classes,
there's
a
bunch
of
structural
issues,
the
link
I
just
posted
includes,
I
believe,
most
of
them
so
and
yeah.
So
this
is
the
primary
challenge,
as,
as
I
said,
the
the
structure
is
incorrect.
A
lot
of
the
times
and
sorry,
you
posted
a
link
to
the
okay.
S
The
generated
doc
is
it
or
no?
This
is
again.
This
is
not
very
idiomatic
code,
hence
needs
a
little
bit
of
cleanup,
but
this
method
basically
takes
in
the
json
document
that
I
that
I,
that
the
tool
downloads
and
transforms
it
and
tries
to
align
it
more
closer
to
the
tree
structure
of
the
the
typescript
definitions
right.
A
S
S
S
S
Another
major
thing
that
has
been
that
required
a
lot
of
manual
labor
is
say
you
have
the
the
methods
in,
for
example,
the
child
process
module
a
lot
of
these
methods
use
very,
very
similar
data
structures,
but
each
method
kind
of
documents
them
the
same,
like
there's,
no
overarching
types
that
are
declared
for.
Okay.
S
S
S
So
this
is
also
one
thing
that
is
currently
not
done
like
there's,
no
virtual
types
or
interface
declarations
or
object,
depletions,
whatever
you
want
to
call
them,
which
makes
this
a
little
bit
difficult
specifically
because
right
now
I
try
to
match
the
interface
declarations
that
we
currently
have
in
the
typescript
definitions
to
method
signatures.
But
this
was
not
really
doable
because
again,
they
don't
really
exist.
S
Q
S
P
D
A
D
Type
parser-
or
I
mean
they
elect
electron-
does
also
so
part
of
doc.
Doc's
parser
is
having
some
some
some
of
those
structures
defined
up
front
and
that
they
basically
get
applied
like
how
doc's
parser
is
written,
is
basically
a
way
to
textually
document,
typescript,
apis
or
api's
impact
in
typescript
with
markdown.
D
D
Yeah,
I
I
I
I
think
I've
shared
that
link
before,
but
I
I
did
some
examples.
Some
example
conversions.
I
think
the
primary
challenges
are
one
updating,
docs
parser,
it
honestly
would
probably
need
a
full
rewrite.
It
is
starting
from
scratch
is
a
better
solution
I
think,
than
using
doxperson
directly.
Unless
someone
wants
to
spend
you
know
the
time
to
update
it,
but
yeah.
D
We
also
have
some
use
cases
that
are
rather
weird
that
I
think
are
are
kind
of
what
simon
is
is
touching
on
here
of,
like
the
the
you
know,
a
method
can
just
change
like
the.
What
you
pass
to
a
method
is
not
consistent,
which
is
very
much
not
what
it's
not
very
type
friendly
is,
I
guess
the
way
to
put
it
which
makes
writing
docs
that
can
convert
to
types
very
hard,
so
we
would
also
have
to
bolt
on,
like
switching
for
that
somehow
and
it's.
D
S
A
A
D
It's
it's
a
fit,
but
I
I
think
it's
a
good
thing
to
take
inspiration
from
it's.
Not
something
to
directly
use
is
the
way
I
I'd
I'd
approach
that
it
it.
We
can
take
a
lot
of
inspiration
from
it,
I
think
directly
using
it.
It
will
be
just
as
much
work
to
directly
use
it
as
it
will
be
to
write
something
from
scratch.
That
is
a
little
bit
more
tuned
to
our
needs.
D
D
D
It
makes
it
makes
you
have
to
write
markdown
a
specific
way
which
ends
up
reading
a
lot
better,
which
is
a
huge
win
and
there's
also
certain
things
you
can
do
like
you
can
require
code,
examples
and
fail
or
like
output.
All
of
the
things
that
don't
have
code
examples
which
to
order
this
point
earlier,
giving
code
examples,
is
actually
really
good
for
types,
because
you
can
give
that
in
the
type
definitions-
and
I
think,
definitions
and
and
give
that
surface
set
to
end
users.
And
then
we
can
split
that
out
in
the
output.
A
T
D
D
D
D
P
U
D
D
D
It's
it
can
only
render
one
at
a
time
and
it
updates
the
other
one.
Well,
we
can
look
at
the
raw
mark
down
then
yeah,
which
I
guess
is
probably
a
little
bit
better.
So
one
thing
I
did
have
to
do
is
I:
there
is
no
syntax
in
doc's
parser
for
these
the
introduced
in
so
that
I
stripped
all
that
out.
I
we
would
want
to
reintroduce
that
as
a
specific
syntax,
but
we
would
want
it
to
be
raw
markdown
still
so
not
html
comments.
D
A
D
A
D
D
Other
ones,
so
one
of
the
benefits
of
how
electron
does
is
it
structures
it
into
you
have
to
structure
in
like
your
methods
and
there's
a
there's,
there's
a
few
different
structures
that
they
follow.
I'm
not
recalling
them
off
of
off
the
top
of
my
head,
but
this
is.
This
is
one
example
of
you
know
you.
You
move
everything
into
a
methods
heading.
T
D
Then
can
get
parsed
into
like
that.
Allows
you
to
kind
of
parse
it
correctly
out
into
the
these.
Are
methods
on
query
string
and
that
kind
of
helps
with
some
of
the
type
stuff
which
is
really
nice,
see
here,
I'm
trying
to
yeah
this
one
was
particularly
challenging
so
yeah.
This
is
the
most
simple
example
that
I
that
I
did
in
this,
and
I
wanted
to
bring
that
one
up
intentionally.
It's.
D
A
A
D
Yeah,
I
think
v8
was
particularly
annoying,
but
let
me
let
me
double
check
to
make
sure
here:
yeah
yeah,
so
it
v8
starts
getting
into
classes.
I
will
just
do
the
same
here.
I
will
not
change
the
file
names,
so
this
is
the
new
v8
one,
and
this
is
the
old
v8
one
and
feel
free
to
follow
along
in
the
actual
link
that
I
pasted.
D
D
D
A
But
I
mean
everybody
else
on
this
call
sanity
check
me,
but
that
doesn't
seem
terribly
like
if,
if
you
wanted
to
sit
down,
if
I
want
to
sit
down
and
say
how
do
I
transfer
one
to
the
other
that
I'm
still
pretty
easily
to
understand
right,
like
we'd,
have
to
document
that
says,
like
you're
documenting
a
class,
you
use
these
headings,
but
it
seems
like
something
that
could
be
fairly
easily
documented
and
people
could
help
you
know.
Crowdsource
moving
things
over
would
actually
be
possible.
T
D
What
you're
saying
okay,
which
again
it's
not
a
lot
like
there,
there's
not
a
lot
there
now,
okay,
programming
side
of
it
is
a
you
know.
Implementing
this
of
parsing
mark
down
and
extracting
this
into
jason
is
is
a
little
bit
of
work,
but
it's
not
it's
not
an.
You
know
obscene
amount
of
work.
It's
also.
B
D
D
The
other
thing
that
that
benefits
to
to
your
point
earlier,
michael
about
the
project
and
kind
of
being
agnostic
of
typescript,
the
other
thing
that
tita
that
electron
does
with
this
is
they
have
automation
around
it
in
the
repo.
So
when
say
I
go
and
make
a
change
to
I
don't
know.
Fs
I
make
a
change
to
fs
I
I
can
see
that
they
have
a
bot
that
basically
checks
to
see.
Okay
gold.
Has
this
method
been
updated?
Have
the
docs
been
updated?
D
No
and
then
you
can
kind
of
make
sure
to
push
people
towards
updating
docs,
in
addition
to
the
the
apis
that
they're,
representing,
which
is
very
useful
in
making
sure
that
docs
are
synced
and
therefore
types
are
synced.
So
we
don't
get
into
a
situation
where
you
know
it's
harder
to
keep
the
the
types
of
updated
over
the
long
term,
since
they
can
just
kind
of
be
generated
automatically
from
people
pushing
it.
Pushing
changes
when
they're
happening
right.
A
Makes
sense
so
my
next
question
would
be
like.
Can
you
just
show
us
an
example
where,
like
we
couldn't
follow
the
electron
style
guide
and
have
it
just
work
because
writing
a
whole
new
tool
is,
is
a
much
higher
bar
than
saying
hey,
we've
got
a
tool
and
we've
got
a
definition
of
a
style
guide.
Yep.
Are
we
okay.
D
D
D
Different
things
first
parameter
can
be
different,
like
you
can
do
server.listen
options,
callback
or
server.list
and
path
backlog,
callback,
which
is
just
it's
wonky
and
hard
to
enter
serverless
import
host
backlog,
but
like
very
hard
to
define
that,
and
so
we
would
have
to
kind
of.
If
we
wanted
to
use
docsportster,
which,
like
is
possible,
we
would
need
to
kind
of
extend
it
in
a
way
that
allows
us
to
have
this.
These
alternate,
like
variants
variants,
yeah
variant.
A
It's
basically
like
same
method,
but
here's
the
three
variants.
You
know.
Basically,
you
could
document
the
three
methods
separately
yeah,
but
then
they
need
to
be
somehow
tied
back
together,
right,
yeah.
Exactly
yeah
is,
is
I
mean,
I
guess,
does
you
know
and
typescript
as
an
example?
Would
it
allow
you
to
just
treat
them
as
separate
methods.
B
No
well
yeah,
let's
just
you
know,
typescript
supports
method
overrides
so
effectively.
This
can
definitely
be
represented
in
the
type
system
quite
easily.
You
just
have
to
know
that
they're
the
same
method
on
the
same
object
and
typescript.
You
can
just
provide
two
different
methods
to
it.
As
long
as
only
one
has
an
implementation
which
isn't
a
problem
on
your
side,
because
you're
not
only
defining
types,
that
would
be
totally
fine,
it
would
just
be
a
matter
of
you
knowing
how
to
describe
it.
So
there's
lots
of
dogs
in
my
room
now.
D
D
So
you
have
to
figure
out
how
the
type
definitions
are
consumed,
which
I
I
don't
know
enough
typescript
to
be
able
to
say
how
to
do
that.
I
I
have
a
feeling
order
does
but
yeah
basically,
you'd
want
to
figure
out
how
to
represent
that
kind
of
information
in
a
typing
system
and
then
re-represent
that
in
markdown
and
then
basically
allow
for
the
conversion.
A
D
D
D
D
A
D
You
have
to
figure
out
how
to
indicate,
and
this
this
could
be
a
similar
function
of,
like
you
know,
the
the
kind
of
front
matter-esque
style
that
we're
doing
now
with
the
emel.
How,
however,
we
implement
that
we
could
do
a
similar
thing,
but,
like
you,
do
have
to
figure
out
how
to
implement
that,
and
I'm
not
saying
like.
D
I
know
how
to
implement
it,
because
I
don't,
but
you
have
to
figure
out
figure
that
out
it's
not
you
can't
just
do
it
and
have
it
work
like
you
actually
have
to
think
about
how
to
implement
implement
something,
so
it
can
be
rendered
through
time
or
included
three
times
and
then
which,
like
there's
ways
you
can
do
that
like.
I
I'm
coming
up
with
ways
in
my
head,
but
I
haven't.
D
A
E
D
B
But
you
know
the
way
that,
even
if
you
were
just
dumbly
taking
this
mark
down
and
turning
it
into
a
an
interface
each
time
that
would
actually
end
up
just
working
out
right
in
typescript
today,
because
it
allows
for
the
same
overwrite,
overriding
and
augmenting
when
you
actually
have
two
things
with
the
same
name
on
the
same
object
class
function
whatever.
So
I
don't
think
it's
necessarily
something
you
need
to
worry
about
from
the
side
of
how
can
typescript
and
the
dt
scripts
handle
it.
A
I'm
just
trying
to
like
for
us
to
understand,
like
how
small
is
the
delta,
because,
if
the
delta
delta's
quite
small,
it
would
be
easier
than
like
if
it's
I'm
always
eternally
optimistic
right.
So
I'm,
like
you
know
today,
it's
for
some
reason,
says
you
can't
it
sees
those
as
the
same
and
there's
some
conflict
or
something
like
so
can
a
little
bit
of
code.
D
There
are
some
bugs
with
multiple
class
exports.
I
think
those
there
there
was
a
there
is
a
pr
up
that
has
not
been
merged.
That
fixes
that
so
that's
not
particularly
a
challenge,
I'm
not
outside.
Of
that,
I
can't
recall
I
I
I
believe
I
stopped
working
on
this
because
of
that
and
it
fundamentally
breaking
the
export.
So
it's
kind
of
hard
to
validate
things
but
yeah,
that's
that
was
the
specific
big
one
and
I
know
there's
some
other
I've
been
told.
D
A
A
B
Yeah,
absolutely,
I
think
it
I
tot.
I
think
it
totally
is
I
mean
to
to
to
assume
that
all
of
the
work
would
be
on
your
side.
Here
is
we
are
we
folly
and
the
dt
side
would
definitely
be
able
to
fix
any
of
that
20
side
or
even
just
ignore
it
right.
Remember
today
we
have
no
automation,
tooling
and
we're
doing
okay,
so
the
automation,
tooling,
is
augments
that
existing
experience
basically.
A
Okay,
so
yeah,
so
that
that
okay,
so
the
it
sounds
like
from
this
discussion,
the
biggest
win
would
be
adding
a
little
bit
more
structure,
and
I
think
you
know
from
the
example
tyranny
showed
me.
Some
of
it
is
relatively
straightforward,
which
is
adding
like
I
guess,
if
we
added
that
to
our
markdown,
so
I'm
also
trying
to
think
like
what
does
it
break
on
our
side
right?
So
today
we
have
a
flow.
We
start
with
what
we've
got
in
the
docs
that
generates
is
our
html.
A
D
A
D
I
mean
so
the
approach
I'd
say
here
is
basically
adopt
the
electron
style
guide
as
how
we
should
write
things
and
like
there's
definitely
gonna
be
problems.
There's
definitely
not
problems
but
like
differences
and
address
those
differences
and
like
maybe
update
them,
but
yeah
overall
use
the
electron
style
guide
and
start
switching
some
docs
over
that
that
allows
us
to
get
the
better.
D
The
better
structure,
I
think
like
it
seems
to
be
a
better
structure
to
me
at
least
than
what
we
presently
have,
which
is
just
as
mentioned
earlier,
a
lot
of
methods
without
like
a
lot
of
structure.
So
it
gets
us
a
little
bit
closer
on
that
and
then
we
can
begin
you
know
again.
I
want
to
make
sure
that
I
I'm
saying
this
like.
I
cannot
do
these
dog
sports
or
changes
myself
like
alone-
that's
not
something
I
can
do
so.
D
A
D
D
A
A
A
B
A
The
the
the
other
thing
too,
is
like
that
json
we
might
need
to
generate
the
html
right,
so
it
may
be
that
that's
just
there
because,
and
so
we
might
need
to
figure
out
how,
like
you,
would
have
a
different
set
of
json
that
you
could
use,
because
maybe
we
can't
get
rid
of
that
anyway,
but
but
okay
but
yeah.
I
kind
of
understand
that.
Okay,
it's
this
separate
parser,
so
you've
run
it
tierney
a
few
times
and
what
percentage
of
the
api
today
would
it
generate
for
probably
some.
A
D
It
doesn't
work,
it
doesn't
work
for
our
ap
like
I
was.
I
rewrote
query
string.
It
works
for
query
string.
I
think
I
it
works
for
another
one,
but
when
I
I
read
it,
v8
is
like
kind
of
a
more
challenging
one
and
v8
is
where
it
breaks,
because
it
has
multiple
class
exports,
so
anything
that
doesn't
have
multiple
classes
can
be
converted
relatively
easily.
Once
you
get
to
multiple
classes
it
breaks.
I
can
also
push
to
try
to
get
that
pr,
but.
D
Yeah
yeah-
and
I
I
think
I
I
think
we
should
also
be
looking
at
this
as
we
are
taking
on
a
dependency
that
we
will
want
to
make
help
maintain.
We
do
we
don't
want
to
just
rely
on
them,
maintaining
it.
We
want
to
help
maintain
this,
because
there
are
things
that
we
need,
that
they
don't
and
they
have
no
reason
to
do
so.
Yeah.
A
D
A
Right
so
we
do,
I
think,
I
think,
before
we
did,
that
it'd
be
good
to
get
the
discussion
like
tsc
agreement
that
like
yeah
this
makes
sense.
This
should
be
like
an
initiative
where
we
want
to
move
from
where
we
are
to
there
right
and
it
supports.
We
can
say
it
supports
a
number
of
things.
You
know
one
might
be
doing
better
better
on
our
type
side,
better,
just
visible
stuff
in
terms
of
the
docs
and
so
forth.
A
D
A
Can
we
tweak
something
right
and
I'm
like
okay?
Well,
then,
we
really
need
somebody
who's
gonna
do
something
versus.
Maybe
we
could
tweak
a
few
and
get
yeah?
That's
right.
You
know
eighty
percent
or
something
sorry
explore
doc's,
purser
and
so
there's
this
sort
of
it
sounds
to
me
like
there's
one
fundamental
fix
that
if
it
got
made
you'd
be
a
lot
more
positive
in
terms
of
how
much
we
could
potentially
generate
right.
Yeah.
D
A
Sure
it's
it's
like
you
know.
Okay,
so
does
multiple
export
fix,
get
a
large
generation
or
more
enough
enough.
I'm
gonna
say
enough
stuff,
so
it's
basically
like
if,
if
the
multiple
exports
fix
allowed
generation
of
say
80
of
what
we
had
I'd,
be
like
hey,
that's
enough
that
maybe
we
should
have
an
initiative
to
move
things
over,
because
we
think
that's
good
for
a
number
of
reasons
and
even
like
a
job
that
would
generate
it
somewhere,
because
that
would
be
adding
value.
It
sounds
like
to
the
type
side
of
things.
D
I
mean
it's
free
to
run
it
like
it
takes
like
10
seconds:
it's
not
a
lot.
I
I
would
recommend
running
it
and
publishing
it
regardless
it
and
again
there
are
like,
if
we
actually
do,
run
it
and
publish
it.
There
are
some
additional
benefits
that
we
can
get
around
like
there.
There
is
potential
for
actually
improving
the
the
development
lifecycle
for
node,
which
is
a
benefit
as
well.
A
But
that's
not
a
I'm.
Just
looking
like
mvp
might
be
just
something
where
we
we
run
the
docs
parser
and
validate
like
say.
If
we've
converted
over
a
file,
we
tagged
that
as
like
that
file's
been
converted,
and
we
run
the
validation
during
prs
and
stuff
to
make
sure
that
they
don't
we
don't
regress,
that
yeah
yep
and
then
you
know,
even
if
we'd
ever
published
that,
then
the
the
consumers
could
actually
run
it
themselves
generate
the
json,
because
once
you
publish
you,
know
just
publishing
something
and
saying
we're
now.
D
A
D
A
C
D
D
O
P
D
Right,
okay,
yeah
same
yeah,
it
bothers
me
that
we
do
yaml
front
matter
and
html
comments,
but
I've
tried
to
hold
that
opinion.
I
love
it.
It's
a
it's
a
great
hack,
it
is
a.
It
is
a
hack
it
I
mean
it
works,
but
yeah.
I
I
think
having
it
as
a
part
of
like
it
increases
readability.
It
helps
helps
in
a
lot
of
different
ways.
I
think
for
end
users.
A
D
I
mean
one
one
one
approach
we
could
take
to
this
is
leave
existing
docs
as
they
are
and
have
a
new
docs
section
somewhere
and
kind
of
split
the
two
and
like
let
docs
exist
as
they
are
without
having
you
know,
I
guess
that
gets
difficult
with
docs
changes
and
having
to
like
import
those
over.
It
gets
annoying.
M
M
The
the
reason
that
we
have
the
two,
the
the
introduced
in
and
the
added
the
the
added
yaml
metadata-
that's
turned
into
a
twisty
on
the
in
the
html
docs,
so
in
the
html,
docs
and
node.
When
you
look
at
a
particular
method,
if
it's
got
like
added
a
sort
of
changed,
yaml,
there's
there'll
be
a
little
twisty
there,
where
you
can
drop
the
twisty
down,
and
it
will
tell
you
which
you
know
when
someone's
actually
written
into
the
metadata.
This
particular
version
changed
this
method.
M
M
Trying
to
think
of
one
of
those
of
my
head
there,
one
one
of
the
modules.
If
you
were
to
open
it
and
it
only
existed
from
like
node
six,
the
introduced
in
would
tell
the
docs
the
the
node
html
generator
that
this
dock
only
exists
from
like
node
6
onwards,
so
it
wouldn't
generate
an
alternate
link
for
say
a
node
4
version
of
the
dock.
A
F
A
M
A
M
I
was
gonna
say
that
could
be
challenging
for
some
bits
of
the
docs,
because
not
all
of
the
docs
are
straight
api
and
docs.
So,
for
example,
all
that
stuff
about
module
loading,
which
I
ident.
Why?
You
would
represent
that
as
in
comments.
So
you
would
need
some
either
some
hybrid
approach
or
a
complete
rethink
or
as
to
the
current
documentation
structure.
A
T
T
So
I
I
would
say
that
if
it's
already
separated,
I
would
prefer
just
to
keep
it
separated,
because
once
you
start
switching
back
and
forth
now
you
have
the
legacy
people
getting
confused
where
it
is,
and
then
you
have
a
certain
amount
of
documentation.
That's
not
consistent!
So,
and
I
don't
know
if
we
want
to
do
a
major
work
on
that.
D
A
Yeah,
okay,
okay,
so
I
I
think
now
would
be
a
good
time.
We
could
take
like
a
15-minute
break
if
that
works
for
everybody
and
then
we'll
come
back.
So
why
don't?
We
come
back
at
noon
and
we'll
kick
off
the
second
session.
If
that
works
for
everybody,
okay,
I
will
leave
the
stream
going,
but
stop
my
video
and
I'll
be
back
in
12
minutes.
I
think
it
is
now
thanks.
A
Okay,
so
yeah
we're
a
few
minutes
late.
Sorry
about
that.
So
now
we
can
move
jump
into
our
second
topic,
which
is
the
single
executable
applications,
executable
applications.
This
was
another
one
of
the
things
that
came
out
of
our
discussion
on
next.
Ten
that
that's,
you
know
important
to
the
success
of
node,
going
forward
as
a
use
case
that
you
know
enough
people
use
that
we
should
make
sure
that
we
think
we're
doing
the
right
thing
to
support.
A
In
terms
of
that,
I
don't
know
what
the
best
way
to
get
started.
Is
I'm
not
super
super
familiar.
I
know
we
have
a
number
of
people
from
versailles.
Who've
been
working
on
a
package,
so
maybe
it
makes
sense
for
you
to
just
give
us
a
an
intro
overview
of
that
and
where
you've
seen
it
used
and
that
kind
of
stuff-
and
we
can
go
from
there-
does
that
make
sense.
N
T
D
A
A
N
H
A
So
we
were
just
starting
the
discussion
on
the
single
executable
applications.
We
were
wondering
stifle,
if
maybe
you
could
give
us
since
you're,
maybe
the
most
up
to
speed
here,
give
us
some
context.
You
know
what
kind
of
places
do
people
do.
You
use
this
for
today
that
you're,
aware
of
and
sort
of
kick
off
the
discussion.
R
Yes,
so
we
kind
of
have
a
history
of
trying
different
solutions
and
that's
how
we
have
kind
of
three
different
tools
that
are
three
slightly
different
ways
of
bundling,
and
so
I
think
the
first
one,
maybe
igor
knows
a
little
more.
The
history
here
was
pkg
and
it
kind
of
bundles
the
node.js
executable,
with
the
user's
code
into
a
single
binary,
and
I
think,
that's
similar
to
what
deno
or
dino
uses.
R
So
like
we'll
use
this
for
clis,
for
example,
so
you
can
npm,
install
and-
and
you
just
have
a
single
js
file,
and
then
it
has.
You
know
the
executable
directive
at
the
top,
but
it
still
relies
on
node.js.
You
select
install
node.js
separately
and
then
the
third
solution
we
we
came
up
with
was
nft
and
that
even
a
step,
further
back,
which
is
tracing
every
like
given
a
single
input
file,
find
all
the
dependent
files
that
that
it
relies
on.
R
So
you
know,
import
require
and
recursively
figure
out
every
possible
file,
as
well
as
every
possible
asset
that
might
be
from
a
read
file,
and
then
you
just
get
a
trace
back.
You
can
do
whatever
you
want
with
that.
You
can
remove
those
files
that
are
no
longer
used
and
come
up
with
with
kind
of
the
smallest
amount
of
files
you
need,
but
there's
no
bundling
done
there.
R
So
it's
you
know
if,
like
a
cli,
I
guess
is
a
good
example
of
like
you.
You
know
you
want
to
have
a
single
binary
or
maybe
not
even
a
cell.
Maybe
you
have
some
sort
of
like
gui
that
you've,
you
know
written
with
electron
or
something
but
having
a
single
binary
is
kind
of
desirable
there,
because
it's
easy
to
download
it's
easy
to
run
and
I
think
get
conceptually
like
as
an
end
user.
It
makes
more
sense.
R
It
just
introduces
some
more
complexity.
I
don't
know
if
the
person
is
currently
maintaining.
Pkg
is
here,
but
I
saw
like
there
was
a
comment
about
some
of
the
the
file
structure
there
and
I
think
someone
correct
me
wrong.
I
think
this
is
what
denno
or
dino
has
for
their
for
their
solution
for
a
single
executable.
R
A
G
A
R
D
I
mean
I,
I
think,
to
to
the
the
point
that
you're
bringing
up,
or
I
said
I
said
I
started
to
mix
miles
michael
and
michael
with
a
k
like
I
don't
know
why
all
three
names
came
to
my
head
at
once.
Sorry,
michael
to
the
to
the
point
of
the
difference
between
the
three.
I
think
all
three
could
be
something
that
would
be
an
interesting
strategy
like
if
we
try
to
do.
D
Doing
allowing
for
a
little
bit
more
extensibility
and
room
in
the
future
for
kind
of
different
approaches
to
the
same
same
problem
or
well
similar
problems,
I
guess
could
be
interesting
but
yeah.
I
think
I
think,
for
what
we're
talking
about
here.
Pkg
is
probably
the
closest,
although
I
think
nft
is.
Oh
god.
I
can't
I
struggle
to
say
that
I
think
nft
is
potentially
interesting
as
as
a
tool.
A
A
So
I
guess
then
yeah.
So
if
we
look
at
pkg-
and
I
guess
also
box
node-
the
question
comes
down
to
you
know:
is
the
current
situation,
good
effective,
you
know
ideal,
or
is
there
something
that
you
know
it'd
be
useful
for
the
project
to
do
to
support?
You
know
people
who
want
to
do
this
and
not
necessarily
provide
it
built
in,
but
to
provide
things
that
help
anybody
who
wants
to
do
this?
P
A
So
I
guess
yeah,
no,
that's
true
with
a
bunch
of
different
ones,
so
I
guess
maybe
it
would
be
good
to
look
at
what
you
know.
What
are
the
common
challenges,
then,
in
terms
of
you
know
the
when
for
pkg
or
the
other
options
like
do
we
know?
What
is
it
that's
hard
to
do
today
that
we
should
call
out
that
list.
L
L
L
L
A
I
I
guess
on
that
yeah,
that's
a
good
breakdown
makes
me
think.
I
think
one
of
the
the
challenges
which
I
I
that
was
mentioned
in
in
the
one
of
the
posts
for
the
person
who
couldn't
make
it
but
was
did
provide
some
useful
info.
Was
they
currently?
You
know
I
think,
in
in
pkg
and
for
box
node
it
requires
compiling
node
itself.
L
It
requires
patches,
while
if
we
don't
have
this
aim-
and
we
only
want
to
there
to
or
only
single
executable
to
be
there-
and
we
are
okay-
that
all
the
sources
all
the
files
are
recoverable
from
that
executable,
then
we
don't
need
it
needs,
checking
I'm
not
entirely
sure,
but
I'm
almost
sure
that
current
node.js
process,
current
node.js
executable,
is
totally
fine
with
it.
We
can
like
join
them
together.
I
mean
notepad
node.js
file
and
the
the
payload
and
starting
it
can
look
around.
L
So
some
minor
some
minor
changes
I
needed
only,
but
still
maybe
I'm
wrong.
Maybe
there
is
still
a
place
where
no
djs
decides
what
is
the
mode
it
is
running.
If
I
remember
correctly
the
same
place,
it
is,
it
is
deciding
if
it's
going
for
rapple
or
for
a
script.
You
know,
and
then
that
was
another
mode
added
along
with
rebel
and
script.
That
was
a
like
self-executable
mode.
A
L
R
A
Is
it
that
you
know
if
there
was
an
executable
that
then
you
can,
can
you
could
you
take
the
existing
node
executable
assuming
it
in
you
know
when
it
ran
it
was
going
to
do
the
right
thing
and
then
create
a
new
executable
which
incorporates
that
you
know
by,
but
obviously
you
would
need
to
create
a
new
exe
with
extra
additional
data
right,
like
the
the
code
segments
and
whatever
for
node
plus
some
other
stuff.
Is
that
technically
feasible?
A
L
A
L
We
have
a
good
example
is,
as
far
as
I
remember,
self-extracting
archives,
like
you,
know,
winrar
it's
it's
possible
to
run
an
executable.
It
does
some
extracting
behind
the
scenes
to
some
temporary
directory
and
then
it
runs
some
executables
that
were
just
extracted.
So
is
that
what
you?
What
do
you
mean.
A
What
I
I
guess
I
was
thinking
more
of
like
an
actual
single
binary
that
could
just
run,
but
and
and
from
that
binary
do
what
you
needed
to
do.
So
it's
still
actually
a
single
binary,
but
that
it's
somehow
you
know
you
we've
got.
We've
got
what
we've
published
on
the
the
node.js
download
site
right
like
is
there
some
flow?
Where
you
take
that
and
then
you
take
the
binary
and
you
run
it
through
some
process
that
ends
up
with
a
new
binary
that
can,
you
know,
run
an
application.
L
It's
not,
for
example,
showing
the
whole
javascript
bundle.
It's
not
wasting
time
on
all
the
whole
javascript
bundles.
So
such
a
internal
file
system
that
allows
access
to
individual
files
is
a
is
a
good
speed
benefit.
I
guess
I
guess
the
same
is
how
electron
stores
files
in
sr
archive
but
correct
me.
If
I'm
wrong,
please.
A
I
think
you're
right
yeah,
I
was
more
just
trying
to
understand,
is
it
is
it
like
if
they're
like?
Obviously
what
we
publish
will
never
include
the
application
right,
so
it
could
include
some
additional
functionality,
but
then
can
you
take?
Can
you
take
that
new
node
version
and
then
externally
package
it
together
with
your
application
and
then
generate
a
binary?
That
may
be
exactly
what
pkg
does,
but
unfortunately,.
L
L
L
A
A
Lets
the
v8
by
code
execute
without
source,
which
I
guess
that's
the
part
which
is
like
hey.
If
you
need,
if
you
want
to
hide
things,
that's
needed
and
then
the
miscellaneous
disable
inspector
enable
lto,
I'm
not
quite
sure
what
why
those
are
needed,
but,
and
then
the
project
itself
right.
Okay,
the
dependency
tracer
generator
of
files
required
by
the
user
project
produces
by
code.
Javascript
files
generates
a
snapshot
that
contains
the
metadata
files,
offset
ranges,
prelude,
script,
that's
baked
into
the
executable
and
executed
on
launch
the
virtual
file
system.
D
A
A
A
M
K
K
As
far
as
I
understand
like
right
now,
you
package
your
initialization
scripts
and
you
will
use
them.
You
execute
them
to
get
to
the
state
before
you
can
before
your
application
starts
to
run
so
so
useless
snapshot
would
be
some
kind
of
nice
to
have
feature
that
can
be
used
on
top
of
that,
but
it's
not
a
necessity
for
them.
K
K
K
So
you
would
still
need
to
have
some
scripts
that,
like
with
the
serialized
hip
with
a
de-serialized
hd
server,
you
open
it
up
again,
and
maybe
you
need
to
do
some
cleanups
or
further
initialization
to
actually
make
it
like
set
it
up
to
a
point
where
you
can
make
it
functional
so
that
kind
of
post,
initialization
script
would
be
something
that
this
kind
of
package
installation
would
also
need
to
take
care
of
so
yeah.
Those
are
so
it's
it
would
be
like
useless.
K
A
K
It
would,
but
it's
mostly
as
because
what
is
snapshots
is
the
heap
as
a
result
of
execution.
So
if
you
execute
some
scripts
to
get
to
the
heap,
the
heap
will
also
retain
the
source
of
as
a
way
for
debugging.
So,
for
example,
if
you,
after
deserializing
the
heap
you
hit
some
function,
that
you
want
to
debug
in
the
debugger
it'll
va
will
need
the
source
to
display
in
through
the
inspector
protocol.
So
it
will
retain
that
source
from.
K
K
A
if
I
go
ahead
it
would
be,
but
I
suppose,
with
something
that
the
pkg
patches
do
they
they
probably
like,
if
that
kind
of
patches
are
also
applied
on
top
of
something
that
implements
useless
snapshot.
My
guess
is
the
the
the
script
will
also
go
away,
so
you
won't
be
able
to
debug
that,
but
it
will
still
work
because
bico
isn't
so.
K
A
Right,
I'm
just
I'm
just
looking
at
like
instead
of
having
you
know,
if
we,
if
we
already
have
snapshots,
if,
if
somebody
created
a
if
we,
if
you
bundled
your,
if
you
boiled
your
file
down
to
budge
your
application
down
to
a
single
javascript
file,
you
created
a
snapshot
and
then,
when
node
started
it
you
know
it
found
the
snapshot
somehow
and
loaded.
It
ran.
A
K
I
guess
this
is
probably
not
enough
if
you
want
to
build
a
single
executable
with
only
the
snapshot,
because
you
usually
need
to
do
something:
post,
snapchat
decentralization
to
take
user
input,
for
example,
because
usually
an
application
needs
to
take
user
input
to
perform
the
action
it
needs.
So
you
mean.
K
K
A
K
A
A
A
A
D
A
Yeah-
and
I
don't
know-
if
that's
for
this
use
case-
is
that
an
obstacle
or
not
right
like
if,
if
I
wanted
to
write
a
very
simple
like
maybe
it's
it's
the
target,
that's
important
as
well
like
if
I
wanted
to
write
a
really
simple
command
line
thing
equivalent
to
like
a
bash
script
and
get
it
into
a
single
executable.
That
would
be
a
challenge
you
know.
Compiling,
for
how
long
it
takes
to
compile
would
be
a
challenge.
Now
I
guess
a
bash
script
equivalent
is
closer
to
the
other
description
which
was
like
hey.
D
Right
and
I
mean
there,
we
could
take
a
dual
approach
right,
where
we
we
do
single
file
and
then,
when
you
actually
want
to
compile
it
for
specific
platforms.
That's
a
different
thing
that
is
like
the
next
step
that
you're
basically
distributing
you're,
building
your
distributable
and
then
you
could
use
like
the
normal
node
runtime.
In
the
meantime,
while
you're
working
on
it.
A
R
J
L
If
I
remember
correctly
well,
executable
files
have
their
own
formats
and
they're
different
on
different
operating
systems
like
msat
on
windows,
l
from
linux
and
maco
and
mac
os,
and
they
have
some
sections
there
and
in
most
of
the
cases
I
have
an
impression
that
there
is
just
a
one,
more
section
added
to
the
end
of
the
executable
and
that
it
has
some
cryptographic
signature
of
all
the
binary
before
that
section.
That
is
added.
L
Otherwise
they
say
like
either,
format
is
unrecognizable
of
the
binary
of
the
executable
or
they
may
simply
strip
the
ending
like
a
stream
operation.
Just
because,
oh
I
see
something
unnecessary,
as
not
mentioned
in
the
index
table.
What
is
it
it's
not
needed
and
yeah,
so
it
may
end
up
the
executable
to
be
signed,
but
without
payload,
so
they
are
not
functional.
A
L
But
I
believe
the
proper,
the
proper
looking
the
proper
formatting
of
the
executable
is
the
way
to
go
because
imagine
like
a
regular
build
of
knowledge.
Yes,
what
does
it
produce?
It
produces
a
pretty
proper
and
well
all
the
format,
format
well
and
yeah,
conforming
all
the
necessary
format
of
the
executable
of
this
operating
system
right.
We
should
follow
this
idea
and
the
packager,
I
believe,
should
produce
an
executable,
the
same
way
to
be
conformant
as
well
right.
A
A
A
Like
would
it
make
sense
that
you
know
part
of
that
the
stuff
that
was
in
there
was,
like
you
know,
suggestion
to
search
through
the
existing
search
through
the
exe
to
see,
if
there's
a
package
packaging
thing
on
startup,
I
somehow
wonder
if
there
would
be
a
way
that
you
know
that
the
way
to
do
that
would
be
to
have
something
in
node.
That
says.
Well,
if
there's
a
new
section,
then
let's
run.
C
A
A
A
It's
the
starting
script.
That
part,
though
I
don't
quite
understand
how
that
works.
That
would
work
because
that
needs
to
be
like
before
the
virtual
file
system
can
be
in
place.
Some
code
needs
to
be
inserted
to
insert
the
virtual
file
system.
Doesn't
it
I
guess
it
could
load,
it
could
load
from
that
section.
It
could
load
something
which
is
effectively
the
bootstrap
javascript
right.
L
Yeah
there
is
a
there
is
a
layer
in
over
fs
module
in
pkg,
so
it
tries
to
mock
to
to
to
inject
some
virtual
file
system.
So
it's
not,
it
is
it's.
It
looks
like
the
the
real
file
system,
so
yeah
there
must
be
some
script
or
maybe
even
some
official
fs,
mocking
or
fast
intercepting
solution,
because
pkg
well
is
a
was
a
standalone
tool
and
it
could
afford
being
hacky
in
few
places.
C
C
C
C
C
K
A
K
I
think
it
makes
sense
for
node
to
be
able
to
like
patch
itself
to
to
like,
for
example,
append
a
section
to
its
own
binary
and
then
be
able
to
boobstrap
again
from
that
binary.
But
in
terms
of
what
goes
into
that
section,
for
example,
if
you
need
a
virtual
file
system,
that
might
be
something
that
needs
to
be
implemented
in
the
user.
K
You
might
want
a
variety
of
a
variety
of
what
the
the
virtual
file
system
support
or
if
it
wants
to
do
any.
I
know
signature
matching
to
make
sure
things
match,
considering
security
and
whatnot
and
yeah,
and
that
might
be
something
that's
better
to
be
done
in
the
years
land.
But
in
terms
of
just
having
this
one
section
that
node
can
generate
and
bootstrap
from
that
seems
to
be
something
that
can
be
done
in
node
already.
A
M
K
K
So
we
need
isn't
like
I.
I
understood
that
the
question
was
how
you
could
generate
one,
this
one
thing
that
just
bundles
every
code
that
you
have
to
run
your
application
and,
I
think
boundary
bundles
already
kind
of
they
already
does
that,
even
though
it's
not
strictly
speaking
a
binary,
they
they
could.
You
know,
spit
out
a
javascript
file,
even
though
it
could
look
like
a
binary,
because
it's
not
readable
because
it's
minified
yeah
but
yeah.
But
that
already
is
something
that
that
that
that
kind
of
like
a
binary.
C
C
A
Yeah,
like
I,
I
guess,
though
it
could
be
a
js
string
plus
some
just
you
know,
here's
a
section
of
data
that
you
can
define
yourself.
Could
it
like?
Do
we
need
to
know
anything
about
the
structure
of
that
or
is
it
just
like
here's,
your
pointer
to
that
in
an
array
you
know,
I
don't
know
we
load
it
into
an
array
buffer
and
give
it
to
the
javascript
or
something.
K
I
think
it
would
be
probably
nicer
if
we
somehow
define
the
structure
of
that
section.
If
we
want
to
locate
an
entry
point,
because
if
the
the
section
is
just
one
javascript,
it's
just
one
block
of
javascript,
for
example,
it
probably
not
would
not
be
very
extensible
if
we
want
to
load
additional
configurations
that
might
be
necessary
to
handle.
K
A
K
You
can
probably
have
like
a
top
level
structure
that,
even
if
it's
just
like
one
one
key
value
pair
of
you
know,
the
key
is
the
entry
point,
for
example,
and
the
value
is
a
javascript
screen
string
that
that
that
javascript's
like
source
string,
that
users
define,
even
if
just
one
key
value
pair,
but
it
would
be
better
if
we
keep
that
as
a
a
structure.
Instead
of
you
know
just
one
right.
A
A
A
And
I
don't
know
igor,
like
does
does
if,
if
you
know,
if
the,
if
node,
basically
located
that
section
on
startup
read
in
the
javascript
bytes
started
running
them
and
passed
in,
I
guess
read
in
the
data
section
too
and
put
it
into
an
array
buffer
and
then
started
the
javascript
passing
it.
That
array
is
that
everything
the
bun
you
know
the
something
like
pkg
would
need
to
do.
The
rest.
L
J
L
Place
that
ncc
produced
javascript
bundle
into
that
section.
That
node.js
is
guaranteed
to
read
on
startup
and
yeah.
This
is
the
minimum
solution
for
shipping
a
cli.
Let
it
be
open
source.
I
mean
recoverable,
without
obfuscation.
By
the
way
we
can
still
obfuscate
this
thirster
or
whatever
mangles
the
variable
names
right.
So
the
missing
piece
to
bootstrap
any
any
approach.
Any
tooling
is
that
no
djs
does
something
on
startup
and
self
runs
like
this.
A
T
C
A
Node.Js
that
could
be
like
a
command
line
like
that
could
be
basically
like
we,
we
find
the
section
we
read
in
like
another
section
from
that,
sorry,
whatever
I'm
I'm,
we
find
the
new
section
in
there.
There
is
a
a
part
which
is
like
arguments
for
node
and
we
use
that
as
if
it
was
passed
to
us
on
the
command
line
as
part
of
the
startup.
L
K
I'm
I'm
wondering
if
it
makes
sense
to
have
like
a
flag
that
allows
you
to
specify
additional,
no
flags.
So,
for
example,
if
you
want
to
pass
a
va
flag,
you
sort
of
like
dash
dash
some
flag,
equals,
va
flag
values
and
possibly
no
flag
values,
because
they're
kind
of
treated
the
same
by
now
and
exactly
what
this
this
this
rule
flag,
I
don't
know,
would
be
so,
for
example,
when
you
run
chrome.
K
A
I
I
think
I
think
what
igor
was
suggesting
was
maybe
like.
What's
in
the
section
like
there's
two
sections,
one
which
is
like
effectively
the
command
line,
you
want
to
run
what
would
have
been
the
node
command
line,
so
it
includes
any
arguments
you
could
pass
to
node
and
if
and
because,
there's
already
a
dash
e.
That
would
let
you
execute
javascript
the
string
of
javascript
that
would
actually
cover
the
the
code
to
start
running
as
well
as
any
options
you
want
to
pass.
A
K
K
You
may
want
to
try
out
different
plaques,
for
example,
if
you
don't
usually
want
to
have
the
inspector
on,
but
in
certain
cases
you
want
to
launch
it
with
the
with
the
the
inspector,
then
you
want
to
like
run
it
differently.
Instead
of
having
the
inspector
the
the
dash
dash
inspect
flag
in
the
section,
so
you
probably
want
some
want
it
to
be
dynamic,
instead
of
being
being
part
of
the
configuration
in
the
section.
A
A
I
think
where
that
might
get
us
into
some
trouble
is
that
it
would
there
might
be
some
arguments
which
would
be
the
applications
of
arguments,
so
I
think
maybe
you're
back
to
like
we
would
need
an
extra
argument.
If
there's
a
section,
then
you'd
want
to
pass
the
command
line,
arguments
to
the
application
not
to.
A
R
R
K
K
Thing,
but
if
they
do
want
to,
for
example,
allow
users
to
like,
for
example,
start
the
ins
inspector
in
case
they
want
the
user
reproduce
some
issues
locally.
Somehow,
then
they
can
specify
in
the
section
that
the
the
bundled
thing
takes,
for
example,
js
flex
that
can
accept
additional,
va,
va
flats,
and
then
the
user
will
use
this
specified
flag
to
passing
additional
flags
if
they
want
to
run
the
to
start
the
thing
differently,
but
that's
totally
optional.
They
can
just
disable
it
by
not
specifying
anything
at
all.
A
K
K
We
can
probably
like
specify
that
this
must
must
be
placed
right
after
the
the
the
the
right
after
the
thing
that
the
executable
yeah
it
has
to
be
the
first
act
argument,
or
we
can,
you
know,
require
that
everything
every
additional
flag
specified
in
section
must
come
first
before
the
user
can
passing
anything
else.
That
can
be
that
that
need
to
be
passed
into
the
into
the
executable.
K
K
L
Well,
yeah
native
add-ons
must
be
deloaded,
like
they
load
operation
system
called.
So
I
guess
the
title
couple
to
file
system,
so
there
must
be
picked
up
from
the
file
system.
Real
file
system,
not
any
sort
of
virtual
one
right,
so
pkg
ended
up
or
with
placing
native
modules
nearby
with
shipped
executable.
L
A
M
M
A
A
So
I
think
maybe
that's
the
one.
The
fundamental
difference
is
like
box.
Node
takes
the
I'm
going
to
compile
node
and,
as
I
compile
add
extra
things
like
add
in
the
application
to
the
exe
and
then
the
bundle
onto
the
existing
node
is
the
other
approach
of
like
hey.
I
already
have
an
exe.
How
do
I
just
tack
something
onto
it?.
A
A
A
M
M
K
And
that
would
be
circlehead
right
so,
but
I
think
that
can
be
done
like
if
you
are
going
with
the
looking
for
something
in
in
the
binary
to
see.
If
there
is
this
section
that
we
need
to
bootstrap
from
then
we
can
just
add
an
add-on
condition
in
because
we
have
this
function
called
start
execution
that
that
looks
at
various
command
line,
flags
and
stuff
to
determine
the
engine
point.
K
So
when
the
third-party
main
was
a
thing,
it
was
one
of
these
conditions
in
that
giant
function.
So
to
make
the
the
new
entry
point
works.
We
just
need
to
add
another
condition
there
to
look
for
this
section
if
and
make
sure
that
it's
it's
checked
before
other
like
repo
stuff
is
checked,
and
if
this
section
is
present,
we
just
run
from
there
and
ignores
other
like
repo
checking
stuff.
A
M
No,
I
only
mentioned
it
because
it's
something
we
used
to
have
that
we
took
out
because
I
think
we
deemed
no
one
was
using
it
right.
Okay,
it's
just
sort
of
prior
art
and
it
may
be
completely
superb,
also
useless
in
this
discussion
or
or
maybe
there
are
things
we
could
look
at
when
we
used
to
have
that
in
terms
of
you
know
those
those
would
be
places
that
would
have
similar
modifications.
K
Yeah,
I
think
that
was
a
mechanism
compared
to
what
we
are
trying
to
see
if
it's
possible
here,
because
to
to
enable
third
party
main
it
was
pretty
simple.
You
just
check
if
there
is
this
script
called
third
party
main
and
if
there
it.
If
it
is
there,
then
you
run
it
and
you
stop
looking
for
other
execution
modes.
K
C
C
K
A
I
mean
that
we
could,
I
think,
like
we're,
really
just
doing
a
bootstrap
right.
So
I
I
think
if
people
want
to
do
more
complicated
things,
we
should
defer
them
to
generating
whatever
the
code
is
from
the
the
like
the
data
section
and
then
starting
it
in
the
right
way.
So
I
I
don't
know
if
that
bootstrap
needs
to
support,
like
I
think,
that's
kind
of
what
joy
might
have
been
saying
is
like
that.
Doesn't
need
to
support
too
many
different
options,
because
the.
K
K
A
K
N
Q
A
Q
P
P
P
K
A
R
K
K
K
A
K
Today
you
can
pass
it
the
the
cache,
but
you
also
pass
the
correct
corresponding
source.
Mva
will
check
that
the
source
matches
the
cache,
even
though
it's
a
very
simple
check.
It
just
check
the
length
matches,
but
so
you
can
like,
like
just
generate,
dump
like
a
gibberish
with
a
single
length
but
to
to
bypass
the
check.
But
right
now
va
requires
you
that
to
passing
the
original
source,
because
it
doesn't,
it
doesn't
assume
that
the
cash
can
be
the
only
source
of
truth,
because
it's
just
a
catch.
K
C
L
K
A
L
Additional
patches
are
required
for
sure
what
joey
was
talking
about.
You
must
say
to
v8
like
take
it
easy
that
there
is
no
source
code
relied
on
the
cache
alone.
In
addition
to
a
few
more
patches,
that
jcc
mentioned
is
that,
for
example,
we
disable
doing
anything
related
to
source
code.
Like
I
can't
recall,
it's
flash
something
like
flash,
it
requires
all
the.
In
short,
all
the
places
that
v8
assumed
source
code
to
be
around
must
be
stopped.
Blocked.
V
A
A
Or
even
that
e,
like
we're
talking
about
passing
the
bootstrap
code
through
the
dash
e
that
that
may
be
regular
code
that
may
be
like
non.
You
know
code
with
source
code,
because
maybe
that's
okay,
because
you
know
that's
just
being
bundled
in
here,
but
then
eventually,
that's
needs
to
start
running
some
javascript,
which
you
don't
want
to
have
the
source
for.
L
K
Right
actually,
I
found
I
realized
that
I
discussed
about
it
with
young
at
one
point
when
he
was
still
on
the
v18
and
there
was
apparently
a
prior
art
and
he
said
it
was
doable
so
I,
but
he
he
isn't
on
the
v80
now
so
that
might
still
be
subject
to
whoever
the
owner
is
thinks
but
yeah.
I
suppose
it's
more.
A
K
A
Those
are
the
sort
of
concrete
ones
I
can
think
of,
and
then
of
course
you
know
this,
this
would
capture
what
we
think.
You
know
a
path
of
what
would
add
value.
Then
it's
always
a
matter
of
you
know
finding
people
who
are
entrusted
to
help
move
it
forward
and
that
kind
of
stuff,
but
having
that
documented,
would
be
a
good
first
step.
A
I
think
it'd
also
be
good
to
target
our
document.
Our
target
flow,
like
I
think
everybody
was
in
agreement,
that
the
the
sort
of
split
between
what
no
the
node
project
does
and
what
is
done
externally
in
projects
like
definitely
types
made
sense,
but
I
think
documenting
and
capturing
that
somewhere
in
the
node
project
makes
sense
to
me
it's.
It
seemed
like
you
know.
The
electron
style
guide
was
a
good
initial
step
that
that
might
help
us
get
to
something
more
structured.
That
would
make
it
easier
for
consumption
and.