►
From YouTube: Web IDE Maintainer Onboarding (APAC) - Aug 2023 1/4
Description
In this session we deep dive into the GitLab Web IDE project.
- https://gitlab.com/gitlab-org/gitlab-web-ide/
A
A
In
no
way
is
it
expected
that
you
need
to
memorize
everything
about
the
project
or
be
intimately
familiar
with
it.
Just
being
sort
of
familiar
with
the
thing
is
the
objective
and
having
some
of
the
keywords
in
in
your
head.
The
next
three
sessions
is
we'll
we'll
pair
on
something,
and
it
would
be
interesting
because
we'll
be
in
doing
separate
time,
zone
meetings
and
we'll
see
how
that
works
out.
But
so
this
is
just
the
big
introduction
time
and
not
what
the
remainder
of
the
meetings
will
be
like.
A
Okay,
let
me
start
sharing
my
screen
and
so
I
took
some
notes.
I
started
out
trying
to
make
a
slide,
and
then
man
that
just
took
too
long
so
I
was
like
all
right,
I'm,
just
making
notes
I,
because
it's
like
I
was
trying
to
make
it
pretty.
I
was
like:
why
am
I
wasting
my
time,
making
this
pretty
I'm
just
gonna
take
notes.
A
A
Previously
we
had
a
homegrown
environment
that
was
a
little
unreliable
because
it
was
homegrown
and
vs
code
has
loads
of
love
and
a
robust
community
that
keeps
it
that
keeps
it
very
lovable.
So
it's
been
pretty
great
that
we
were
able
to
find
a
way
to
make
it
seamlessly
connect
with
your
gitlab
contacts
and
so
previously,
where
we
had
a
fully
full
from
scratch:
editing,
environment
based
on
the
monocle
editor
and
every
we
controlled
all
the
moving
pieces.
A
A
A
A
A
Then,
when
things
change
we'll
run
into
conflicts
and
that
that
will
be
difficult
to
maintain
the
downside
is
we've
kind
of
touched
this
thing
a
bit,
but
we
really
try
not
to
there's
a
lot
more,
that
we
want
to
try
to
do
to
control
how
we
do
this.
A
lot
of
those
us
touching
this
project
is
just
affecting
how
we
build
it.
So
there's
a
lot
of
is
like
some
CI
changes
and
internal
scripts
with
it.
A
But
this
is
the
projects
the
main
this
artifact,
that
the
project
produces
is
a
tarball
of
the
vs
code,
browser
environment
and
that's
what
we
also
load
into
the
gitlab
web
IDE,
not
much,
not
much
that
we
regularly
have
to
touch
here.
But
if
we
ever
update
this,
what
you'll
see
in
the
main
web
ID
project
is
you'll
see
just
an
update
to
the
version
location
of
oh
we've.
We've
updated
the
vs
code
for
version
of
where
we're
downloading
it
from
yeah.
A
Those
are
the
main
other
two
projects
that
this
web
ID
project
communicates
with
yeah,
and
that
brings
us
to
the
gitlab
web
ID,
which
the
main
artifacts
that
we
produce
from
this
project
is
this
gitlab
web
ID
npm
package,
and
so
this
gets
published
through
CI
jobs,
which
we
have
a
lot
to
do
to
make
it
more
to
improve
the
developer
experience.
So
it's
not
we're
not
making
tagging
releases
ad
hoc
and
we're
able
to
do
this
kind
of
schedule.
You'll
also
notice
that
we're
not
using
semantic
versioning.
A
A
A
But
we
replay
our
commits
onto
like
a
release
candidate
branch
that
we
we
have
a
the
branch
is
based
off
of
whatever
vs
code
Forks
the
vs
code
tag.
We
want
to
base
it
off
of,
and
then
we
replay
all
our
commits
on
top
of
that
which
is
kind
of
cool,
but
it
does
require
us
to
force
push
domain
when
we
finally
commit
to
everything
which
is
not
a
pleasant
experience.
A
A
A
A
All
right,
we
have
documents
folder.
This
is
where
we
we
keep.
We
try
to
document
some
of
our
processes
and
how
to
work
with
the
different
tools
and
patterns
that
you'll
see
in
the
project
so
perusing
through
this
and
just
being
familiar
with
it.
It
would
be
nice,
but
we
kind
of
use
it
as
a
reference.
A
We
need
to
be
pretty
lean
with
when
we're
building
that
so
using
a
sub
module.
Helped
us
move
quick,
but
there's
some
downsides
with
the
sub
module
here,
which
is,
if
I'm
like
searching
for
something
and
the
project-wide
search
and
vs
code,
it'll
search
in
both
the
sub
module
and
and
the
main
thing.
So
the
sub
module
approach
to
including
the
gitlab
vs
code
extension
might
not
stay
around,
but
that's
how
it
gets
included.
A
And
then
you'll
see
all
of
the
source
code
lives
inside
of
this
folder
packages.
So,
unlike
the
main
gitlab
project,
where
we
have
all
of
our
JavaScript
lives
in
one
folder
and
any
module
can
reference
another
module
and
all
of
it
becomes
this
big
bowl
of
spaghetti,
because
modules
are
pointing
all
over
the
place.
We've
tried
to
organize
the
responsibilities
of
to
build
that
final
gitlab
web
ID
object
into
clear
responsibilities
which
are
implemented
with
these
packages.
So,
for
instance,
there's
a
whole
like
file
system
package
that
we
needed
to
implement
that
uses.
A
A
So
all
of
this
lives
in
its
own
package
so
that
it
never
breaks
its
encapsulation
of
just
being
concerned
about
file
system
stuff.
It
doesn't
have
to
dive
into
vs
code,
specifics
or
git
lab
client
specifics
that
would
live
in
the
gitlab
client
package
and
then
all
the
vs
code,
specific
stuff,
usually
is
prefix
with
vs
code.
So
that's
kind
of
the
way
that
we've
tried
to
use
packages
to
create
some
boundaries
with
how
the
app
is
laid
out.
A
And
then
scripts
is
just
like
some
development
scripts
and
then
you
have
all
you
know
the
the
sundry
of
build
and
lending
files
that
show
up
in
every
every
project.
But
the
package
is
probably
the
most
strangest
thing
to
newcomers
of
the
project.
But
if
you've
ever
worked
with
a
mono
repo
before
something
like
that,
then
it
should
feel
somewhat
at
home,
and
the
packages
is
an
introduction
into
this
document
that
I
want
to
share,
which
lays
out
the
architecture
of
what
the
packages
do
and
what
each
package
kind
of
produces.
A
A
Looking
like
is
we
have
two
folders
and
so
right
now
I'm
inside
of
node
modules
and
our
main
gitlab
project
and
I'm
inside
of
the
gitlab
web
ID,
or
this
at
gitlab
web
ID
I
want
to
show
you
the
output
of
the
package.
So
then
we
can
get
a
feel
of
like
okay.
These
are
the
artifacts
that's
being
consumed
by
Main
gitlab,
and
then,
where
do
they
come
from
in
the
gitlab
web
ID
project?
C
A
So
it's
just
bootstraps
vs
code
with
our
web
ID
engine
inside
of
it
doing
its
thing,
but
where
does
it
get
all
the
vs
code
assets
and
because
vs
code
kind
of
expects
a
certain
layout
from
how
it's
being
served
up?
That's
what
this
dist
public
directory
is
so
like
this
main.
This
is
the
entry
point
of
that
iframe
that
we
kick
off,
but
then
you
see
like
vs
code.
A
Don't
don't
bundle
these
just
just
host
them
as
it's,
and
so
when
we
actually
visit
the
web
IDE
here,
let's
do
it
when
we
actually
visit
the
web
ID
here
we
see
we
pull
in
all
of
our
main
webpack
chunks
and
stuff.
Yes,
yes,
yes,
yes,
yes,
and
then
all
of
these,
like
just
come
from
that
dist
public
folder,
just
right
into
vs
code,
extensions
and
like
this
is
these
are
all
vs
code
stuff,
and
so
these
aren't
bundled
into
the
webpack
they're
just
hosted.
B
A
It
makes
sense,
awesome,
I'm,
not
sure
if
it
makes
sense
to
me.
That's
why,
if
I,
if
I,
keep
saying
it,
it's
probably
because
I'm
like
it
still
makes
sense
right,
foreign,
okay,
yeah.
So
that
brings
us
to
this
document.
So
this
big
box
shows
the
this
big
box
shows
a
split
between
the
lib
index,
which
is
that
code
that
gets
that
gets
imported
by
webpack
and
then
all
the
stuff
that
gets
just
hosted.
A
So
we
have
main.js,
which
is
like
our
main
entry
point
to
that
iframe.
We
create
the
vs
code
bootstrap
package
bootstrap
is
such
a
bad
name,
but
it's
that's
what
it's
called
it
bootstraps
vs
code,
and
so
this
is
the
main
entry
point
to
the
iframe
that
we
create
in
the
entry
point
package
and
so
all
of
like
the
vs
code,
entry
point
configuration
parameters
of
like
what's
our
social
URL.
A
What
are
the
URLs
that
we
need
to
look
up
our
CDN
assets
from
a
whole
list
of
large
amount
of
like
product
configuration
information
that
vs
code
lets
you
put
at
the
entry
point
all
that
lives
here
so
anytime
we're
talking
about
injecting
stuff
at
vs
code.
Startup!
That's
kind
of
this
package's
responsibility
we
try
not
to
do.
The
goal
is
to
lean
into
vs
code's
extension
API
as
much
as
possible,
and
so
the
heart
of
the
web
ID
is
probably
implemented
in
this
built-in
gitlab
web
ID
extension.
So
you
can
actually
View.
A
They
live
inside
of
here
of
the
extension
API,
but
we
see
then
like
this
bit
includes
if
it's
like
that
file
system
package,
because
we're
going
to
have
a
file
system
and
the
gitlab
API,
API
client,
and
on
so
on.
So
this
is
a
nice
document,
for
the
goal
is
to
have
packages
that
have
a
clear
responsibility
and
I
kind
of
lay
out
describe
and
words
the
packages
responsibilities
here,
and
so
those
responsibilities
shouldn't
really
change.
A
A
Okay,
cool
yeah
I
want
to
show
that
and
then
and
then
I
think
it'd
be
neat
to
just
get
a
feel
for
what
kind
of
them
are's.
You
can
come
down
the
pipeline
and
like
see
the
kind
of
changes
and
the
kind
of
packages
that
get
touched
so
there's
a
whole
bunch
of
so
here's.
Here's
an
example
of
where
we
just
updated
the
vs
code
extension
reference,
because
there
was
new
feature
development
that
we
want
to
include,
and
so
from
the
web
ID
project.
A
All
we
did
since
it's
a
sub
module
right
now
is
the
sub
module
commit
just
had
to
be
updated.
We
have
a
CI
job
to
make
sure
that
this
is
actually
released
version
of
the
vs
code
extension
project,
so
this
is
pretty
straightforward,
probably
as
a
reviewer,
the
main
task
is
just
doing
a
smoke
test
of
making
sure
everything
still
works,
which
we
will
become
very
familiar
with
how
to
do
and
a
little
bit
I.
Don't
know,
let's
see
what
other
interesting
ones
document
updates
are
not
interesting.
A
This
is
a
back
part
of
a
security
fix,
so
we
have
documented
like
a
security
process.
If
we
need
to
do
a
security
release,
this
has
already
been
released.
So
this
is
why
it's
showing
up
in
the
main
project.
Now,
let's
look
at
this
one,
so
vs
code
has
built
into
it
its
own
CDN
that
we
want
to
use.
We
don't
want
to
depend
on
anything
outside
of
servers
that
we
control,
and
so
this
is
updating
some
of
the
configuration
to
wrap
point
to
a
CDN.
A
It
required
a
update.
At
the
same
time,
there
is
a
fork
update
that,
because
they
did
have
some
hard-coded
references
to
their
vs
code,
CNN
CDN,
that
we
wanted
to
also
remove.
So
at
the
same
time,
we
also
updated
this
vs
code
version,
which
is
located
in
the
vs
code,
build
package.
So
if
I
go
back
to
here
and
the
gitlab
web
ID
and
packages,
we've
talked
a
bit
about
vs
code,
bootstrap
vs
code
build
is
interesting
because
there's
no
source
files
here.
A
The
only
thing
that
lives
here
is
this:
that's
the
only
thing
that
lives
here.
That's
interesting
is
this
Json,
which
is
just
a
pointer
to
where
do
we
download
the
package
and
then
some
metadata
information
about
that
package
and
then
a
make
file
which
is
includes
Autos
it
become
this
How
Does.
It
include,
become
the
folder
in
the
disk
directory.
A
A
It
so
that
was
pretty
run-of-the-mill
nice
change.
When
we
look
at
one
look
at
it.
Let's
look
at
this
one.
This
one
touch
is
an
interesting
package,
so
there's
a
link
to
here
to
the
vs
code
extension
an
MR
from
there
and
both
of
these
both
of
these
Mrs.
So
this
is
the
web
idmr
and
then
there's
a
corresponding
vs
code
extension
Mr.
The
reason
that
these
Mrs
need
to
come
in
pairs
is
because
they
touched
a
very
special
file
that
lives
inside
of
web
IDE
interop.
A
A
A
That
knows
how
to
be
somewhat
context
aware,
and
so
you
could
probably
we
could
spend
you
know
a
couple
of
minutes
and
think
of
100
different,
better
ways
to
do
this,
but
right
now
the
way
that
this
interop
is
consumed,
the
clarity
and
consumed
and
the
web
ID
and
by
its
clients
is
we
have
a
file
that
we
just
got
to
keep
in
sync
in
the
two
projects.
So
whenever
this
is
touched,
there's
a
comment
here
at
the
top
of
we
gotta
change
it
over
elsewhere.
A
So
that's
why
it
is
common
pairs
because
we
touch
the
web
ID
interop
here,
and
so
we
updated
the
corresponding
file
over
here
as
a
reviewer
for
the
web
ID
project
I
would
just
want
to
be
aware
of
like
okay
I'm
touching
this
file.
I
have
no
idea
what
this
file
is
about.
Let
me
check
out
the
files
like.
Oh
it
says:
I
need
to
keep
it
up
to
date,
and
so
I
would
ask
maybe
the
reviewer
that
we
keep
it
up
to
date
and
we're
pretty
good.
A
Thankfully,
this
type
change
is
pretty
backwards
compatible.
So
there's
nothing
like
super
breaking
here,
but,
along
with
allowing
these
request
objects
to
receive
headers,
they
also
had
to
implement
the
behavior
to
receive
the
headers,
so
that
showed
up
in
the
client
package
which,
rather
than
just
taking
just
your
own
ramps,
now
also
taking
headers,
and
so
then
here
in
the
vs
code
extension
project
that
those
types
and
the
things
that
reference
the
types
the
contributor
just
followed
the
trail
and
that's
about
it.
A
So
that's
one
of
the
great
things
about
revealing
the
in
this
project
that
both
Enrique
and
I,
who
frequently
contribute
this
project,
feel
is
because
of
typescript
I.
Do
not
spend
a
lot
of
time
like
having
to
check
for,
did,
I
call
a
thing
correctly
kind
of
bugs
that
happen
in
the
main
project,
because
it
would
wouldn't
even
build
if
you
weren't
referencing
the
types
correctly.
So
a
lot
of
the
changes
start
with
the
type
is
changing,
and
then
it
just
trickles
from
there
of
okay.
A
A
A
So
this
is
all
just
very
specific.
With
this
Mr
reading
the
title,
we
can
kind
of
pull
that
okay,
there's
two
classes
to
be
interested
in
there's
a
default
and
a
deprecated,
and
if
you're
coming
across
this
in
a
review
and
wanted
to
know
more
context,
this
is
where
man
just
ask
a
question
in
the
slack
Channel
and
there's
a
number
of
people
that
are
familiar
with
the
history
here,
you
could
also
look
at
the
commit
history
to
kind
of
get
a
feel
for
why.
A
This
is
how
we
want
to
make
requests,
but
previously
we
kind
of
had
this
wild
west
gitlab
client
very
similar
to
the
API
module
and
the
JavaScript
on
the
main
gitlab
project
and
we're
deprecating
it,
because
we
want
to
just
use
one
way
of
making
requests,
and
so
this
project
was
all
about
making
sure
can
we
do
everything
the
deprecate
a
project
client
was
doing?
Can
we
do
it
in
the
new
default
GitHub
client
and
it
required
making
a
number
of
like
type
changes,
for
instance,
here
in
the
web,
ID
interop
every?
A
A
This
the
change
just
spreads
because
loads
of
stuff
are
referencing
the
types
because
everything's
typescript
and
we
have
it
strict,
like
you-
can
have
a
little
bit
of
security
that,
like
okay,
at
least
we're
not
running
into
the
whole
set
of
bugs
that
can
happen
when
we're
referencing
types
incorrectly,
so
making
sure
that
the
modules
just
make
sense
is
goes
a
long
way,
but
this
this
Mr
was
introducing
a
lot
of
changes
at
once.
So
it's
this
is
probably
as
as
big
and
as
gnarly
as
as
they
might
come.
A
B
Yeah
I
I
have
a
question
about
because
I
I
saw
that
you
have
a
bunch
of
Mrs
and
basically
you
need
to
as
a
reviewer.
You
need
to
take
care
of
the
changes
in
in
the
packages
and
versions
and
everything
else.
But
is
there
any
way
to
mount
this
like
to
test
the
Mrs
locally?
And
how
do
you
do
that?
Yes,.
A
Great
questions,
great
question
and
that's
that's
a
great
segue,
and
to
the
next
thing
we
should
probably
talk
about.
So
that's
one
of
the
Great
one
of
the
biggest
wins
we
get
from
this
being
separated
from
the
main
gitlab
project
is,
we
can
run
it
outside
the
GDK
very
easily,
and
so
I'll
show
you
how
I'll
show
how
we
can
do
that.
We
can
also
run
it
inside
the
GDK
easily
too,
and-
and
we
can
dive
into
that
as
well,
although
it's
not
usually
necessary,
but
before
I
before
I
dive
into
demoing.
C
Have
a
question
so
we
have
different
packages
within
the
web.
Ide
right,
I
guess
I
wanted
to
ask.
If
they
do,
they
ever
have.
Are
there
any
dependencies
that
like,
for
example,
a
package
one?
Has
this
specific
dependency
and
I
guess
like
do?
We
have
have
you
encountered
any
problems
like
updating
one
and
then
having
to
yeah.
B
A
B
A
Also
possible
to
add,
like
just
shared
package
dependencies
and
the
root
level
package,
Json.
Okay,
clearly
it
looks
like
we
don't
do
that,
except
for
like
for
some
Dev
dependency
stuff,
but
that's
that's
a
possibility
if
we
ever
find
a
way.
You
know
things
to
improve
with
this
and,
if
you're
like,
oh,
how
come
we
don't
do
it
this
way,
that's
just
so
obvious
that
we
should
improve
things
in
this
way.
B
A
Yeah
I,
honestly
I,
don't
I,
don't
find
myself
thinking
about
it
a
lot,
but
there
is
here
in
the
documentation.
You
can
see
working
with
packages,
and
so
we
have
like
here's
how
to
add
a
new
package.
So
this
is
using
yarn,
workspaces
and
yarn.
Two.
Has
this
built-in
feature
where
we
can
declare
what
they
call
workspaces
and
we're
calling
packages.
A
And
so
it's
kind
of
it's
kind
of
out
of
the
box,
but
we
have
kind
of
if
you
are,
if
we
are
introducing
a
new
package
which,
like
hasn't,
had
to
happen.
You
know
this
is
very
rare
that
this
has
to
happen.
Here's
kind
of
the
steps
that,
like
okay,
we
want
to
make
sure
we
have
the
package
Json
and
so
it's
using
typescript.
A
We
also
need
to
make
sure
it
has
a
typescript
Json
for
this,
and
so
we
just
kind
of
follow
these
steps,
and
then
we
have
our
new
package,
how
to
add
like
a
dependency
from
a
package.
So
this
we
don't
have
to
reference
versions
inside
of
the
mono
repo.
We
don't
reference
specific
versions,
We
just
say
so.
A
If
I'm
here
inside
of
this
package,
gitlab
web
ID
and
I
want
to
import
from
web
ID
types,
I
just
say,
give
me
the
workspace
version,
and
that's
yarn
knows
how
to
resolve
this,
and
and
it
resolves
it
really
nicely
where
it
actually
Imports
doesn't
mess
with
Sim
links
or
anything
like
that.
So
like
this
is
better
than
lerna,
which
was
the
the
predecessor
monorepo
tooling
tooling,
and
that
could
run
into
that
was
a
lot
more
difficult
to
use
than
yarn
workspaces.
I,
don't
I,
don't
find
myself
thinking
about
it.
A
B
A
A
A
But
when
I
do
start
example,
it's
also
keeping
watch
for
changes.
So
if
I
make
a
change,
it'll
automatically
rebuild
so
I
can
as
I'm
contributing
or
if
I'm
testing
something
out.
I
can
I
can
see
that.
But
it
serves
everything
up
in
this
in
this
URL
which
I'm
going
to
open
in
Chrome,
because
we
don't
have
cash
breaking
and
the
assets
that
get
served
up
yet.
A
It
does
not
disable
the
cache
of
some
things
that
get
served
up
from
these
web
workers
and
service
workers.
So
I've
noticed
Firefox
not
being
super
reliable
and
that's
definitely
something
we
need
to
improve
with
our
developer
experience,
but
I
started
the
example
project,
and
this
looks
nothing
like
we've
seen
so
far,
and
it's
a
very
wonky
weird
form-
and
this
is
all
coming
from
this
example
package,
so
example-
gets
imported
by
nothing.
A
This
doesn't
ever
have
to
happen
to
the
main
app
because
we
can
just
take
advantage
of
having
the
users
session
cookie
to
authenticate
with,
but
when
you're
in
a
totally
separate
app,
we
gotta
somehow
authenticated
so
we'll
keep
track
of
it
with
the
token
I
have
included.
This
is
mostly
me
just
saying
like
hey.
This
is
an
example
app.
If
you
want
to
put
a
production
token,
that's
on
you.
A
That's
that's
me
trying
to
make
sure
people
think
twice
before
doing
that,
but
it
should
be
fine
if
you
wanted
to,
but
I'm
not
going
to
so
I
can
run
this
without
a
token,
and
it's
going
to
on
the
ref
for
the
web.
Id
project
is
Main,
so
we
run
this
without
a
token,
and
oh
I
was
playing
this
before
so
it
was
doing
stuff.
A
You
saw
a
little
modal
pop
up,
which
I
instinctively
close,
but
it
just
opens
everything
in
a
read-only
when
it
detects
that
you
you're
not
authenticated
so
I
can
still
test
some
things
out
in
this
way,
and
I
can
just
do
like
some
smoke
testing
in
this
way,
which
which
we'll
do
often-
and
in
fact,
because
this
is
all
this
example-
app
actually
gets
produced
in
our
in
our
pipelines
so
I'll
even
from
time
to
time
the
artifact
is
gone.
It
was
removed
three
days
ago.
A
Let's
go
to
different
one:
let's
go
to
yeah.
Let's
look
at
this
one
that
Enriquez
to
it.
Maybe
this
this
one
will
do
it.
Hopefully
it's
building
yeah
this
one
builds.
So,
let's
check
this
out.
I,
don't
know
what
Enrique
is
doing,
but
we'll
we'll
see
so
I
can
browse
the
build
jobs,
artifacts
and
jump
into
example,
disc,
index.html
and
then
jump
into
it,
and
now
I
can
run
the
example
app
from
the
MR,
so
without
even
checking
out
locally.
A
So
I'll
do
this
a
lot
too,
and
since
this
does
include,
you
know
some
cash
breaking
thing.
I,
don't
necessarily
need
to
do
worry
about
whether
I'm
in
Firefox
or
Chrome,
whatever
something
like
that,
but
yeah
I
can
test
things
out
without
even
checking
out
locally
from
this
example
app,
which
is
really
cool.
So
we
could
test
merge,
requests
out
this
way.
A
Yeah,
let's
see,
there's
one
other
really
cool
way
to
test
things
out,
but
wait,
there's
more
there's
this
manual
job
Enriquez
would
be
like
what
are
you
doing
to
my
Mr
there's
this
manual
job
of
where
you
can
create
a
development
package?
Oh
wait!
This
is
the
other
Mr
that
was
already
merged,
we're
going
back
to
Enriquez.
A
There's
this
manual
job,
where
we
can
create
a
development
package
that
all
right,
when
this
runs
it
basically
gives
me
I-
can
get
a
URL
that
I
can
include
in
my
I
can
update
on
my
local
gdks
gitlab
web
ID
to
instead
of
pointing
to
this
npm
version.
I
can
have
it
points
to
that
tarball
that
gets
produced
from
the
job
artifact,
and
so
this
way
I
can
test
just
with
my
local
GDK.
What
would
this
new
web
ID
version
be?
A
B
A
B
B
A
Man,
that's
a
good
question.
That's
a
really
good
question!
So
that's
this
is
some
history
to
the
one
of
the
reasons
all
this
got
released
really
really
quickly
was
our
remote
development
offering
was
the
very
an
alpha
POC
version
of
it
got
coupled
to
the
web
ID
environment,
because
I
guess
the
way
that
we
kicked
it
off,
that
you
could
connect
to
a
remote
connection
was
with
this
button
here
that
was
produced
in
the
web
ID.
A
So
a
user
could
click
this
and
enter
some
sort
of
remote
development,
environment
and
then
they'd
have
a
whole
integrated
term
working
terminal
browser,
editing
environment
provided
by
gitlab,
which
is
really
cool,
but
this
is
actually
not
the
current
state
of
the
remote
development
at
all.
We
have
our
own
workspaces
that
you've
probably
saw
advertise
advertised.
Maybe
that's
not
very
weird,
but
it
kind
of
seems
like
it's
advertised.
You
kind
of
see
it
advertised
here,
so
this
is
actually
the
way
work.
A
The
remote
development
environment
works
now
not
through
this
way,
which
means
we
might
actually
probably
be
able
to
get
rid
of
this
button
at
something
probably
have
to
check
on
and
which
means
we
probably
can
get
rid
of
all
of
this
setup
as
well
too,
but
all
of
that
is
like
here
we
would
where
the
user
was
expected
to
put
in
these
parameters.
Okay,
we
can
test
that
out
through
our
example
app
in
this
way,
so
we
had
two
different
kind
of
Entry.
The
way
that
the
web
ID
could
start.
A
One
is
hooking
into
a
remote
development
environment
where
the
terminal
actually
works.
You
can
run
commands
and
stuff
like
that,
which
is
kind
of
neat
and
interesting,
but
the
current
workspaces
isn't
actually
thought
out.
Implementation
of
the
kind
of
experience
users
would
expect,
rather
than
having
to
manually,
enter
this
thing.
A
A
A
Okay,
so
I
want
to
I
want
to
share
there's
just
two
minutes
left
I
want
to
just
familiarize
ourselves
with
one
more
other
than
I
want
to
highlight.
There's
so
many
things
we
want
to
prove
here
so
like
as
a
reviewer,
don't
ever
feel
like.
If
you
see
something
that's
pre-existing
like
oh
I
guess
this
is
the
way
we
wanted
it
to
be.
A
Diagram
so
the
vs
code,
bootstrap
it
Imports
mediator,
commands
and
then
the
extension
also
Imports
mediator
commands.
So
these
are
special
commands
that
get
executed
outside
of
the
extension
sandbox
vs
code
runs
every
institution
extension
in
a
very
tailored
sandbox
for
security
reasons,
so
that
when
you
download
extensions
with
extension
Marketplace,
it
can't
really
make
a
muck
of
things,
which
is
great,
but
it's
not
great
when
we
want
to
piggyback
off
of
the
user's
cookie
to
make
authenticated
requests.
So
the
current
architecture
for
implementing
the
seamless
skid
lab
web
ID
experience
is.
A
We
have
a
set
of
commands
that
when
we
need
to
make
API
requests,
they
go
through
these
mediator
commands,
and
so
we
have-
and
that's
also
how
the
vs
code
extension
project
the
git
lab
vs
code
extension
project.
It
looks
for
those
mediator
commands,
so
this
weird
package
declares
a
whole
bunch
of
commands
and
commands
is
like
a
vs
code,
specific
thing
that
you
can
just
run
based
off
of
the
title
of
the
command,
but
we
have
in
the
web,
ID
interop.
A
You
will
have
a
these
media
commands
that
we
declare
fetch
from
API.
So
anytime.
We
make
need
to
make
an
API
request.
We
call
that
mediator
command
and
because
it's
running
outside
of
the
extension
sandbox,
it
automatically
picks
up
the
the
user
session
context.
So
that's
one
of
the
magic
sauce
of
how
the
web
ID
works.
Is
this
weird
mediator
commands
package,
but
then
man
that
was
that
was
about
you
know,
that's
that's
kind
of
it.
A
So
we're
gonna
spend
the
the
next
bit
of
time
actually
pairing
at
something.
So
we
can
feel
what
it's
like
to
make
a
change
through
all
of
it
and
and
then
we'll
go
from
there.
So
yeah
thanks
for
listening
and
and
participating
I'm
I,
don't
I'm
still
here.
So
if
you
want
to
talk
some
more
or
ask
questions
about
it,
I'm
still
here,
but
we
could
we
can.
We
can
call
it
or.