►
Description
PnP Short Video on how to debug SharePoint Framework solutions in Visual Studio Code. Starting from SharePoint Framework Yeoman templates v1.3.4, scaffolding will create needed debugging settings automatically for your SPFx solution. Details on the used commandlets available from the following article - https://docs.microsoft.com/en-us/sharepoint/dev/spfx/debug-in-vscode
A
Welcome
to
the
SharePoint
patterns
and
practices
short
video
system,
we'll
have
a
look
on
how
to
debug
shape
on
framework
solutions
in
Visual
Studio
code
and
let's
actually
jump
right
into
it.
So
here
we
have
already
created
an
out-of-the-box
Visual
Studio
code,
a
solution
or
actually
SharePoint
framework
solution
which
has
been
open
up
within
the
Visual
Studio
code
as
part
of
the
version
1.3,
1.4
and
forward.
A
We
from
SharePoint
engineering
are
including
the
needed
debugging
configurations
to
make
the
debugging
as
easy
as
possible
within
the
visitors
to
their
code
and
their
certain
requirements,
which
we
need
to
take
into
account
when
we
start
doing
this.
So
first
of
all
the
debugging
requires,
and
the
easte
debugging
directly
in
Visual
Studio
code
requires
that
we
have
a
debugger
for
Chrome
extension
installed
for
time
being
you
have
to
use
the
debugger
for
chrome,
there's.
New
additional
dip
occurs
for
other
process
available,
but
this
works
pretty
well
in
the
Chrome
browser.
A
It
might
be
done
at
some
point
and
there
will
be
additional
extensions
which
are
supporting
other
process
as
well,
so
in
your
visitors
to
their
code,
you
need
to
have
this
extension
installed.
So
you
can
actually
start
debugging
directly
within
the
Visual
Studio
code
and
in
the
context
of
the
Chrome
browser.
Now,
let's
get
back
on
the
code,
so
as
part
of
the
version
1.3
point
for
and
forward,
we
will
give
you
the
needed
configuration
in
the
vs
code
folder.
A
So
if
you
have
a
look
on
this
launch
JSON
file,
this
actually
contains
the
configurations
for
the
debugging.
So
how
do
we?
How
does
the
Chrome
extension
actually
behaves?
Where
does
it
actually
open
up?
What
are
the
additional
runtime
arguments
when
the
Chrome
browser
actually
starts
going
to
start
debugging
and
there's
two
different
configurations
here
with
so
we
have
a
separate
configuration
for
local
workbench,
which
is
boiling
on
to
the
localhost
four
three
two
one,
which
is
two
local
Brickman's
URL,
and
then
there's
a
separate
configuration
for
the
hosted
workman.
A
A
So
how
do
we
do
debugging
we'll
go
to
the
actual
source
code,
and
in
this
case-
and
this
is
just
out
of
the
box-
a
web
part
which
has
been
created
and
there's
no
changes
yet
on
the
code
and
directly-
and
this
is
using
the
one
point-
three
point:
four
version:
if
you're
using
a
new
version
of
SharePoint
framework,
this
would
might
be
looking
slightly
different
again,
but
the
basic
functionality
is
and
basic
experience
for
debugging.
Exactly
is
exactly
the
same.
A
Now,
if
I
do
a
at
a
breakpoint
here
in
the
line
19,
we
can
actually
say
that
I
can
at
that
breakpoint
available
just
by
clicking
the
certain
section.
So
now
we
do
have
a
breakpoint
available
or
marked
into
our
code
and
we're
basically
ready
to
start
debugging.
The
thing
what
we
need
to
remember
first
is
to
actually
start
the
solution
in
the
Knope
rouser
mode.
So
what
I'm
going
to
do
is
that
I
started
to
terminal.
A
Let
me
actually
open
up
that
one
using
the
browser
or
the
window,
so
you
can
easily
find
where
you
can
open
up
that
determine
our
console.
So
if
you
open
up
the
View
window,
you
can
actually
see
this
integrated
terminal
option
and
that
will
open
up
the
integrated
terminal
directly
within
the
visual
studio
code
and
you
can
choose
to
use
PowerShell
or
command
line.
A
There's
multiple
options
here
as
well,
but
for
me
the
setup
is
being
the
powershell
integrated
console,
and
what
I
want
to
do
here
is
that
I
want
to
run,
call
up,
serve
and
no
browser,
and
this
will
essentially
make
sure
that
the
compilation
of
the
transformation
of
the
typescript,
the
javascript,
has
happened.
The
bundling
has
happened
and
we're
ready
to
go
to
start
debugging
of
our
code
as
well.
So
there
we
go
now.
Everything
is
up
and
running.
A
Our
localhost
is
running,
our
localhost
is
serving
the
fall,
and
I
can
actually
go
to
the
code
and
have
a
look
on
the
under
modification.
I
could
do
modification
that
will
just
rewire
that
that
oh
well,
that
will
recompile
that
run
the
type
script
to
the
JavaScript
as
we
move
as
we
make
those
changes
within
the
code.
But
in
these
guys
we
wanted
to
test
the
debugging.
A
So
again,
if
I'm
in
here
I
can
choose
debug,
start
debugging
or
I
burn
I
can
press
also
f5,
which
works
as
well.
So
let's
actually
do
that
so
I'm
pressing
f5,
what's
going
to
happen,
is
that
another
processor
window
or
Prowse
window
is
actually
started,
and
let's
do
this
side
by
side,
so
we
can
easily
see
what's
actually
happening
while
we're
doing
the
debugging.
So
I'm
gonna
hide
on
the
left
and
navigation.
So
I'm
gonna
hide
the
file
section.
A
A
For
example,
this
dot
context
is
a
good
example
of
the
information
which
is
getting
visible
and
getting
available
for
your
web
part,
or
you
can
have
a
look
on
this
stood
host
or
HTTP,
client
and
all
of
those
properties
within
the
code.
So
you
can
actually
do
step
by
step
debugging
within
a
code
and
we
feel
fine.
A
You
can
also
say
that
the
shortcuts
here,
which
are
pretty
familiar
and
when
we're
good
to
go,
we
can
just
press
f5
and
the
web
park
is
getting
loaded
and
again
when
we
do
modifications,
we
will
hit
the
breakpoint
in
this
case,
because
this
is
a
reactive
web
part.
It
will
actually
rerender
the
render
section
and
execute
this
code
every
single
time
and
actually
go
modification
on
the.
A
So
that's
why
the
parade
points
again
heating,
but
key
point
here,
is
that
when
I
do
an
f5
I
will
actually
get
that
browser
to
start
and
it
will
be
attached
to
the
visitors
to
their
code
and
I
can
do
actual
debugging
of
my
god
directly
within
the
Visual
Studio
code
and
that's
super
cool.
Now.
How
do
we
do
this
in
the
context
of
sharepoint
online?
So
it
lets
actually
break
this
one
and
let's
get
back
on
the
on
the
files,
and
let
me
actually
open
up
that.
A
Lounge
JSON,
which
we
had
a
quick
look
on
this
one
already.
So
this
is
the
local
workbench
option
and
which
was
the
one
which
is
hosting
stuff
from
a
local
host.
But
if
you
want
to
do
debugging
in
the
context
of
SharePoint,
that's
not
necessarily
what
you
want
to
do,
because
in
the
context
of
SharePoint,
you
have
much
more
additional
options
and
information
available.
A
If
wanna
test
with
the
live
data
as
an
example,
you
would
actually
go
to
the
hosted
workbench,
which
is
actually
running
within
the
SharePoint,
and
that
URL
is
then
your
tenant
underscore
layouts
and
work
on
aspx.
So
now,
if
I
do
here,
SP
PMP
on
sorry
SharePoint
com,
there
we
go
underscore
layout
weapons
aspects.
I
would
be
in
the
context
of
my
developer
tunnel,
there's
certain
options
here,
which
you
can
actually
configure,
which
sister
runtime
arguments
so
depending
again,
how
familiar
you
are
with
the
chrome
profiles
and
how
chrome
profile
work.
A
You
might
or
might
not
use
the
ink
of
NATO
option
in
here.
If
you
use
the
ink
open
adoption,
the
debugging
and
the
host
against
the
host
workman's,
when
starting
it
in
against
that
URL
will
start
in
the
incognito
mode
and
you
need
to
sign
in
now.
Technically,
if
you
know
how
the
profiles
actually
work,
you
could
get
rid
of
this
one
and
as
long
as
you
are
using
as
long
as
you,
you
touch
that
session
or
the
profile
browser
which
is
in
the
same
in
your
in
your
tenant
context.
A
It
would
actually
run
that
one
and
open
that
one
as
the
debugging
window
for
time
being
for
the
demonstration
purposes.
Let's
actually
keep
the
incognito
option
still
here
and
let's
go
to
the
debug
option
and
the
default
setting
is
the
local
Berkman.
So
I
want
to
have
flip
that
one
to
be
hosted
and
then
I'm
doing
going
to
start
at
debugging
and
that's
going
to
now
start
a
new
process
session
and
let's
go
onto
our
file
and
double
check
that
we
have
an
extension.
We
have
a
breakpoint
waiting,
so
let's
actually
get
that
one
there.
A
But
we
can
see
that
this
is
in
ink
of
NIDA
mode
based
on
that
icon
there
over
there
and
that's
why
we
need
to
sign
in
as
well
so
now,
if
I
sign
in,
we
can
say
that
we
are
actually
in
the
layouts
workbench
and
there's
a
first
debug.
Sorry
breakpoint
is
actually
getting
catch
and
this
is
an
exception
actually
in
out-of-the-box
JavaScript
files.
A
So
that's
why
that
is
getting
tackled
or
there's
a
breakpoint
getting
hit,
and
so
we
can
ignore
that
and
let's
continue
forward
because
we're
interested
actually
on
the
code
which
is
in
here.
So
we
are
interested
on
getting
that
breakpoint
actually
to
hit
so
we're
able
to
analyze
again
our
code
in
against
the
live
SharePoint
site.
A
A
This
one
was
the
unfortunate
article
box,
one
for
time
being
and
there's
our
paper
to
point
which
is
getting
hit
on
our
custom
code
and
now
we're
able
to
again
analyze
the
values
analyze,
the
context,
we're
able
to
analyze
additional
information
and
do
property
bucking
against
the
code,
which
is
running
in
the
context
of
browser.
But
we
can
do
the
debugging
directly
in
visitors
to
their
code
and
that's
super
super
cool
now
like
mentioned,
this
capability
is
part
of
the
1.3
point
for
SharePoint
framework.
A
If
you're
using
an
older
version
of
SharePoint
framework,
you
need
to
do
some
of
a
configuration
manually
if
you're
running
the
version,
1.3
point
for
a
new
version
of
SharePoint
framework.
The
only
thing
what
you
need
to
do
is
install
the
SharePoint
install
the
Chrome
extension
to
Visual
Studio
to
code
to
make
this
happen
and
obviously,
if
you
have
any
feedback,
please
use
our
kidnapping
social
media
channels
to
let
us
know
how
we
can
improve
your
development
experience
in
the
future
as
well.
Thanks
for
watching
and
let's
absolutely
stay
in
touch.
Thank
you.