►
From YouTube: The CITGM Diaries - Myles Borins, IBM
Description
The CITGM Diaries - Myles Borins, IBM
"During October of 2015 I was given the task of working on The Canary in the Gold Mine, a smoke testing utility that automates running unit tests of various various modules in the node.js ecosystem. CITGM has been incredibly successful, finding all sorts of regressions across the ecosystem and in node core itself.
I have kept a diary of all the weirdness, lets examine how things break!"
A
A
Nice
and
inside
I
just
told
myself,
you're
clapping
for
me,
so
I
feel
really
good
right
now.
So
this
is
the
first
slide
I
put
on
every
presentation
when
I
do
this
kind
of
little
mantra
and
I
turn
towards
this
screen
and
I?
Look
up
and
I
put
my
hands
and
I.
Just
do
this,
and
now
I
heard
you
laugh
and
I
didn't
see
you
and
I'm
like
ready,
I'm
ready
to
go
I'm
miles.
It's
very
nice
to
meet
all
of
you.
Thank
you
all
so
much
for
coming
out
and
giving
me
your
time.
A
I
really
appreciate
it.
I
currently
work
at
a
small,
disruptive,
startup
cloud,
firm,
called
IBM.
It's
worth
mentioning
the
views
in
this
talk
are
my
own,
although
it
is
a
lot
of
the
work
that
I
do
for
IBM,
but
anytime.
That
I
say
anything.
That
sounds
like
a
personal
opinion.
It's
probably
mine,
but
so
what
exactly
is
sit
gimm
now
you
probably
saw
that
the
talk
is
entitled.
The
sit,
Kim
Diaries,
so
sit.
Kim
is
an
acronym
and
it
stands
for
canary
in
the
gold
mine,
and
some
of
you
may
be
thinking.
A
Well,
it's
actually
canary
in
the
coal
mine
is
the
the
proper
term
and
the
project
was
started
and
named
by
James
Snell
who's.
My
mentor
at
IBM
and
I
asked
him
this
question
and
said
James.
Why
did
you
call
it
canary
in
the
gold
mine-
and
he
just
said
it
sounds
good
so
that
that's
why?
But
what
is
it
canary
in
the
gold
mine
is
a
smoke
testing
utility
that
we
use
in
the
node.js
project,
primarily
to
make
sure
that
we
don't
break
your
code.
A
A
So
canary
in
the
gold
mine
will
go
and
will
grab
the
source
code
for
a
named
module.
It
will
run,
npm
install,
will
run
npm
test
and
then
it
will
report
the
results.
So
it
has
a
logger
with
various
verbosity
levels.
On
the
top,
you
can
see
the
default
verbose
of
running
a
module
called.
Oh,
my
god,
I
pass.
A
That's
a
module
that
I
published
in
a
zero
code.
Npm
test
just
does
echo
zero?
It's
really
great!
If
you
want
to
test
whether
or
not
modules
test
Suites
pass
below
you
can
see
it
being
run
with
a
verbosity
setting,
and
this
is
really
great
because
it
gives
you
more
insight
into
all
the
network
requests
that
are
going
on
if
things
aren't
working.
This
is
a
great
way
to
figure
out
why
it
also
has
a
variety
of
reporters
that
you
can
use.
A
So,
if
you're
running
a
modules
test
suite-
and
you
want
to
report
that
onto
github
or
into
some
sort
of
blog
or
something
you
can
do-
output
in
markdown
here
we
can
see
the
output
for
the
module-
oh,
my
god,
I
fail
version,
2.0
the
difference
between.
Oh
my
god-
oh
my,
oh,
my
god,
I
pass,
and
oh
my
god
I
fail
is
that,
oh,
my
god,
I
fail,
echoes
1
instead
of
0,
and
then
it
fails.
You
can
report
in
tap
as
well.
A
A
This
isn't
a
problem,
but
in
canary
in
the
goldmine,
after
a
run
against
70
of
the
top
modules,
it's
a
lot
of
data
and
that
can
actually
cause
504
errors
constantly
from
Jenkins
and
our
Jenkins
instance
running
really
slow.
So
we
actually
replaced
the
tap
reporter
with
a
X
unit
reporter
and
used
an
off-the-shelf
X
unit
parser
in
Jenkins,
and
it
just
worked
like
way
better.
A
So
Sitka
mall
is
also
a
utility
that's
available.
When
you
npm
install
canary
in
the
gold
mine
and
it
will
test
70
modules
from
the
ecosystem
and
we've
select
these
modules
from
a
number
of
different
places,
this
includes
core
ecosystem
modules,
such
as
request,
Express
body,
parser,
gracefully
fast
level,
async,
WS,
socket,
IO,
serial
part
low
and
underscore,
and
you
can't
see
it
and
it's
not
because
I
don't
like
promises,
but
Q
and
Bluebird.
This
is
a
cropping
issue.
This
was
not
intentional.
A
We
include
modules
for
testing
streams,
including
readable
streams
through
to
split
duplexer,
BL,
binary,
split,
sax
duplex,
if
I
pump
a
Phi
and
from,
and
we
also
include
modules
that
you
may
not
expect,
such
as
ones
for
testing
tooling
and
front-end
frameworks.
So
we
test
browser,
5,
vinyl,
FS,
gulp,
react,
jQuery,
node,
sass,
ember,
CLI,
commander,
hug
and,
what's
really
interesting,
is
that
we've
actually
managed
to
get
projects
to
simplify
their
workflow
in
order
to
get
into
canary
in
the
goldmine,
because
really
all
it
does
is
run
npm,
install
and
npm
tests.
A
So
if
you
have
anything
special
in
your
repo,
such
as
get
sub
module
or
something
like
that's
right,
I
get
like
sick
every
time.
I
think
of
them,
but
like
we
actually
had
node
sass
remove
some
get
sub
modules
that
they
had
in
order
to
get
into
our
CI.
So
it's
nice
about
this
is
it's
starting
to
create
a
bit
of
a
baseline
within
the
ecosystem
that
people
are
adopting
similar
patterns
for
automating
their
test
suites.
A
A
You
can't
even
think
of
all
the
ways
that
things
can
break,
because
the
universe
just
has
it
out
for
you,
but
what
we
can
do
is
we
can
rely
on
all
the
edge
cases
that
other
people
are
writing
for
their
own
code
and
we
can
know
hey
if,
in
the
latest
version
of
node,
these
tests
were
passing
and
in
the
new
version
that
we're
about
to
cut
its
breaking.
We
know
we
changed
something,
and
then
we
have
enough
information
to
do
a
deep
dive
and
find
the
breaking
difference.
A
I,
don't
know
how
many
of
you
often
use
get
god.
Why
am
I
totally
spacing
on
my
favorite
get
utility?
It's
a
binary
parse
that
allows
you
to
go
through.
Can
someone
scream
it
out
because
they
know
what
I'm
doing?
Thank
you
so
I
don't
know
if
anyone
uses
get
bisect
at
all.
It's
like
one
of
my
favorite
tools,
but
if
you
know
we're
code
was
working
and
you
know
a
place
where
code
was
broken,
you
can
use
git
bisect
to
do
a
binary,
search
against
the
entire
tree
and
finally,
offending
commits.
A
So
the
great
thing
about
a
tool
like
this
is
we
can
find
when
we
did
something
that
broke
it.
I
can
write
like
a
five
line:
shell
script
to
automate
running
the
test,
Suites
of
a
module
and
then
I
can
just
do
git,
bisect
good
and
the
good
commit
give
bisect
bad
and
the
bad
commit
get
bisect
run
in
the
script,
and
it
will,
in
you
know,
as
long
as
it
takes
to
run
the
test.
A
A
So,
if
you're
making
a
change
to
streams-
and
it
may
not
be
some
ver
major
but
we're
kind
of,
like
oh
streams-
are
kind
of
fragile,
like
we'll,
actually
run
it
through
the
test
suite
and
make
sure
that
it's
working
you'll
see
down
here
some
of
the
operating
systems
that
we
run
the
test
suite
on
it's
not
as
full
of
a
sweet
as
the
node
CI
is
run
on,
but
we're
still
running
on
debian,
two
versions
of
fedora
OSX,
a
couple
versions
of
Ubuntu.
So
we
have
a
decent
amount
of
spread
and
is
really
interesting.
A
Some
of
the
errors
that
we
find,
because
what
may
work
on
bsd
may
not
work
on
fedora
or
may
not
work
on
a
bun.
We
actually
had
an
issue
a
while
ago
with
with
real
path
where
the
real
path
implementation
in
bsd
actually
didn't
include
limits
by
default,
so
it
was
actually
causing
some
like
really
weird
errors,
but
it
was
like
only
in
the
stdlib.h
d.
So
if
we
weren't
testing
all
of
these,
we
wouldn't
have
seen
it.
That's
really
interesting.
A
You
know
to
the
force
to
dig
into
kernel
code,
but
how
does
it
work-
and
you
know
that's-
that's
a
good
question-
how
how
do
we
do
this?
It's
actually
not
as
complicated
as
you
might
think.
We
actually
just
do
a
lot
of
wrapping
so
NPM
view
we
wrap
that
we
use
NPM
view
you
do
NPM
view
and
then
the
name
of
a
module,
and
it
will
give
you
back
a
JSON
file
with
all
the
information
about
that
module.
A
What
the
latest
tarball
is
what
the
repo
is,
who
the
author's
name
is
that's
part
of,
like
essentially
M
PM's
lifecycle.
So
if
you
want
to
get
information
about
a
module,
you
can
use
that
command.
Npm
pack,
we
wrap
that
NPM
package.
You
say
NPM
pack
in
a
module
name,
it
will
actually
just
give
you
the
tarball
for
that
module.
A
If
you
do
NPM
pack
and
a
link
to
a
git
repo,
it
will
give
you
the
tarball
from
github,
which
may
have
more
data
in
it
than
you
will
in
just
the
modules
on
NPM
so
actually
in
canary
in
the
goldmine,
we're
generally
grabbing
tarballs
from
github
rather
than
from
NPM,
because
not
everyone
publishes
with
all
their
tests
and
everything
npm
install'.
We
wrap
that
you
can
imagine,
we
want
to
grab
the
module,
we
have
the
module
it's
on
tarde,
we
run
npm
install
and
then
it's
you
know,
ready
to
be
run
npm
test.
A
A
But
yeah
you
may
be
thinking
to
yourself.
Why?
Oh,
why?
Oh,
why
are
you
using
a
child
processes
constantly
to
call
it
to
a
CLI?
Is
there
not
an
api
you
could
be
using
and
it
turns
out
that
npm
already
does
all
of
this
stuff
and
every
build
that
we
do
in
CI
already
comes
with
NPM
installed
as
a
binary
that
we
can
call
too,
and
another
thing
that's
really
nice
is
that
the
NPM
CLI
is
is
managed
by
semver
and
it's
assembler
that
we
actually
as
a
project,
have
somewhat
of
a
control
on.
A
If
you
actually
go
to
the
NPM
website
and
look
up
the
documentation
to
try
to
find
documentation
about
whether
or
not
you
can
use
NPM
as
an
API,
you
won't
find
it
and
I
may
be
incorrect
in
this,
but
the
last
time,
I
checked
MPM
does
not
officially
support
NPM
itself
being
required
and
being
used
programmatically.
So
part
of
the
reason
why
we're
wrapping
everything
in
child
process
is
because
NPM
is
supported
as
a
CEO
like
you,
so
we're
guaranteed
to
have
consistent
support
as
long
as
we
do
it
that
way.
A
So
when
we
have
it
all
wrapped
we're
taking
all
the
STD
out
messages,
all
the
STD
error
messages,
we're
managing
them
were
piping
them
around
we're
keeping
track
of
that
we're
keeping
track
of
which
modules
past,
which
modules
failed.
We
have
a
lookup
table
that
also
includes
which
modules
are
flaky.
What
systems
they're
flaky
on?
A
A
So
it
turns
out
that
there
was
an
API
that
was
deprecated
in
2010
but
was
never
actually
deprecated.
They
forgot
it
I
guess
and
then
no
one
ever
really
checked,
but
it
was
the
string,
an
interface
on
FS
read
and
it
just
seemed
like
a
general
thing
that
we
should
do
is
hey
you
know,
maybe
we
should
actually
deprecated
that
API
and
the
deprecation
process.
The
first
thing
we
do
is
emit
warning
messages
because
they
are
less
detrimental
to
the
stack
than
just
making
something
not
useful
anymore,
and
we
could
see
here.
A
This
was
essentially
the
code
and
you
can't
tell
too
much
but
there's
a
require
here
to
an
internal
util
called
print
deprecation
message,
and
then
we,
when
that
API
is
used
in
the
thing
that's
passed
as
a
string,
we
print
the
deprecation.
It's
you
know
pretty
pretty
straightforward.
The
print
deprecation
method
has
the
ability
to
know
whether
it's
been
called
or
not.
So
it's
not
called
multiple
times
and
there's
also
hooks
now
into
the
node
lifecycle.
You
can
run
node
with
I.
Think
it's
like
step.
A
We're
guaranteed
that,
like
those
warning
messages,
kind
of
hook
into
these
lifecycle
events,
so
we
weren't
really
expecting
much.
You
know
they
it
got
reviewed,
it
got
landed.
This
was
you
know,
all
pretty
rode
until
it
broke
NPM
a
master
so
canary
in
the
gold
mine,
I
went
to
run
it
one
day
and,
and
it
just
didn't
one
of
the
first
steps
we
do
is
actually
NPM
install
canary
in
the
gold
mine
before
we
run
canary
in
the
gold
mine
and
that
didn't
work.
And
so
you
know,
I
ran
the
test.
A
Suite
I
went
and
did
something
for
30
minutes
and
I
went
to
go
check
back
and
everything
was
read
and
I
was
scared.
So
you
know
the
commit
broke,
NPM
and
master
and
to
reproduce
simply
run
npm
install.
The
good
news
was
that
we
didn't
break
npm
sub
stack,
npm
visit
up
or
npm
Xmas,
which
are
all
awesome,
Easter
eggs,
but
it's
probably
a
good
idea
not
to
have
a
broken
NPM
on
master.
So
why
did
it
break?
And
this
was
really
interesting-
it
actually
have
to
do
with
the
way
in
which
graceful
FS
works.
A
Okay,
I
see
a
show
of
hands
of
how
many
people
know
what
graceful
FS
is
alright
cool,
so
I'll
spend
a
little
bit
more
time
on
that
graceful.
Fs
is
a
module
that
was
written
by
Isaacs
and
it's
a
wrapper
around
the
FS
module
that
just
is
more
graceful
ways
in
which
the
FS
module
will
throw
or
cause
problems.
Graceful
FS
will
just
be
like.
Okay,
that's
cool,
just
keep
doing
it.
I
know,
there's
an
error,
and
it
just
makes
things
a
lot.
A
Less
painful
can
I
see
a
show
of
hands
how
many
people
have
used
gulp
before
so
a
few
more
so
gulp
is
built
on
top
of
utility
called
vinyl
FS
vinyl
FS
is
an
abstraction
for
doing
stream
based
stuff
over
the
file
system.
Like
pretty
much
every
time
you
do
like
gulp
source
pipe,
that's
just
an
abstraction
over
vinyl
of
s,
and
so
vinyl
FS
under
the
hood
is
actually
using
graceful
FS
for
all
of
its
calls.
A
So
you
can
maybe
get
an
idea
of
where
this
is
going,
but
for
now
we're
focusing
on
NPM
and
it
turned
out
that
NPM
had
a
module
called
command
shim
inside
and
inside
of
command
sham.
They
were
following
an
old
version
of
graceful
efest
version
3
in
graceful
official
version
3.
Unfortunately,
what
was
happening
was
graceful.
Fest
was
spin,
it
was
using
the
VM
module.
It
was
using
an
undocumented
feature
which
is
processed
binding
to
get
the
source
code
of
FS.
A
It
was
then
executing
that
source
code
inside
a
VM
and
then
doing
all
sorts
of
little
hooks
into
it
to
be
more
graceful
and
then
exposing
that
version
that
was
in
the
VM
to
user
land,
and
so
what
this
allowed
it
to
do
is
it
allowed
it
to
monkey
patch
FS
without
monkey
monkey
patching
over
the
FS
that
node
would
use
internally?
This
is
important
to
do
because,
if
you're
going
to
monkey
patch
something
like
that,
you
could
end
up
breaking
all
of
nodes,
so
this
kind
of
contained
it.
A
The
unexpected
problem
was
that
when
we
included
an
internal
module
which
anything
in
internal
is
actually
not
able
to
be
required
from
userland
without
a
flag,
everything
explodes
because
it
can't
find
it-
and
this
was
actually
something
that
was
was
a
problem
six
months
prior
to
this,
and
they
actually
rewrote
a
new
version
of
graceful,
FS
graceful
FS
for
that
fixed
this
around
the
time
that
that
this
hit
us
the
first
time
and
most
of
the
things
in
NPM
are
updated,
but
it
turned
out.
You
know
this.
A
One
package
had
this
dependency
that
hadn't
been
caught
yet
so
a
short
term
solution
was
made
and
essentially
what
we
did
was
we
went
and
grabbed
what
was
in
internal.
You
tool,
print
deprecation
method
and
he's
plopped
it
right
in
there
as
a
temporary
solution
for
for
v5,
and
the
idea
was,
is
we
were
gonna
land
this
in
now
and
then
for
v7
as
a
major
change,
we're
going
to
revert
it?
A
This
allowed
us
to
move
forward,
or
they
actually
deprecating
it
deprecating
in
a
way
where
we
warned
it
to
people
you
can
see
down
here
we
have
a
print
deprecation
message
and
that's
great
we're
able
to
do
it,
and
so
there
was
no
way
that
we
were
able
to
know
right
away,
that
a
warning
would
break
the
world
and
what
was
really
great
is
because
we
had
canary
in
the
goldmine
to
catch
this.
We
were
with
the
catch
that
NPM
was
broken.
A
If
we
had
not
caught
that,
if
we
had
not
done
enough
to
diligence,
it
would
have
been
possible
that
we
could
have
cut
a
release
with
a
broken
NPM
that
would
have
been
miserable.
Try
like
trying
to
get
people
to
install
it
in
like
once.
You
release
a
version
of
software.
You
never
know
how
many
people
are
gonna,
install
it
forever.
It's
like
it's
the
weirdest
thing
people
will
show
up
me
like
I'm
running
node,
5,
7,
3
and
I
installed
it
yesterday
and
you're
like.
A
Where
did
you
find
that
and
I
don't
mean
that
as
like
any
like
insults
or
attack
on
the
person?
It's
more
just
like
literally,
where
did
you
find
it
I'm
very
interested
to
find
out
because
I
don't
know,
but
this
happens.
So
when
you
really
software,
when
you
release
broken
software,
that's
in
the
ecosystem.
That's
gonna,
break
lots
of
people
and
confuse
lots
of
people.
So
it's
really
good
to
catch
that.
A
So
we
ended
up
the
way
we
solve
that
afterwards,
as
we
also
wrote
a
new
unit
tests
for
NPM
that
was
able
to
test
whether
or
not
npm
install'
worked,
and
it
was
just
a
no
op,
and
so
now,
every
time
we
run
our
test
suite,
it
does
a
little
no
op
npm
install
and
if
we
have
our
break
npm
again,
we'll
know-
and
you
know
that's
the
best
way
to
handle
it.
When
you
break
software,
cuz
you're
gonna
break
software,
it
just
don't
break
it
twice.
So
dear
diary,
today
we
broke
body
parser.
A
How
many
people
know
body
parser,
okay,
so
for
how
many
people
know
express
so
body
parser
is
what's
used
in
express
to
parse
bodies.
So
this
is
extremely
hot
code
and
that's
why
there's
fire
all
over
the
screen,
but
so
body
parser,
is
running,
express
and
some
examples
of
the
scale
of
that
is
kraken
is
built
on
top
of
express
over
a
paypal,
a
whole
bunch
of
PayPal's
infrastructure
is
running
on
that
strong
loops
loopback
utilities
all
built
on
top
of
express.
So
it's
breaking
body
parser
is
going
to
break
a
lot
of
the
internet.
A
So
how
do
we
break
it
in
a
completely
unexpected
and
beautiful
way?
Query
string,
parse
also
again,
code.
That's
probably
used
a
lot
very
hot
code:
lots
of
query
strings
being
parsed.
There
was
logic
inside
of
query
string
that
was
deemed
unnecessary.
Essentially,
we
were
calling
string,
dot,
split
on
a
string
of
a
query
string
and
it
was
creating
a
large
array
and
then
when,
if
someone
gave
max
keys
as
a
value,
we
were
comparing
the
length
of
that
of
that
array
to
the
max
keys
and
then
dumping
a
bunch
of
memory.
A
Just
shortening
the
array-
and
this
creates
a
whole
bunch
of
unnecessary
garbage
and
especially
in
really
really
hot
code,
such
as
query,
string
parks,
it's
being
run
in
all
this
stuff
that
can
actually
have
huge
performance
degradation
or
create
all
sorts
of
extra.
So
it
was
a
very,
very
minimal.
Change,
went
through
really
quickly
as
a
patch,
and
all
it
did
was
pass
max
key,
as
the
second
argument
to
split,
because
it
turns
out
split,
actually
has
an
argument.
A
A
second
argument
that
you
can
do
this
so
yeah,
no
more
garbage
things
are
faster,
but
one
thing
we
didn't
think
about
was
infinity
and
whenever
you're
dealing
with
infinity,
your
life
is
going
to
be
difficult.
But
before
we
did,
this
change,
query
string,
parse,
parsing,
a
string
with
one
query
string
in
it
with
a
max
keys
set
to
infinity,
would
give
back
a
length
of
one
as
one
would
expect.
A
After
the
change
it
gave
back
a
length
of
zero,
which
is
not
what
you
would
expect.
Why
did
that
happen?
Well,
it
turns
out
that
the
second
argument
to
split
is
expecting
an
integer.
No
I'll
ignore
the
fact
that
integers
don't
exist
in
JavaScript,
but
it
means
that
in
the
VM
it's
inferred
as
an
integer
when
infinity
is
inferred
as
an
integer,
it's
inferred
as
zero,
because
mathematically
that's
correct
I
would
argue
logically
infinity
as
one,
but
we
don't
need
to
have
that
argument.
This
is
the
spec.
This
is
what
we
live
by.
A
These
are
the
rules
of
our
universe.
So
when
max
Keys
was
put
there
as
the
argument
to
split
it
was
always
passing
zero.
Now
in
node
core,
we
didn't
have
a
test
to
test
for
infinity,
but
body
parser
had
that
extra
edge
case
could
because
Doug
Wilson
is
amazing
and
thinks
of
everything,
and
so
it
was
actually
pretty
straightforward.
Once
we
saw
it
was
broken,
we
could
go
and
we
just
wrote
a
test
and
using
the
the
vanilla
assert
and
then
the
change
to
fix
it
was
pretty
straightforward.
A
It
was
literally
just
checking
for
infinity,
but
sometimes
a
patch
is
much
more
disruptive
than
it
seems
at
first,
and
this
is
why
these
kinds
of
tools
are
really
important.
We
don't
know
everything,
we
don't
know
everything
about
these
systems
and
all
the
weird
ways
that
they
interact
and
there's
no
way
that
we
can.
The
only
thing
that
we
can
do
is
create
systems
in
which
we
can
minimize
the
damage
dear
diary.
A
So
remember
how
I
was
talking
about
how
to
node
7
we
were
gonna
revert
that
change
that
broke,
trace,
Follette,
that's
well,
we
did,
or
we
tried
to-
and
you
can
see
the
change
here.
It
was
literally
just
grabbing
all
that
code
that
we
added
before
and
adding
back
that
internal
module
seems
pretty
painless.
We
gave
the
ecosystem
a
bunch
of
time.
It
was
no
longer
breaking
NPM.
A
We
thought
everything
was
going
to
be
fine,
and
then
we
ran
canary
in
the
gold
mine
and
it
turned
out
a
lot
of
stuff
broke,
so
we
ended
up
having
Chalker,
whose
member
of
node
4.
He
does
really
really
amazing
work
right
now
on
ecosystem
analysis.
So
he
has
these
databases
of
are
like
I,
think
they're,
just
like
giant
archives
of,
like
all
the
strings
of
all
the
modules
of
all
the
code
and
all
the
modules,
and
he
has
these
regular
expressions
that
go
through
and
can
find
like
all
the
instances
of
requiring
specific
modules.
A
So
if
we
wanted
to
know
in
the
entire
ecosystem,
how
many
modules
are
there
that
are
actually
still
using
graceful
fs3,
because
we
knew
that
if
we
landed
this
change,
we
would
just
break
all
of
those
like
not
even
just
a
little
bit.
Just
all
that
code
would
stop
working
and
it
turned
out
that
still
5%
of
NPM
5%
of
the
modules
on
the
planet
still
use
this
code.
So
this
is
bad.
A
We
started
using
internal
modules
for
various
things,
and
one
of
the
things
we
wanted
to
use
in
NFS
4
was
for
abstracting
errors,
as
it
is
right
now,
error
messages,
our
assembler
major
changes.
We
want
to
make
it
so
that
there's
error
codes
that
we
can
give
instead
and
that
the
set
that
the
message
would
be
in
a
lookup
table
based
on
the
error
code
and
the
specific
message
that's
being
thrown.
This
would
allow
for
internationalized
error
messages.
It
would
allow
us
to
modify
error
messages
without
it
being
cember
major.
A
This
is
something
that
James
Snell
is
is
moving
forward
with
right
now,
but
this
blocked
that
work.
If
we
can't
even
just
land
this
message
that
admits
a
warning
because
we're
gonna
break
5%
of
the
ecosystem.
How
are
we
ever
going
to
get
to
that
code?
And
there
are
a
handful
of
other
efforts
that
all
got
broke
jammed
on
SF's,
so
we
dug
in
more
and
it
turns
out
that
we
were
able
to
get
the
list
down
quite
a
bit.
A
You
can
see
the
dates
here
and
the
number
of
modules
that
between
you
know,
May,
20th
and
June
6.
You
know
it's.
It's
almost
half
the
size.
We
got
it
down
to
about
60%
of
the
original
by
sending
out
just
tons
of
pull
requests
to
modules
in
the
ecosystem,
but
there
was
one
module
that
wasn't
updated
and
that
was
gulp
three
and
as
many
of
you
had
your
hands
raised
because
you've
used
golf
before
you
know
how
proliferated
that
is
in
our
ecosystem.
A
So
under
the
hood
golf
3
is
using
vinyl
FS
zero
point,
five
point:
ax
vinyl,
FS,
zero
point:
five
point:
X
is
using
graceful,
FS
version
three
because
of
how
complicated
the
system
of
gulp
is.
The
maintainer
zip
felt
completely
uncomfortable
just
arbitrarily
bumping.
The
version
of
vinyl
effects
because
they
couldn't
bump
vinyl
FS.
We
were
nigh
unable
to
bump
graceful
FS.
A
We
even
tried
to
bump
graceful
FS
in
a
way
that,
like
to
bump
graceful
FS
in
vinyl
FS,
but
it
still
was
something
that
gulp
3
didn't
have
the
kind
of
test
suite
that
would
allow
us
to
do
it
in
in
a
safe
way.
So
what
ended
up
happening
there
was.
We
have
to
try
to
figure
out.
What
can
we
fix?
Vinyl
effects,
oh
yeah,
and
so
28%
of
the
modules
that
were
left
and
directly
and
42%
of
the
ones
indirectly
that
were
broken
were
all
related
to
gulp.
A
To
avoid
broke
breaking
the
Royal
I
did
a
little
reggae
and
doing
redexes
now
are
called
reggae's
due
to
a
spelling
error
that
I
made
accidentally
once
isaacs
really
enjoyed
it
and
so
yeah
any
time
you
do
a
regex,
that's
doing
a
reggae,
and
basically,
what
we
did
was
you're
gonna
recognize
this
code.
We
took
that
chunk
of
code
that
we
had
just
hard-coded
into
node
before
we
did
a
little
read
and
we
found
any
time
where
we
were
requiring
the
internal
module.
A
So
it
was
really
important
for
us
to
try
to
land
this
in
seven,
because
it's
experimental
until
Isaac
came
up
with
an
extremely
elegant
solution.
He
updated
graceful,
FS
3
and
we
were
able
to
land
it.
What
he
what
he
landed
was
this
new
module.
He
created
called
natives
and
natives
is
a
module
that
allows
him
to
require
in
and
run
the
code
in
a
VM
that
explicitly
find
the
x
with
its
internal
modules
and
flip
the
flag,
that's
necessary
to,
in
turn
to
grab
internal
modules,
but
only
in
the
VM.
A
It's
just
like
all
this,
like
craziness,
but
with
all
those
things
that
are
moving
around,
he
was
able
to
get
it
set
up
in
a
way
where
things
didn't
break
and
the
universe
didn't
explode.
This
is
an
example
of
how
you
can
use
it.
You
save
our
natives
equals
require
natives
FS
code,
equals
native
source
FS,
and
that
will
give
you
the
source
of
FS,
and
you
can
you
can
assert
and
require,
and
it
allows
him
to
to
do
what
was
trying
to
be
done
before,
but
one
thing
I
will
mention.
A
If
you
take
a
look
at
the
note,
I
feel
compelled
to
give
you
a
word
of
warning.
If
you
were
considering
using
this
module,
it
lets
you
do
some
creative
things
with
JavaScript
code
and
note.
There
are
some
things
here
that
are
basically
a
recipe
for
memory.
Leaks
are
the
very
least
being
broken
with
each
new
release
of
node,
since
none
of
these
API
surfaces
are
technically
supported
by
the
managing
the
project.
A
So
there's
no
need
to
do
any
sort
of
requiring
of
internal
modules,
so
you
know
like
we're,
willing
to
listen
and
Bend
on
both
sides
and
find
a
place
that
just
you
know,
makes
things
easier
for
everyone
so
dear
diary,
even
though
we
broke
a
lot
of
stuff,
most
people
didn't
notice
and
that's
that's
the
reason
to
celebrate
in
my
mind.
So
thank
you
very
much.
This
is
a
picture
is
wrongly
Pro
card
playing
a
flute.