►
Description
To learn more about critical open source JavaScript projects like Appium, Dojo, jQuery, Node.js, and webpack, and 27 more checkout The OpenJS Foundation: https://openjsf.org/
Debugging Your Way Through a Node.js Upgrade - Bethany Griggs, Red Hat
JW Grand Ballroom 1
Speakers: Bethany Griggs
New major versions of Node.js are often anticipated for all the new features and capabilities they will bring. Though, for many engineering teams upgrading to a new major version can be a daunting process. It’s not always easy to associate the change of behaviour in your application with an entry in the changelog. And it’s not always obvious if or how you need to amend your code to successfully upgrade. In this talk, I’ll share my experiences of helping teams upgrade to new Node.js versions, with some practical shortcuts and tips I’ve learned along the way.
A
Probably
good
to
get
started
now
so
hi
everyone,
my
name
is
bethany
griggs
and
I'm
excited
to
be
back
here
at
openjs
world.
Actually,
my
first
ever
conference
was
here
in
austin
about
six
years
ago,
so
it's
good
to
be
back,
and
today,
I'm
here
to
talk
to
you
about
the
fun
of
debugging
node.js
upgrades.
A
First,
a
quick
bit
about
me,
cyano's
senior
software
engineer
at
red
hat
in
the
node.js
runtime
team,
which
means
I
get
to
spend
a
good
portion
of
my
time,
helping
out
in
node
project
helping
to
maintain
the
runtime,
but
the
rest
of
my
time.
I
get
to
work
with
teams
at
red
hat
that
are
using
dojs
and
sharing
the
expertise
that
we
learn
from
working
within
the
project
itself.
A
I
am
a
no
tierc
and
particularly
active
in
a
release
working
group,
and
this
means
I
spend
a
lot
of
my
time
helping
to
prepare
releases
of
node
so
yeah.
So
a
lot
of
my
time
helping
to
provide
releases
shuffling
the
major
releases
out
in
case
you
missed
it.
The
big
news
from
the
note
space
is
that
node.js
18
was
released
not
too
long
ago.
Now
on
19th
of
april,
and
actually
it
was
one
of
our
more
featureful
releases.
Typically,
our
major
releases
happen
to
be
just
the
series
of
breaking
changes.
A
So
new
release,
shiny
new
features,
some
of
the
key
highlights
in
the
node
18
release
included
the
google
chrome
upgrade
and
it's
through
a
v8
engine
upgrade
sorry
and
it's
through
the
google
chrome
v8
upgrade
that
we
pick
up
all
the
new
javascript
syntax
and
features,
and
things
like
that.
I
believe
we
got
some
additional
like
array
methods
or
apis
through
that
upgrade.
A
The
other
big
news
was
a
bunch
of
new
globally
available
browser-compatible
apis.
So
I'm
sure,
if
you
went
to
ethan's
talk,
you
heard
about
fetch
coming
to
node.
That
was
a
very
much
anticipated.
Api
is
great
to
have
an
experimental
version
of
it
available,
and
similarly
we
got
the
web
streams
apis
again,
a
similar
vein
and
also
the
test
runner.
So
as
of
node
18,
there's
a
very
minimal
test.
A
Runner
shipped
with
node,
it's
experimental
a
lot
of
hard
work
done
by
colin
from
the
tse
there,
so
lots
of
shiny
new
features
to
get
your
hands
on.
I
do
believe
my
colleague
michael
will
be
going
through
some
of
them
in
more
detail
after
this
talk
so
stick
around,
but
that's
the
positive
side
of
a
new
release,
but
actually
the
reality
is
upgrading
to
a
new
node
version
takes
time
effort
money,
not
every
business
out
there
is,
you
know,
deploying
several
times
a
day.
A
The
first
thing
to
appreciate
is
node.js
aims
to
follow
the
semantic
versioning
standard.
I'm
sure
many
fakes
are
familiar,
but
the
first
number
is
incremented
with
a
breaking
change.
The
second
number
is
incremented
when
a
feature
is
added
in
a
backwards,
compatible
manner
and
the
third
digit
is
incremented
folder
patches
and
changes
that
neither
are
breaking
or
adding
functionality.
A
So
we
try
to
adhere
to
this
semantic
versioning
standard,
but
there's
a
bunch
of
caveats
that
come
with
that.
First
of
all,
who
gets
to
decide?
What's
a
bug
fix
or
a
breaking
change?
What
we've
found
over
the
years
of
working
in
the
node
project
is
a
lot
of
applications
are
actually
relying
on
buggy
behavior.
A
So,
even
if
it
is
a
bug,
we
may
need
to
consider
that
a
breaking
change.
So
it's
definitely
a
discussion
and
semantic
version.
Is
this
versioning
as
a
standard?
We
try
to
deity
and
guide
our
decisions,
but
sometimes
we
may
need
to
elevate
a
bug
fix
to
a
breaking
change
because
it's
going
to
break
just
so
many
applications
and
we
want
to
be
able
to
give
our
consumers
and
users
the
time
to
upgrade
when
that
breakage
comes
along.
A
The
other
exception
is
for
security
releases
and
security
fixes.
So
we
have
a
policy
in
the
node
project
that,
if
there's
a
critical
vulnerability
or
security
issue,
that
requires
a
breaking
change
to
fix
it.
We
can
land
that
in
an
existing
release
line
so
that
when
the
project
maintains
multiple
release
lines
of
node,
we
actually
do
land
breaking
security
changes
in
those
we
do.
We
are
aware
this
can
be
disruptive,
so
we
often
do
try
to
like
help
you
out
and
supply,
maybe
a
reverb
flag.
So
you
can
work.
A
Revert
that
change
and
work
around
the
behavior
until
you
have
time
to
patch
and
there's
also
unexpected
side
effects.
So
authors
pr
authors,
commit
authors,
do
their
best
effort
of
trying
to
determine
the
impact
of
the
change
they're
contributing
to
the
project,
but
sometimes
there's
unexpected
side
effects
that
no
one
anticipated
and
it's
just
exposed
a
part
of
you
know.
Node,
we
didn't
think
would
be
affected
by
that
particular
change.
So
all
a
bunch
of
caveats
of
why
you
may
hit
breaking
changes
in
like
minor
and
patch
releases
too,
but
we
try
to
avoid
it.
A
We
do
our
best
effort
above
that
node
aims
to
have
a
predictable
release
schedule
two
major
releases
per
year.
This
is
again
with
consumers
in
mind.
We
want
to
have
a
predictable
schedule
so
that
they
can
plan
their
upgrades
accordingly,
and
we
also
have
this
concept
of
current
and
long
term
support,
so
even
numbered
release
lines
are
granted
long-term
support
status,
odd
numbers
once
or
not.
This
is
why,
in
the
chart,
you
can
see
like
node
19
is
only
supported
for
a
short
window.
A
Generally,
our
distinction
is
use
cut
the
current
release
line.
If
you
want
to
get
your
hands
on
the
latest
and
greatest
features,
whereas
long-term
support
releases
are
more
aimed
at
you
know
the
enterprise
or
the
production
use
case,
where
you
want
stability
and
guarantee
over
time,
and
that's
why
you
see
a
lot
of
enterprises
saying
they
stick
to
the
long
term
support
release
lines
only.
They
never
got
the
odd
numbered
versions.
A
But
that
means
for
most
companies
when
it
does
come
to
upgrading-
and
you
are
sticking
to
just
the
yell
test
lines.
You
actually
have
to
make
a
double
jump
when
you
go
to
upgrade.
This
means
you're
picking
up
the
braking
changes
from
two
versions,
so
you
need
to
make
much
larger
jump
and
this
can
make
it
much
harder
to
isolate
the
particular
change
that
has
caused
your
issue,
and
this
is
all
relevant,
because
the
first
port
of
call,
when
trying
to
upgrade
a
node
version,
tends
to
be
the
change
log.
A
So
when
upgrading
to
a
new
major
version,
you
want
to
look
at
the
zero
zero
1500
change
log
for
that
release,
but
actually,
if
you're,
upgrading
from
14
to
16
you'd,
also
need
to
up
review
the
change
log
for
1500
and
1600.
So
you've
got
two
sets
of
breaking
changes.
You
need
to
accommodate
and
review
and
going
on
more
so
with
our
change
logs,
the
node
project
does
aim
to
identify
commits,
so
you
can
get
idea
of
what
area
of
runtime
they
touch.
A
So
this
is
great
when
you
have
an
issue
that
has
known
impact,
known
errors
and
no
workarounds,
and
one
I
think
we
did
really
well
was
the
open,
ssl
3.0
upgrade
which
came
in
node.js
17..
We
knew
this
would
be
a
breaking
change
and
have
ecosystem
impact.
So
what
we
did
is
we
called
out
notable
changes.
A
A
So
it's
great,
it's
really
not
always
the
smooth,
and
this
is
where
I
want
to
talk
through
one
of
my
recent
experiences
at
red
hat
and
so
at
the
start
of
the
year.
I
was
tasked
with
helping
a
team
update
their
javascript
client
for
that
project
up
to
node
16.,
and
this
team
actually
was
a
predominantly
java
team,
so
they
didn't
necessarily
have
any
node.js
expertise
within
that
group.
They
just
had
this
javascript
client
to
maintain
and
what
the
product
was.
It
was.
A
It's
called
infinispan,
it's
like
an
open
source
data
grid,
I
think
kind
of
like
a
redis
equivalent
and
they
needed
sport
node
16,
so
they
reached
out
to
our
team
to
ask
for
some
help.
This
is
where
I'd
like
to
share
some
of
the
techniques
I
used
with
increasing
complexity,
to
try
and
figure
out
what
was
happening
so
step
one
with
some
very,
very
typical
debugging
techniques,
so
run
it
with
no
14.
It
passes
16,
it
hangs
node
15,
it
hangs.
A
A
So,
as
first
steps
are
pretty
reasonable,
I
found
the
exact
tester
was
failing
and
I
narrowed
it
down
to
the
window
between
node,
14
and
15.,
and
just
to
give
some
background
on
what
this
test
was
doing,
because
it's
relevant
slightly
later
in
the
talk
is
it
sets
up
two
infinitive
band
clients
a
and
b
expects
to
be
able
to
persist
and
reach
data
to
both.
It
then
destroys
one
of
the
clients
attempts
to
persist
data
to
the
client
that
it
destroyed.
A
So
again,
once
I
found
a
test
case,
I
did
some
very
I'm
sure,
familiar
techniques
to
what
people
use.
You
know
very,
very
intense.
It
was
good
from
this
point.
I
was
able
to
at
least
get
to
the
point
of
saying
this
is
roughly
where
the
test
is
hanging,
so
it
was
a
great
step
forward.
Then
I
figured
I
need
to
try
something
a
bit
more
intentional
to
debug
this
so
pulled
up.
The
chrome
inspector
and
you
know,
run
the
test.
A
Node
inspect
and
with
a
chrome,
debugger,
try
to
step
through
it
and
see
what
was
going
on
with
my
breakpoints
and
what
I
found
is.
I
was
just
stepping
through
the
ticks
in
the
event
loop,
I'm
just
waiting
for
something
to
happen,
never
happened
so
actually
going
through
these
steps.
It
wasn't
obvious
to
me
what
was
actually
going
wrong,
because
all
I
was
doing
was
waiting
for
something
to
happen.
That
never
happened.
A
So
I
had
to
take
a
step
back
and
really
try
and
think
about.
How
can
I
approach
this
next,
like
what
are
my
next
steps,
and
this
is
where
I
resorted
to
get
bisect
if
you're
not
familiar
with
get
bisect,
it's
a
command
that
uses
a
binary
search
algorithm
to
find
which
commit
in
your
history
introduced
a
problem
or
a
bug,
and
so
in
this
case,
what
I
had
to
do
to
use
it
was
check
out
the
main
branch
of
node
identify
a
good
and
a
bad
commit.
I
know
it
was
within
this
window.
A
A
Can
I
say
demo
I
pre-recorded
it
so
yeah,
oh
yep,
so
to
start
get
bisect.
You
call
get
bisect
start
that
just
initializes
the
bisect
you
supply
the
good
commit.
In
this
case
it
was
the
node
15
release
commit
and
you
supply
bad
commit.
I
supplied
very
early
bad,
commit
the
node
13
bad,
commit,
I
believe,
and
you
can
see.
I
had
like
1
700
odd
revisions
to
test.
A
And
what
you
can
do
at
each
step
is
run
your
tests
and
run
your
build.
What
I've
done
is
I've
just
like
simulated
this,
because
I'm
sure
you
don't
want
to
watch
me
build
node
like
20
times
over
in
this
talk
but
yeah
I
build
node
with
the
mate
j32
and
then
run
the
test,
and
then,
when
the
test
hangs,
I
just
apply
good
bad
good
bad.
As,
as
I
can
start
to
find
a
problematic
commit,
I
believe
it's
still
going
and
what
you
can
do
is
automate
this
into
a
script.
A
A
A
This
is
really
difficult
from
where
I
am
okay
right,
so
I
found
a
problematic
commit
great.
So
what
you
could
do
here
is
look
at
the
file.
Def
look
at
the
changes,
try
and
figure
out
what's
going
wrong,
but
for
most
folks,
actually
you
know
particularly
this
team.
If
this
team
was
doing
that
they
don't
have
you
know
the
low
level
context
of
node
runtime,
like
digging
into
node
source
code
when
you're
just
trying
to
debug
an
upgrade
issue,
isn't
isn't
easy
for
everyone.
A
So
what
this
does
is
it
enables
a
low
level
debug
logs
from
node
runtime
and
you
just
supply
node
debug
and
the
subsystem,
and
these
are
the
subsystems
I
mentioned
earlier
roughly
from
the
change
log.
They
roughly
equate
to
each
other,
so
you
can
specify
http
net
stream
fs
and
you
get
that
low
level.
Log
data
from
the
runtime
itself:
you
can
supply
like
enable
wall
with
asterisk,
but
that
will
have
timer
output
and
it
just
pollutes
it.
So
it's
good
that
I'd
already
figured
out.
A
But
what
I
did
find
is
the
node
14
was
emitting
an
error
that
wasn't
being
admitted
in
note
16,
so
they
at
least
managed
to
realize,
like
an
error
should
have
been
emitted,
but
no
longer
is
so
it's
a
step
closer
and,
as
you
can
see
the
command
to
run
it.
I
just
set
the
environment
variable
and
then
the
path
to
my
file.
I
want
to
run
so
at
this
point.
I
was
spent
a
few
days
on
this
and
I
was
at
this
point
I
was
like.
A
A
So
at
this
point,
I'd
step
through
the
test
so
many
times
I
was
so
familiar
with
what
I
was
doing:
I'd
log,
the
low
level
output.
It
was
only
at
this
point.
I
was
able
to
do
this
because
I
actually
understood
what
was
going
on,
and
what
I
could
understand
is
that
what
the
test
was
simulating
was
the
creation
of
the
server
the
creation
of
the
socket.
A
So
actually
I
was
able
to.
This
is
a
shortened
version
of
the
full
minimal
reproduce
I
had
and
you
can
see
it
was
actually
the
socket
right
at
the
bottom.
There,
which
happens
after
the
socket's
been
destroyed,
did
not
omit
an
error
in
node
16.
in
node
14.
It
did
in
node
16
it
didn't.
I
was
like
this
is
strange.
So
refer
back
to
the
docs,
I
now
had
a
minimal
reproduce.
A
So
that's
a
whole
bunch
of
techniques
that
I
used
like
the
first
was
like
to
isolate
the
test
failure
and
isolate
a
specific
version
that
introduced
a
change
for
isolating
the
version,
introduce
a
change.
I
tend
to
actually
do
that
manually
just
with
like
nvm,
so
just
nvm,
the
versions
myself
to
see
when
it
was
introduced,
then
reviewed
a
change
log
for
that
version,
guided
by
the
subsystem.
So
using
you
know,
looking
at
the
error
trying
to
guess
roughly
is
it
related
to
streams?
A
Is
it
related
to
http
and
reviewing
that
field
to
the
subset,
then
try,
you
know
all
the
traditional
debugging
techniques
like
console
logs,
the
chrome
inspector
in
this
case
that
didn't
solve
it.
For
me,
I
did
resort
to
a
get
bisect
of
the
node
runtime
and
you
may
say
why
didn't
you
go
to
that
straightaway?
First,
that
can
take
a
lot
of
time
to
run.
A
A
This
is
my
code
you're
using
just
node,
it's
much
easier
to
step
in
and
help
and
and
in
the
last
couple
of
minutes,
it's
kind
of
like
how
can
you
prepare
for
an
upgrade
like?
How
can
you
make
this
easier
in
the
future
and
there's
only
one
piece
of
advice,
I
tend
to
recommend
to
teams
and
folks,
and
that
is
to
skip
the
head
and
that
is
to
add
the
current
version.
A
So
at
the
moment,
node
18
is
current,
but
not
long
term
support,
even
if
you
don't
adopt
current
versions,
try
running
your
application
or
your
module
routinely
with
that
version,
because
then
you'll
be
able
to.
You
know
just
gauge
and
keep
on
top
of
how
difficult
your
upgrade
path
is
going
to
be,
and
some
teams
like
to
go
as
far
as
adding
the
current
version.
So
at
the
moment,
node
18
to
their
matrix
is
their
ci
test
matrix
as
early
as
possible,
because
this
means
you're
getting
that
feedback
of
hey.
Is
it
likely
to
break?
A
And
last
thing:
I'd
like
to
call
out
is
in
the
pkg.js.org,
which
is
an
org
with
a
bunch
of
contributors
from
the
node
project
and
other
spaces,
and
we've
created
a
pkg
js
action
and
what
this
does
is
it
automatically
creates
a
matrix
for
you
to
test
against
the
lts
versions
of
node.
So
it
figures
out
what
are
the
lts
versions
and
then
will
automatically
update
your
matrix.
A
So
no
time
would
you
have
to
go
and,
like
add,
a
pr
to
add
a
new
version,
just
as
it
automatically
runs
the
suite,
and
actually
there
is
a
setting
in
there
where
it
will
do
like.
I
recommend,
which
is
to
test
against
all
the
lts
versions
and
the
next
current
version
is
currently
up,
and
this
was
a
lot
of
work
done
by
dominica's
success
and
I'm
sure
he'd
really
appreciate
the
feedback
and
people
to
try
it
out.
So
please
do
take
a
look.
It's
quite
nifty.
I
think
with
that.
A
A
The
second
is,
it
may
have
been
undocumented,
or
maybe
we
didn't
document
it
well
enough.
So
you
raising
it
to
us,
helps
us
to
help
future
folks
and
also
it
helps
us
to
assess
the
impact
of
you
know
similar
changes
in
future.
If
we
listed
something
as
a
patch
to
actually
break
a
bunch
of
people,
we
will
know
in
future.
You
know
when
a
similar
change
comes
along.
Maybe
we
should
be
a
bit
more
cautious.
Maybe
it
needs
to
be
major
and
any
the
places
to
raise
issues
like
that.