►
From YouTube: Web IDE Maintainer Onboarding - Aug 2023 1/4
Description
In this session we deep dive into the Web IDE project:
- https://gitlab.com/gitlab-org/gitlab-web-ide/
A
So
yeah
I
took
some
notes
on
the
agenda
and
I'm
going
to
just
be
following
these
steps
here,
and
so,
if
you
ever
wanna,
follow
along
or
want
to
review
kind
of
what's
this
project,
all
about
again,
maybe
coming
back
to
here
is
a
good
good.
Maybe
I
should
document
this.
That's
probably
another
good
idea,
but
before
we
dive
into
the
web
ID
project
itself,
which
is
here
in
gitlab
web
ID
before
we
dive
into
this
project
yeah
before
we
do
that,
let's
just
make
sure
we're
familiar
with
the
feature
itself.
A
B
A
A
C
A
Yeah,
that's
that's
what
it's
good
for
it's
when
when
you're
feeling
lazy-
and
you
want
to
just
edit
from
here-
so
it's
really
great!
So
this
you
can
open
from
a
number
of
different
contexts
from
merge
requests.
We
can
open
it
up
and
you'll
see
a
little
icon
next
to
the
merge
request,
specific
changes
or
you
can
open
up
from
a
tree
or
a
specific
file,
and
this
is
the
web
ID.
A
A
All
of
this
really
lend
itself
till
we
need
to
pull
this
away
from
the
main
project,
because
we
want
to
be
able
to
test
this
in
isolation
and
run
it
in
isolation,
because
it's
only
just
integrates
with
the
gitlab
API.
It's
not
really
contributing
anything
to
the
monolith.
It's
really
a
client
to
the
the
git
Labs
backend.
A
All
of
that,
given
the
unique
technology
that
was
needed
to
to
make
this
work
lint
it's
this
needs
to
kind
of
be
its
own
project,
and
so
that's
why
it's
in
its
own
project
now
and
the
architecture
to
get
it
to
work.
Where
it's
aware
of
your
gitlab
contacts
is
that's,
hopefully
a
little
bit
that
we'll
dive
into
today.
A
But
that's
part
of
why
this
this
isn't
just
a
this,
isn't
just
a
naive,
drag
and
drop
of
vs
code
browser
environment
we've
had
to
do
a
few
creative
things
to
make
it
feel
seamless
in
the
gitlab
world,
but
yeah
then
otherwise,
it's
just
like
an
editor,
so
you're
just
here
able
to
open
files
edit
files.
Once
you
do
that,
you
can
go
to
the
little
Source
control
Tab
and
commit
things,
and
that's
great.
A
So
that's
the
web
ID
but,
as
you
can
imagine,
there's
some
things
that
are
related
to
this,
because
it's
in
vs
code,
so
that
we're
going
to
dive
into
those
X
external
projects
that
we're
not
interested
in
maintaining
at
the
moment.
Shakar
is
interested
in
maintaining
them.
Thank
you,
shakar,
but
having
this
context
is
helpful
because
these
projects,
all
kind
of,
are
related
so
there's
one
side
project
which
is
the
git
lab
vs
code
extension.
A
This
is
our
official
vs
code
extension.
You
can
download
the
vs
code
Marketplace
that
provides
a
number
of
really
great
integrated
features
into
gitlab
in
your
vs
code,
editing
environment,
one
of
the
huge
wins
for
us
moving
the
web
ID
to
the
vs
code.
Browser
environment
was:
could
we
put
this
extension
into
the
web
ID,
because
this
extension
has
really
neat
features
like
review
and
merge
requests?
Could
we
do
all
of
that
through
the
web?
Id
and
that'd
be
awesome,
so
we
now
have
two
artifacts
that
get
produced
from
this
project.
A
So
how
this
relates
to
the
web.
Id
project
is
knowing
that
when
we
Implement
new
features,
sometimes
we
want
to
just
Implement
them
here
and
then
the
web
ID
is
just
interested
in
just
updating
its
version.
Reference
to
the
vs
code
extension
it's
pulling,
because
if
there's
like
a
new
gitlab
integration
feature
that
I
want
to
have
also
be
similar
in
the
web
ID
and
in
the
desktop
environment.
This
is
the
project
I
want
to
make
that
change.
A
The
second,
the
second
side,
project
that
we
want
to
be
aware
of
is
our
Fork
of
vs
code.
The
very
first
thing
I
have
to
say
about
this
is
that
this
is
just
a
necessary
evil.
So
we
try
as
hard
as
possible
not
to
touch
this
project,
but
you
can
look
in
our
commit
history.
We
maybe
maybe
maybe
we
could
try
a
little
harder.
A
There's
a
lot
of
like
just
CI
stuff,
that's
kind
of
on
the
side
to
like
help
us
just
tweak
how
we
build
this
thing
and
and
package
it
for
it
to
be
consumed
by
the
web,
ID
and
package
it
because
this
is
also
consumed
by
a
remote
development
feature
as
well,
but
yeah
as
you
expect.
We
want
to
keep
this
up
to
date
with
the
Upstream
vs
code
and
so
any
changes
we
make
to
the
actual
production
code.
We
introduce
potential
conflicts
down
the
line
which
we
want
to
strongly
avoid.
So.
A
A
Often
enough
so
yeah,
it's
it's
I
I.
We
tried
to
a
couple
months
ago,
but
there
was
actually
a
bug
in
it.
That
was
fairly
obvious
and
I
tried
creating
Upstream
issue
and
it
didn't
get
resolved
up
there.
So
it's
I
need.
We
need
to
try
to
update
it
again,
but
ideally
it
would
be
like
right
now
we're
kind
of
aiming
at
like
once
a
quarter,
maybe
but
having
it
a
bit
more.
A
We
don't
have
to
do
Force
push
when
we
update
the
vs
code
Fork,
which
we
have
to
currently
do
which
so
it's
not
it's
not
great,
but
this
does
shine
a
good
light
on
the
state
of
the
web,
ID
and
vs
code
projects
in
general.
Is
it's
like
there's
so
much
love
and
improvements.
We
want
to
do
which
makes
it
exciting
and
so
don't
ever
feel
like
when
you
come
across
something
that's
a
little
wonky
like
oh
I,
guess
it's
the
way
it
has
to
be,
because
that's
not
it's
not
the
situation.
C
A
B
Yeah
I
was
just
going
to
say
it
would
be
great
if
we
just
treated
it.
Just
like
you
know,
we
treat
the
gitlab
vs
code
extension
project
in
terms
of
it's
just
a
sub
module,
and
then
you
know
the
vs
code.
Fork
is
just
a
sub
module
and
then
we
somehow
apply
patches
like
magically.
We
just
upgrade
the
sub
module,
apply
our
patches
and
you
know,
that'd
be
really
cool,
but.
A
Yeah
I
have
a
I
have
a
POC
of
that,
so
it's
like
I
think
I
think
that
idea
is
all
there.
It's
a
very
possible
way
of
doing
that
and
I
just
gotta.
We
gotta
we
gotta,
commit
to
it
and
make
it
happen
yeah
anyway.
This
is
the
session
started,
no
no
you're
good
yeah,
but
it's
it's
I
think
it's
good
to
talk
about.
Okay,
let's
take
a
quick
look
at
the
web.
A
So
we've
got
some
folders
here.
This
coverage
is
nothing.
This
has
got
to
be
an
ignored
thing.
Oh,
these
are
just
a
bunch
of
empty
directories.
I
think
we
got
docs
folder
as
you
expect.
That's
where
docs
go,
we've
got
this
gitlab
vs
code
extension.
This
is
a
sub
module
to
the
get
lab
vs
code
extension
right
now.
That's
how
we
include
our
reference
for
it
down
the
line.
A
We
might
not
keep
it
around
as
a
sub
module,
but
since
both
projects
are
being
actively
developed
at
the
same
time,
this
has
been
convenient
for
the
people
that
are
working
on
the
interoperability
between
the
two
and
then
we
have
packages
and
scripts
scripts
are
internal
development.
Scripts
packages
is
the
interesting
bit
so,
unlike
in
the
main
gitlab
project,
where
we
have
one
folder
where
all
the
JavaScript
goes
and
all
the
JavaScript
can
talk
to
all
the
other
JavaScript,
and
you
end
up
with
this
big
noodle
of
JavaScript.
A
So
some
of
these
packages
include,
like
vs
code,
build
in
vs
code
bootstrap
and
the
vs
code
extension,
which
is
the
web
ID
extension
that
is
able
to
be
context
aware
for
for
gitlab.
So
when
we
talk
about,
how
is
the
project
laid
out,
one
is
to
keep
in
mind
is
like
okay.
This
is
this
is
a
monorepo
that
publishes
one
package,
but
the
other
packages
exist
to
create
some
cohesive
boundaries
for
how
we
can
make
that
one
package
and
then
just
being
aware
of
what
are
the
responsibilities
of
these
other
packages.
A
Yeah
I
want
to
take
yeah.
Let's
I'm
gonna
skip
this
one.
Let's
do
this
one.
Let's
do
this
one
a
little
bit
first
right
now,
I
want
to
do
I
want
to
look
at
the
architecture.
Responsibilities
of
the
packages
I
want
to
look
at
this
document,
but
before
I
jump
there
I'm
actually
going
to
detour
very
quickly
into
the
main
gitlab
project.
C
A
A
A
It's
it's
expected
to
be
kind
of
laid
out
this
way
where
you
have
a
whole
bunch
of
files
that
it
can
pull
at
runtime
when
they're
needed,
because,
as
you
can
see
like
we're,
not
going
to
bundle
all
the
extensions
together
in
one
big
glorious
JavaScript,
these
get
pulled
as
they're
enabled
and
as
they
can
use.
You.
A
A
Webpack
knows
to
just
oh
we're
just
going
to
serve
these
up
just
normally,
and
then
this
is
what
gets
imported
and
included
in
the
main
page
bundle.
So
when
we
start
up
the
web
ID,
let
me
do
this
real
fast
when
we
start
up
a
web
ID.
Let
me
start
my
little
Network
thing:
edit
web
web
ID
all
right
go
to
the
network,
all
right.
We
loaded
a
whole
bunch
of
stuff
yeah.
A
So
you
see
here
we
get
all
these
like
assets,
webpack
and
then
we
get
from
the
get
lab
web
ID
project
we
get
we're
pulling
in
these
modules.
This
is
all
stuff
that
vs
code
does
out
of
the
box,
so
we
just
have
to
have
a
place
where
these
modules
live
and
that's
how
the
package
has
two
parts.
One
part
that
gets
bundled
up
in
our
main
page
bundle
and
then
the
other
part
that
we
have
to
host
for
vs
code
to
work.
That
was
my
main
point.
A
A
All
right
so
I
wanna
this,
this
diagram
is
probably
looks
a
little
daunting,
not
daunting's,
not
the
way
we're
but
confusing
at
first.
But
the
reason
I
wanted
to
show
I
wanted
to
show
those
the
package
as
it
gets
consumed
by
gitlab,
is
because
that's
how
this
diagram
is
organized
is
a
number
of
our
sub
packages
in
the
gitlab
web
ID
project.
A
A
We
have
a
package
in
the
gitlab
web
ID
project
called
vs
code
build
and
that
package
looks
really
interesting
where
it
doesn't
really
have
any
code.
It
just
has
a
make
file
that
holds
vs
code
artifact
down
based
on
this
file
of
where
are
we
finding
our
vs
code
artifact?
And
then
it
puts
that
in
this
package
is
disk
folder
and
then
the
other
other
parts
of
our
build
process
will
pull
that
dist
into
the
final
package,
we're
building
so
inside
of
vs
code.
A
We
also
have
this
extension
that
kicks
off
the
context-aware
web
ID,
and
so
that's
in
this
package,
vs
code
extension
web
ID,
and
so
this
is
similar
to
the
gitlab
BS
code,
workflow
extension,
and
that
this
is
consuming
vs
codes,
extension
API,
which
there's
a
lot
of
really
great
documentation
on.
Yes,
this
is
all
consuming
just
the
vs
code
API,
but
this
is
like
the
built-in
extension
that
knows
how
to
start
up
the
file
system
and
make
the
initialize
requests
and
everything.
This
is
our
built-in
web
ID
extension.
A
A
Okay,
oh,
go
talk
to
Issa
Issa
knows
where
it
is:
okay,
here's
this
vs
code,
bootstrap
file
and
I'm
gonna.
Go.
We
don't
have
to
understand
everything,
that's
going
on
here
right
now,
but
you'll.
This
is
all
coming
from
vs
code,
specific
API,
that
when
we
just
started
all
up,
these
are
all
configuration
settings
that
it
it
expects
so
yeah,
big
takeaway.
This
document
exists.
A
Individual
packages
have
a
specific
responsibility,
a
specific
bit
that
we're
there
supplying
to
the
overall
package,
and
so
knowing
what
that
individual
package's
responsibility
is
is
important,
and
so
you
can
look
at
this
document
to
kind
of
get
a
feel
for
that.
Some
of
it's
written
out
here,
which
is
probably
even
clearer
than
a
trying
to
make
a
picture
out
of
the
yeah
I.
Don't
know
what
do
you
all
think.
B
A
That's
a
great
question:
let's,
let's
check
in
the
code,
so
this
is
the
web
ID
prac
web
ID
package,
which
has
the
index
which
exports
the
start
functions
and
when
we
build
our
iframe,
we
are
yep
we're
just
looking
for
main.js
that
lives
inside
that
disk
folder,
which
in
this
context
is
referred
to
as
the
base
URL.
But
it's
a
sibling
to
the
vs
code,
folder
and
stuff,
like
that
yeah,
my
Mac
requires
a
security
update.
What
is
this?
Are
you
all
seeing
this?
C
A
C
I
think
everything
kind
of
well
you're
so
far,
I
had
a
question
earlier,
but
I
I
think
the
walkthrough
you've
done
has
almost
kind
of
like
answered
it
about
the
ability
to
add
Extensions
by
default
to
our
web
ID
and
from
what
I
can
see.
We
do
include
the
vs,
the
good
five
vs
code
extension
already
and
in
there
so
I
I
guess
this
has
been
answered
already.
A
Yeah,
that
is
a
good
question,
so
we
can
see
the
the
code
that
does
that
I'm
just
showing
like
this,
this
kind
of
the
packages
to
familiarize
yourself
or
we're
looking
for
something
like
that,
including
an
extension
by
default.
That's
like
when
we're
initializing
vs
code,
that's
going
to
kind
of
live
here
in
this
vs
code.
Bootstrap
thing
these
modules
are
not
the
best
named,
but
Maine
is
the
main
file
and
start
is
the
start
file.
A
We
have
some
other
kind
of
extensions
we
support
just
in
our
own
environment.
Yes,
but
don't
ask
don't
interrupt
me
logo,
but
can
you
play
in
your
room
because
it's
a
little
loud,
that's
a
good
idea
and
then
yes,
we
include
the
get
lab
vs
code
extension
yeah,
the
the
build
glue
for
all
of
this,
which
is
a
bit
that
I've,
you
know
tried
to
tactfully
work
around,
but
I
feel
that
I
feel
the
need
to
come.
The
complain
bring
out
all
the
all
the
dirty
laundry
of
this
project.
A
A
You
see
us
have
some
bit
of
code
where
we
initialize
that
sub
module
on
our
build
step,
and
then
we
include
inside
of
our
inside
of
the
disk
folder
how
to
build
this
and
then
we're
also
going
to
ref
have
references
where
we
pull
it
in
as
well,
and
things
like
that,
so
we
don't
have
to
understand
all
the
make
file
I
just
want
to
share.
This
is
a
this
is
a
lot
of
the
glue
for
how
this
output
files
of
certain
packages
end
up
in
other
packages.
A
What
am
I,
what
am
I
going
to
use
right
sponsor,
make
right
I
like
I,
like
make
the
big
to
do
here
and
if
you
all
become
maintainers
before
I.
Do
this?
One
of
you
all
will
will
come
across
this
merge
request
for
myself.
The
big
to
do
is
to
split
up
the
make
file
so
that
we
don't
include
all
the
package
information
in
one
glorious
file.
A
Yeah
cool
so
I
think
a
couple
of
things
I'm
noticing
as
we're
talking
about
this
and
when
I
say
we
I
mean
as
I'm
talking
about
it
and
you
are
being
very
patient
and
but
you
all
have
asked
really
great
questions
for
like.
Where
is
the
web
ID
doing
this
anytime?
You
have
that
question
pop
up.
Your
head.
Ask
me
right
away
so
that
I
can
we
can
dive
into
the
code
and
I?
Think
that's
a
really
great
way
to
familiarize
yourself
is
like.
Oh,
this
is
gonna.
A
A
C
A
C
A
A
Yeah
this
required
changing
the
changing
like
a
constant
that
was
hard
coded
in
the
vs
code
in
the
vs
code
source
code.
But
then,
once
that
change
will
merge
into
our
Fork,
we
have
a
process
for
kicking
off
a
release
internally
there
and
that's
how
we
reference
and
pull
down
those
pack
that
package
that
got
updated.
C
A
Then
the
other
only
other
thing
here,
then,
is
that
project
then
expects
some
configuration
parameters
which
we
can
control
here.
So
it's
like
this
is
where
previously
I
said
something
like
we
don't
want
to
touch
the
fork
I
just
admitted
to
touching
it.
We
could
have
touched
the
fork
in
a
very
dramatic
way
and
just
like
we're
hard
coding
this
into
it.
A
We'd
only
had
we
only
touched
something
that
was
hard-coded,
but
for
us
to
use
our
own
CDN.
We
needed
to
provide
a
custom
value
to
this
setting
parameter
when
vs
code
all
starts
up.
The
main
takeaway
here
is
like
this
is
a
vs
code,
starting
configuration
thing,
that's
going
to
show
the
vs
code,
bootstrap
or
bootstrapping
vs
code,
all
of
that
wiring
all
together
that
all
lives
in
this
package
and
then
the
rest
is
just
tests
and
that's
it.
So
it's
that's.
A
That's
a
kind
of
kind
of
merge
request
to
expect
there's
some
CI
updates.
Let
me
look
at
there's
some
really
small
Mrs,
which
are
like
here's,
an
MR
that
just
updates
the
commit
of
the
gitlab
vs
code
extension.
So
this
is
one
great
way
that
the
web
ID
receives.
New
features
is
vs
code
extension
gets
updated
and
it's
updated
in
such
a
way
that
a
new
feature
knows
how
to
run
both
the
web
ID
and
the
desktop.
So
this
project
just
needs
to
update
its
reference
to
the
new
git
lab
vs
code
extension.
A
We
have
a
job
that
makes
sure
that
these
commits
come
from
tagged
commits
on
the
project,
so
we're
not
just
pointing
to
random,
commits
we're
pointing
to
actual
releases
of
the
gitlab
vs
code
extension.
But
this
is
another
kind
of
really
straightforward
Mr
that
we
can
expect
from
this
kind
of
project.
A
A
So
this
required
changing
a
very
interesting
package
which
we'll
talk
a
little
bit
more
about
in
a
little
bit.
It
required
changing
this
web
IDE
interop
package
or
you
can
you
can
dive
into
the
readme
to
get
what's
the
whole
point
of
this
package,
and
it's
this
is
all
about
the
interoperability
between
the
web
ID
and
the
gitlab
vs
code
extension
so
anytime.
A
So
it
has
this
one
file,
which
is
a
lot
of
different
types
and
some
constants
that
are
shared
between
the
two
environments
but
anytime.
This
file
changes.
We
also
change
it
in
the
we
have
to
try
to
keep
these
files
in
sync,
we
could,
probably,
within
a
period
of
five
minutes,
come
up
with
five
better
ways
to
keep
these
files
in
sync
than
the
manual
copying
and
pasting
process
that
we
do,
but
right
now
we
just
manually
copy
and
paste
anytime.
This
file
changes
across
the
projects.
A
So
the
fact
that
in
the
vs
code
extension
they
needed
to
be
able
to
provide
headers,
they
have
to
implement
that
behavior
here
if
they
want
the
web
ID
to
be
able
to
consume
that
so
they've
updated
the
types
to
receive
headers
and
then
updated
the
underlying
code
to
receive
and
actually
use
HTTP
headers.
When
we're.
A
A
A
A
A
If
we
look
for
what
uses
fetch
from
API
one
downside
side
note
one
downside
to
you
having
a
sub
module
is
when
I
do
a
project-wide
search.
A
search
is
inside
the
sub
module,
as
well
so
I'm
going
to
exclude
all
of
these
ones
in
the
vs
code
extension
one:
okay,
if
I
look
for
what
is
referencing,
this
fetch
from
API
type
I'll
see
in
the
web
ID
project.
A
We
have
a
command
that
implements
this
fetch
from
API
thing.
It
has
to
implement
this
type
for
both
the
vs
code
extension
and
the
web
ID
to
adhere
to
the
same
interface
so
that
we
could
be
polymorphic
with
it,
but
this
default
gitlab
client
is
the
actual
underlying
thing
that
knows
how
to
resolve
and
implement.
This
is
the
actual
implementation
of
the
thing.
A
A
Mediator
commands
which
we'll
talk
about
in
a
second.
But
the
really
cool
thing
that
I
wanted
to
highlight
with
this
is.
This
is
a
really
large
merge
request.
It's
doing
a
lot
of
refactoring
in
typescript,
I've
noticed,
merge,
requests,
kind
of
tend
to
be
bigger
because
you
have
any
time
you
update
a
type.
A
You
got
to
kind
of
propagate
that
type
change
everywhere,
but
here's
a
really
great
thing
with
typescript
when
it
comes
to
really
somewhat
large
Mrs
like
this,
that
are
touching
a
lot
of
files
when
we
change
over
here,
I'm,
just
here,
I'm
just
updating
something
but
reviewing
these
typescript
changes.
Let
me
see,
let
me
find,
let
me
see
if
I
can
find
one,
let's
try
to
check
out
yeah
yeah,
let's
go
to
here.
A
Oh
no,
let's
go
to
here
yeah
with
reviewing
these
like,
and
you
see
I'm
I'm
referencing,
this
function
where
I'm
creating
a
graphql
request
and
I'm
passing
in
these
generic
type
parameters.
I
find
myself
when
we're
doing
these
merge
request
reviews
compared
to
the
main
gitlab
project.
I,
don't
have
to
look
at
as
many
potential
gotchas
as
I
do
in
the
main
gitlab
project,
because
it
will
fail
and
blow
up
at
compile
time
if
I'm
referencing,
something
or
I'm
using
something
in
a
way
that's
not
declared
in
the
type.
A
So,
what's
really
great,
is
we've
been
able
to
adhere
to
typescript
from
ground
zero
and
everything's
strongly
typed.
We
avoid
any
anything
like
that
as
much
as
possible
and
it
pays
off
here
where,
rather
than
looking
at
okay
or
how
are
we
just
hooking
up
all
the
types
I
can
get
a
feel
for
changes
by
looking
at
the
types
we're
introducing
and
just
and
thinking
about,
like
okay
do
these
types?
Why
are
these
I
click
on
this,
and
it's
taking
me
to
the
top
we're
like?
A
B
C
A
A
top
anyways
yeah.
My
main
point
is
this
is
a
very
confusing
large
Mr,
so
this
is
probably
as
confusing
and
large
as
it'll
get
if
you're
not
familiar
with
typescript,
but
looking
at
the
type
definitions
is
a
great
way
to
get
a
feel
for.
What's
actually
changing
here,
because
there's
no
cheating
the
type
definitions
they
they
will
fail
on
compile
time,
which
is
really
great
win.
It's
something
that
we
don't
experience
in
the
main
gate
lab
project
as
a
reviewer,
I
I
really
appreciate
it.
A
B
Much
easier
like
even
as
a
developer,
to
make
big
read
to
make
big
refactors
is
a
lot
easier
like
it.
Just
tells
you
in
red
right
that
hey
all
these
things
have
gone
wrong.
When
you
made
this
little
change
by,
you
know
capitalizing
the
L
and
git
lab
or
whatever,
so
it.
It
really
does
help
with
these
things,
and
you
can
always
yeah.
You
can
always
check
out
the
and
stick
the
types
and
and
even
the
fact
that
the
that
it's
BSC
is
compiling.
A
Cool
I
think
the
last
thing
I
want
to
do
is
dive
into
maybe
some
special
packages.
We
talked
about
the
web
ID
and
drop
a
lot,
but
I
want
to
talk
about
a
few
other
special
packages,
starting
with
maybe
the
example
package.
So
no
packages
require
the
example
package.
The
example
package
is
an
app
that
allows
us
to
test
all
of
this
in
isolation
apart
from
the
main
git
lab
project.
So
I
don't
need
the
GDK
running
to
run
the
web
ID,
which
is
cool
so
opening
up
the
readme.
A
A
A
It's
building
the
underlying
vs
code
extension
stuff,
so
there's
a
bit
of
building
that
seems
to
be
happy.
I
must
have
had
it
cleaned
before
yeah,
okay,
nice
and
it
copied
everything
out
boom.
It's
ready
to
go,
but
up
here
it
gave
me
where
I
could
visit
to
actually
open
up
the
example
app,
and
so
the
example
app.
A
You
start
off
by
giving
some
git
lab
configurations
for
how
it's
going
to
communicate
to
git
lab
I'm
gonna
say
that
we're
going
to
open
up
the
gitlab
web
ID
project
from
gitlab.com
I
could
point
this
to
my
local
GDK,
which
I
do
often
too
and
then
I
can
say
what
Raph
I
wanted
to
open
up
at.
We
have
some
other
tips
here.
A
I,
don't
think
the
code
suggestions,
one
does
anything,
because
we
move
the
code
suggestions
into
the
vs
code
extension,
but
this
one
you
can
enter
a
git
lab
token
to
do
the
authentication
for
writing
and
make
actually
making
changes.
In
this
example.
App
so
I
have
a
little
security
warning
here
of,
like
you
know,
hey.
This
is
an
example
app.
Maybe
you
don't
want
to
share
your
production
token.
A
A
Looking
at
all
this,
just
through
the
read-only
way
that
I
mean
you
could
interact
with
the
web
ID,
but
I
can
use
the
web
ID
without
the
GDK
and
just
test
it
here,
and
this
watcher
will
watch
any
changes
that
I
possibly
make
so
I
can
go
over
to
the
web.
Id
extension
and
we'll
go
here
to
the
main,
activate
function
and
we'll
call
vs
code
window,
show
error
message.
B
A
All
right
and
we
can
see
it
starts
building
since
it
detects
the
typescript
changes.
It's
gonna
incrementally
rebuild
just
what
it
needs
to,
so
it
won't
have
to
pull
vs
code
and
do
everything
over
again
I'll
refresh
my
example.
App
start
it
again:
hey
where'd,
my
where'd,
my
wall
go:
oh
okay,
I
didn't
have
the
network
tab
open,
I'm
glad
we
ran
into
this
the
example
apps.
All
the
assets
are
going
to
be
cached.
We
don't
have
cash
breaking
on
which
I
need
to
that's
a
to-do
thing.
A
We
gotta
do
so
I
got
to
make
sure
that
the
tabs
open,
so
that
the
cache
is
actually
disabled.
When
I'm
doing
this
in
the
example
app,
where
are
you
at
and
I'm
pretty
sure
this
is
Firefox
as
well
in
addition
to
having
the
cash
disabled
Firefox.
For
some
reason,
although
it
says
it's
disabled
because.
C
A
A
Oh!
Oh!
Here's,
my
woe!
Yeah!
It
came
up.
I
thought
it
was
gonna,
be
a
modal.
Did
it
show
up
like
that
on
the
Firefox
and
I
just
wasn't
paying
attention
it
didn't
show
up
here.
Didn't
oh
yeah
it
just
yeah
Firefox!
Doesn't
care
yeah
forget
about
Firefox,
so
if
you're
testing
this
thing
out,
I
recommend
using
Chrome
the
web
ID
Works
in
Firefox
for
some
reason
our
example
app.
That
has
a
hard
time,
forgetting
things
it's
very.
B
A
Yeah
yeah
well,
I
mean
so
the
way
it's
the
way.
It'll
work
is
yeah
because
it's
just
reads:
it's
just:
let's
find
a
good
one
yeah,
so
you
see
like
there's.
No
there's
no
hash.
That's
gonna
put
cash
thing
here,
so
it's
things
just
get
cached,
what's
challenging
what
we've
noticed
with
Firefox
vs
code
makes
extensive
usage
of
things
like
web
workers
and
service
workers,
so
that
things
can
be
sandboxed,
which
is
a
good
thing
but
Firefox,
even
though
I
say
something
like
disable
cash.
A
It
doesn't
seem
to
do
that
when
the
requests
come
through
a
service
worker
web
work.
So
it
seems
like
a
weird
bug
with
Firefox
that
if
we
were
great
citizens
we
would
also
create
probably
a
Firefox
issue
and
probably
something
to
do
but
main
takeaway
is
you
can
test
out
the
web
ID
without
the
GDK?
By
using
the
example
app?
And
we
can
you
just
want
to
make
sure
you
have
the
dev
tools
open
with
disabled
cash
and
yeah?
A
A
Do
this
later
yeah,
we
ran
out
of
time
and
that's
okay.
I
mean
this
was
loads
of
information,
so
I
think
it's
good
to
probably
just
sit
here
next
week.
We'll
start
pairing
on
something,
but
I
might
I
might
just
jump
into
a
high
level.
Talking
about
this
weird
package,
mediator
commands
because,
right
now
this
is
a
key
element.
A
That's
that
is
makes
the
web
ID
work,
but
it's
weird
so
it's
worth
talking
about,
but
you
can
also
read
the
architecture
package
architecture
documents
for
more
information
on
on
on
that,
but
yeah,
that's
that's
man!
That's
a
crash
course
that
was
that
was
a
lot
of
stuff.
So
thanks
for
letting
me
introduce
all
of
that
and
then
we'll
get
the
next
three
weeks
is
just
Hands-On.
Let's
just
start
pairing
on
it,
so
we'll
get
comfortable
with
it
and
that's
it
and
then
as
we're
making
as
you're
reviewing
code.
A
If
there's
any
questions
about
it,
don't
ever
feel
like
you
have
to
know
everything
about
the
project.
It's
just
about
sharing
your
your
your
own
personal
expertise
on
maintainability,
and
then
we
can
Loop
in
as
many
people
as
needed
for
specific
questions
and
and
and
help
there.
So
as
I'm
doing
this
large
crash
course,
the
main
intent
is
just
to
get
a
feeling
for
the
state
of
the
project
and
and
where
things
are
at
not
having
to
be
an
expert
at
all
of
it.
B
A
Yeah
well,
thank
you.
Thank
you,
shikaran
thank
you.
Ahmed
I'm,
so
excited
to
have
more
citizens
on
the
project
and
I.
Think
it's
gonna
be
great.
So
please,
oh,
the
thing
I
was
gonna
say
is
Shakara
you're
already
on
it,
but
I'm
mad.
If
you
could
join
and
I'll
leave
a
comment
on
the
issue,
but
if
you
can
join
the
F
getlab
web
ID
channel
yeah,
that's
where
that's
probably
the
most
up-to-date
information,
and
just
we
do
a
lot
of
the
conversations
about
this
specific
project
there.