►
Description
In this session we deep dive into some architectural considerations around the gitlab-web-ide project.
https://gitlab.com/gitlab-org/gitlab-web-ide/
00:00 Intro
27:40 Package Architecture
A
Okie
dokie
all
right
and
let
me
start
not
just
recording
but
also
sharing
my
screen
and
let
me
introduce
you
to
the
gitlab
web
ID
project
and
then
I
want
to
walk
through
because
we're
doing
it's
kind
of
a
mono
repo
approach.
So
we
can
have
nice.
Cohesive
packages
does
huge
maintainability
when
and
try
to
make
this
as
easy
to
work
with
as
possible.
So
if
you
do
run
into
issues
with
this,
we
want
to
know
that
so
that
it's
because
so
far
it's
profitable
made
from
a
maintainability
perspective.
A
A
A
Has
a
this
whole
repo
has
a
Pages
deployment
for
the
example
package,
which
consumes
our
main
artifact
from
this
repo,
and
so
you
can
run
you
know
the
main
branch
build
gets
deployed
to
pages,
and
these
are
like
the
entry
point
parameters
that
kick
off
our
main
packages.
Entry
point
function,
any
main,
gitlab
user
isn't
going
to
see
this
UI.
This
is
all
just
example:
code.
A
A
So
this
modal
thing
pops
up
and
yeah,
so
we're
just
building
out
the
features
here.
One
huge,
obviously
missing
feature
is
Source
control,
so
that's
a
bit
that
we're
refining.
So
we
did
the
technical
Spike
of
validating
that
we
could
do
this,
but
since
then
we
kind
of
changed
our
approach
to
it
for
reliability
reasons,
but
this
whole.
A
B
A
A
This
web
base
is
like
a
client
to
that
vs
code
server
and
that
can
actually
run
extensions
that
use
git
or
whatever
other
kind
of
backend
Services
needed.
So
that's
where,
from
architecture
perspective,
we'll
probably
use
extensions
of
like
having
this
client
only
extension
set.
That
uses
things
more
in
memory
and
in
the
browser
and
a
lot
of
those
will
be
unplugged
when
we
want
to
do
like
connect
to
the
remote
development
environment,
and
so
this
is
a
different
entry
point
function.
B
So
when
you
are
talking
about
remote
development,
you're,
not
talking
BS
code
server,
you
are
not
talking
about
the
same
remote
development
project
that
the
other
part
of
our
team
is
working
on,
because
when
I
I,
don't
I
I'm
not
like
completely
up
to
date
with
that,
but
they
are
talking
about
a
different
wrong
time.
That
is
not
vs
code
server
right.
A
C
From
what
we're
still
iterating
on
is
like
what
that
infrastructure
will
look
like
like.
Will
we
use
shea
to
you,
know,
spin
up
these
containers
and
remote
file
systems
and
stuff,
or
will
we
you
know
roll
our
own,
something
based
on
kubernetes
or
what
that's?
What
we're
we're
still
trying
to
decide?
Okay,.
B
A
Yeah
and
I
think
I
think
we'll
have
like
some
sort
of
for
every
every
remote
development
environment
they
get
spun
up
will
have
some
subset
of
container
setup
or
whatever.
That
would
probably
include
the
vs
code
server.
That's
needed
for
this
whole
thing
to
work,
I
think
so.
This
is
still
definitely
in
development,
and
so
we're
we're
solving
the
we're,
we're
doing
more
elaboration
and
early
development
on
that
orchestrating
part
of
it.
A
A
The
token
like
that
authentication
should
be
seamless,
and
even
these
URLs
and
stuff
so
like
what
what
we're
iterating
on
right
now
is.
We
have
some
sort
of
like
technical,
technical
demo
that
we
then
want
to
in
the
spirit
of
iteration,
integrate
into
what's
already
in
the
product,
but
behind
a
feature
flag.
A
So
it's
none
of
this
is
going
to
be
generally
available,
but
there's
there's
a
lot
of
desire
to
get
all
the
integration
pieces
set
up
since,
since
they'll
need
to
be
that
user
flow,
that
integration
will
still
need
to
exist
as
these
things
change.
So
that's
that's
the
main
goal
does
that
make
sense.
A
Here
we
go
so
we
can
check
out
the
developer
Docs,
but
even
just
says
we
can
start
by
running
this
example
locally,
so
we're
using
yarn,
but
we
use
yarn,
Berry
and
yarn
recommends
doing
this
by.
Actually
it
includes
the
version
of
yarn
in
the
source,
control
that
we
use,
and
so
yarn
actually
knows
to
look
for
that
and
knows
how
to
use
this
version.
A
So
if
you
run
yarn
version,
it's
going
to
be
grabbing
this
yarn,
even
though
this
one
that's
in
the
repo.
So
obviously
when
checking
out
round
yarn
install-
and
this
is
all
using
yarn
too-
which
does
and
with
the
plug
and
play
stuff,
so
it
doesn't
have
node
modules.
Don't
pay
no
attention
to
this
thing?
A
I,
don't
that's
gonna,
be
some
artifact
from
a
while
ago,
but
it
puts
all
of
its
stuff
in
these
in
this
cache,
but
there's
no
node
modules,
which
is
the
first
weird
thing
that
you'll
observe
with
yarn
plug
and
play.
But
the
best
thing
we
get
with
yarn,
Plug
and
Play
is
all
of
the
local
package.
References
get
resolved
seamlessly
without
semlings,
because
yarn,
Plug
and
Play
means
that
instead
of
node
resolving
require
statements.
A
Yarn
knows
will
resolve
requires
statements.
So
if
I
have
web
ID
vs
code
extension
here
and
I
can
depend
on
the
workspace
package,
web
ID,
EFS
or
whatever
so
everywhere,
I'm
requiring
here
gitlab
web
idfs
yarn
knows
how
to
resolve
that
to
this
local
directory,
not
using
Sim
links
or
anything
else
like
that.
So
that's
one
of
the
best
things
we
get
with
the
Plug
and
Play
system,
and
so
there's
the
yarn
documentation
for
all.
This
is
really
really
good,
but
basically
what
they
end
up.
A
So
the
reason
I
bring
all
this
up
is
there's
a
lot
of
out-of-the-box
support
for
yarn
plug
and
play,
but
you
might
run
into
situations
where
some
sort
of
development
tool
or
editing
environment
does
not
can't
recognize
like
your
plugins
and
stuff,
and
a
lot
of
that
just
means
it's
trying
to
use
node
raw
node,
like
your
Global
node,
to
install
things
rather
than
your
local
yarn,
environment,
and
so
one
of
the
most
here
in
our
developer.
Docs.
A
Like
if
you're
using
vs
code,
you
need
to
tell
it
to
use
the
workspace
version
of
typescript
if
you're,
finding
like
weird
errors,
because
that
way
it
knows
how
to
resolve
the
things,
and
so
basically
any
kind
of
node
command
has
to
go.
You
either
need
to
run
it
through
yarn,
node
and
yarn.
That
means
yarn
is
going
to
shimmy
and
it's
required
resolution
or
there's
another
of
other
paths
based
on
what
you're
doing
so,
if
you
run
into
yarn
too
issues,
let
me
know.
C
A
You
don't
have.
That
was
an
issue
too.
It
was
like
you'd
have
to
if
I
did
a
clean
I'd
always
have
to
like
tell
learn
how
to
do
its
thing
to
recreate
the
some
links
and
stuff
like
that.
So
it's
like
from
just
my
experience.
I
know
this
has
worked
way
easier
for
me
out
of
the
box,
but
okay,
because,
like
I,
don't
have
any
specific
things
off
the
top
of
my
head
other
than
that
manual
step
of
creating
some
links
and
having
multiple
node
modules.
All
around
can
cause
confusion.
C
Because
there's
newer
tools
like
the
pnpm
that
they
give
you
like
more
speed
and
the
deduplication
or,
like
you,
know
the
single,
the
single
node
modules
store
and
like
this.
This
did
have
some
some
sharp
edges
around
tooling
and
like
trying
to
get
the
linking
to
work,
and
all
of
that
so
I
just
like
this
to
keep
in
mind
like
if
there's
other
things
that
give
us
these
same
benefits.
But
without
the
drawbacks
we
should
think
keep
them
in
mind.
Yeah
I,
don't
know.
A
There's
a
more
of
a
thankfully
I
think
from
everything
inside
of
packages
isn't
necessarily
like
super
coupled
to
the
fact
we're
using
yarn.
So
it's
like
yeah,
if
there's
a
better
tooling,
that's
something
we
could
explore
and
hopefully,
but
so
yeah
I
mean
that's,
definitely
I'm
I'm
not
going
to
be
close-minded
to
to
other
other
mono
repo
options.
Although
lerna
yeah
that
that
that
project's
not
even.
A
A
So
all
of
this
happens
again
right.
All
this
happens
automatically,
but
it's
worth
being
familiar
with
what
it's
actually
doing
so
that
when
you
do
run
into
issues,
It's
usually
the
same
issue
and
you
could
fix
it
with
environment
variables
or
whatever
like.
If
we
run
into
issues
but
I
agree,
it
should
work
out
of
a
box,
but
this
highly
recommend
familiarizing.
B
A
All
right,
I,
gotta,
rant
about
this
I,
have
had
this
Mr
open
for
more
than
a
week
and
look
at
all
the
pipelines.
I
just
keep
every
day
like
trying
to
get
the
pipeline
to
be
green
because
it
keeps
running
into
weird
Master,
broken
things
and
then,
when
I
re-base
I
have
to
reset
all
the
approvals
so
frustrated.
This
has
been
really
frustrating
talking
about
turning
off
and
on
machines.
B
A
There
is
going
back
to
the
readme.
There
is
a
packaging
script
which
creates
the
gitlab
web
ID
package.
So
there's
really
only
one
main
artifact
produced
from
this
repository.
We
don't
we
don't
publish
all
of
these
packages,
it's
just
the
web
ID
package,
the
other
packages
are
kind
of
considered
internal,
and
so
we
can
create
a
development.
We
can
also
create
a
development
package
which
basically
calls
this
from
a
manual
job
on
a
pipeline
too.
A
So
you
can
create
like
a
local
tarball
package
that
way
and
there's
a
published
development
package
that
reads
the
artifacts
of
this
job
actually
published
to
npm
when
we
were
doing
that
and
since
we're
still
in
early
development,
everything
is
just
a
development
package.
Until
we
get
a
level
of
feature
complete
stability
here
and
when
I
show
you
the
way
the
packages
are
architected
it'll
make
sense
of.
What's
actually
in
this
main
package.
B
A
A
C
A
This
all
works
nicely
and
that
little
preview
pops
up
but
let's
say
I-
want
to
make
a
change.
So
this
is
the
main
workflow
I'm
going
to
go
to
the
we'll
talk
about
the
roles
of
these
packages
in
a
second
but
I
go
to
the
extension,
where
I'm
actually
showing
that
message
and
I'm
saying
we're
under
development.
Just
say:
hello:
world.
A
A
We
didn't
say
hello
world,
probably
because
good
thing
we
did
this
because
I
don't
have
local
cash
disabled
so
on
the
main
product,
these
all
of
the
assets
are
going
to
be
scoped
under
the
version
of
the
package
we're
consuming
but
locally
they're,
not
scoped.
So
you
might
need
to
keep
this
open
to
disable
the
cache.
If
you're
not
noticing
changes
reloading
now
we're
hello
world,
that's
great!
So
now
we're
we're
developing
and
that's
it,
and
so
we
also
have
unit
tests,
which
are
maybe
a
little
sparse
but
they're
there.
A
A
B
A
A
In
the
development
board
we
have
set
up
integration
tests
would
be
really
nice
really
want
to
do
that,
and
that
was
one
of
the
reasons
too,
of
moving
this
to
its
own
package,
because
we
don't
need
to
spend
out
the
whole
git
lab
back
end
and
everything
for
just
doing
some
more
even
visual
integration
tests
of
this
repo,
so
yeah
I
would
definitely
want
to
do
that.
The
goal
is
to
get
you
know.
A
C
Every
bar
is
great,
but
when
you're
under
the
covers,
like
look
at
look
at
the
VidCon,
some
of
those
demos
of
the
latest
Cyprus
and
playwright
like
either
crazy
fast,
they
don't
use
selenium
under
the
covers
they're
like
use,
newer,
Technologies
I
think
we
should
really
look
at
Slim's.
Just
painful
flaky,
like
yeah.
C
B
End-To-End
and
it's
not
unit
tests
either
it's
something
like
closer
to
to
the
the
operation
test
that
is
faster
and
allow
us
to
like
to
test
a
group
of
components
together,
yeah
insulation,
without
thinking
about
the
entire
page.
So
there
are
many
things
that
we
can
take
advantage
of
in
that
that
tool.
A
Yeah,
that's
awesome,
I
think
it's
worth
I!
Think
from
that
comment.
It's
worth
moving
to
talking
about
the
responsibilities
of
the
different
packages,
so
I
just
started
this
Mr
I'm.
Sorry,
this
hasn't
been
in
the
project
for
a
while
it's
needed
to
be,
but
I've
finally
got
to
write
it
out
and
unfortunately
it's
it's
not
styled
really
nicely
by
git
Labs
mermaid
thing,
but
I'm
gonna
try
to
use
this
to
talk
about
What's
Happening
Here.
A
A
A
But
what
we
get
also
with
this
package
is
are
a
whole
bunch
of
assets
that
we
need
to
self-host,
and
so
we
do
this
with
web
other
webpack
packages
that
have
bits
that
we
run
at
runtime
and
like
bits
that
have
scripts
that
we
have
to
pull
in
or
iframes
or
whatever
that
we
have
to
pull
in,
that
we
self-host
with
webpack
and
so
there's
a
there's,
a
dist
public
directory
in
this
web
ID
package,
which
these
aren't
imported
at
runtime.
These
are
just
self-hosted,
and
so
this
includes
a
main.js.
B
The
I
mean
before
we
move
on
there,
I'm,
not
completely
understanding
the
difference
between
self-hosted
and
imported
them.
From
time
like
when
you
are
running
on
a
JavaScript
application
in
the
web
browser,
everything
is
imported
on
runtime
right.
So
what?
What
do
you
mean
by
self-hosting?
What
do
you
mean
by
unfortunately,
one
time.
A
This
is
a
really
good
question.
So
let's
look
at
the
main
entry
point
here,
which
is
the
git
is
the
web
ID
package
and
our
index
file
here.
So
we
have
these
this
method.
These
are
main
entry,
point
methods
we
start
or
we
can
start
remote,
these
kind
of
so
then
you
know
they
call
this
base
method
of
starting
based
on
any
config.
You
have
we're
going
to
start
and
what
we
do
here
is
we
create
an
iframe
and
we
load
in
all
of
from
this
iframe.
A
A
We
have
to
treat
this
like
a
document
like
a
separate
document,
and
so
these
come
from
the
vs
code,
the
Raw
vs
code
built
like
our
CSS
that
we
have
to
import
and
the
other
like
the
workbench
main
workbench
scripts,
which
add
all
the
vs
code
globals
and
things
so
instead
of
raw
importing
these,
because
we
kind
of
need
to
spin
up
this
containerized
environment
and
the
way
these
scripts
are
built
is
this
is
this?
Is
that
browser
runtime
level
of
like
we're?
Not
we're?
Not
all.
A
These
scripts
are
like
writing
to
the
document,
and
things
like
that.
So
these
scripts
are
things
that
we
can't
just
import
from.
Here
they
are
self-hosted,
and
so
we
have
to
reference
them
somewhere,
and
so
that's
the
main
difference
here
is
we
have
our
main
if
I
look
at
the
package
Json
the
main
comes
from
lib
index.js.
A
A
So
let
me
go
to
this
project,
so
the
vs
code
bootstrap
its
main
output.
Is
this
main
JS
thing
which
is
this
is
the
this?
Is
the
main
script
that
that
iframe
that
we
create
runs,
but
what
it
does?
Is
it
loads?
All
of
these
vs
code,
Scripts
and
via's
code
uses
AMD
to
import
scripts,
and
so
it
expects
these
to
be
self-hosted.
A
A
interface
to
Define
new
modules,
based
on
other
modules
that
you're
requiring
and
it's
going
to
fetch
these
from
the
from
the
self-hosted
scripts.
So
part
of
this
is
an
artifact
of
how
vs
code
works
of
vs
code
is
expecting
all
of
its
infrastructure
to
be
self-hosted,
and
so
we're
we're
creating
a
bootstrapper
that
will
also
need
to
be
self-hosted,
which
knows
how
to
reference
all
that
stuff.
B
Okay
so
trying
to
recap:
we
actually
leave
slash
index.
That
is
the
code
that
we
that
we're
writing
that
we
are
gonna
import
through
the
in
the
we're
going
to
import
the
GitHub
in
the
gitlab
application,
using
the
module
system
that
is
used
by
gitlab.
That
is
webpack.
We
are
going
to
like
we're
gonna.
B
With
doing
gitlab
with
that
file,
then
everything
that
is
in
this
slash
public
is
using
its
own
module
system.
That
is
AMD
and
we
are
publishing
all
of
that
directly
without
any
pre-processing
perform
like
web.
So
this
is
something
like
we
can
imagine
that
as
a
an
application
that
everything
that
is
this
slash
public,
let's
open
an
application
that
is
already
built
and
ready
to
be
put
in
that
and
ready
to
be
deployed
in
a
in
a
static
student.
B
A
C
A
B
C
A
A
A
B
I
I
use
it
by
the
way
should
I
use
the
the
term
CDN
incorrectly
I.
What
what
I
meant
was
like
What,
if,
like
we
put
all
of
those
files
in
in
the
server
any
in
any
ways
like
in
any
place
where
we
are
deploying
the
JavaScript
files
to
be
used
by
the
application,
it
could
be
a
CDM,
but
it
could
be
like
yeah.
C
A
C
A
A
Vs
code,
if
it
did
100
yep
yeah,
so
that's
a
good
question,
and
so
yes,
this
main
module
that
we
import
from
the
main
gitlab
project
is
really
Slim.
And
it's
just
hey
we're
just
going
to
start
the
iframe.
The
majority
of
everything
you
see
is
actually
self-host
stuff
so
like
starting
at
the
right
hand
side
like
so
we
get
all
of
vs
code
assets
from
this
package.
Via's
code
build,
and
so
this
package
just
has
a
script
in
it.
For.
A
How
do
we
download
what
our
main
base
vs
code
version
that
we're
using
and
so
there's
actually
a
checked
in
file,
vs
code
version
which
links
to
one
of
our
vs
code,
Fork
releases
and
Source
control?
But
you
can
also
there's
if
you
and
the
developer
docs
there's
a
way
to
get
this
to
link
into
your
local
file
system
if
I'm
needing
to
work
on
both
the
fork
and
this.
At
the
same
time,
you
can
have
it
linked
to
a
local
file
system,
but
the
main
output
of
all.
A
C
C
B
C
B
B
A
C
B
B
A
A
A
So
this
is
actually
like
one
of
this
one
of
the
it
might
be
one
of
the
weirder
packages,
because
it's
not
a
JavaScript
package,
but
it's
definitely
one
of
the
simpler
packages,
because
it
does
something
really
straightforward
of
it.
Just
pulls
from
that
metadata.
That's
committed
to
Source
control,
the
vs
code,
release
that
ends
up
in
the
web,
ID
just
public.
A
The
other
more
significant
thing
is,
we
then
add
our
own
extension
has
to
live
alongside
the
other
built-in
extensions
within
vs
code,
and
so
we
have
a
web
ID
vs
code
extension
package,
which
is
the
main
output,
is
this
main.js,
and
this
this
is
very
important.
Vs
code
extension
metadata
package.json.
A
These
are
the
main
outputs
there
and
that's
where
a
lot
of
the
code
that
you
for
the
main
issue
is
that
you're
going
to
write
is
going
to
live
so
BS
code
has
a
whole
really
sophisticated
extension
API
and
the
only
way
we
get
to
interact
with
that
API
is
within
extension
land.
So
I
can't
I
can't
easily
like
create
a
modal
to
show
up
from
my
bootstrap
package,
because
I'm,
just
not
I,
don't
have
any
any
of
that
internal
vs
code
API
exposed
to
me
there.
A
A
C
A
So
this
is
one
big
build
of
like
so,
if
you
look
at
the
source
files,
there's
a
whole
lot
of
stuff
going
on
here,
so
we
have
some
vs
code,
implementations
of
vs
code
interfaces.
Here
we
have
a
main
entry
point
method,
but
we
use
es
build
to
bundle
all
of
this
into
one
file,
that's
which
is
the
extension
that's
going
to
run.
So
whenever
the
the
way
the
vs
code
extensions
work
is,
it
has
to
be
a
module
that
exports
and
activate
and
exports
to
deactivate
function.
A
Since
we
don't
really
allow
any
deactivating
of
this,
we
kind
of
really
only
have
an
activate
and
that's
where
we
get
to
do
our
API
methods
like
showing
the
warning
message,
and
we
have
a
whole
bunch
of
process
for
creating
our
file
systems
and
stuff
like
that.
So
this
is
where
a
lot
of
the
glue
code
of
our
in-memory
file
system
and
vs
codes,
API
will
come
together
and
the
same
thing
with
the
source
control.
This
is
the
glue
code
for
that
stuff.
A
What
I
love
about
separating
these
packages
is
now
to
just
solve
the
file
system
problem,
that's
its
own
package
and
we
have
tests
for
that
which
are
just
focused
on
you
know:
a
file
list,
nothing
vs
code
is
in
here.
This
is
just
about
creating
an
in-memory
file
system
that
we
can
use
to
manage
Source
control
and.
B
C
B
A
This
is
a
vs.
This
is
in
the
vs
code
extension.
This
implements
a
very
specific
vs
code
interface
file
system
provider,
but
you
see
that
it
takes
in
so
this
is
actually
an
adapter
pattern.
It
takes
in
our
own
file
system
interface,
so
we
really
want
to
decouple
what
does
it
mean
to
be
a
file
system
from
what
is
vs
code
say?
It
means
to
be
a
file
system
and
there's
a
whole
bunch
of
wins
there.
One
just
keeping
it
simple,
but
also
I
could
see
us
reusing
these.
A
A
The
other
weird
this
is
this
is
probably
the
other
weird
package
is
so
we
need
a
file
system,
but
we
also
need
to
communicate
with
the
gitlab
API
and
inside
extension
land.
So
these
are
all
notes,
I'm
going
to
write
into
this
document
too,
but
right
now
we
just
have
the
diagram
inside
extension.
Land
vs
code
is
really
nice.
It
gives
us
a
lot
of
really
great
methods
to
use,
but
we
are
in
a
sandbox
and
we
cannot
make
any
fetch
requests
or
anything
writing
to
the
document.
A
It
has
a
fairly
comprehensive
module
to
make
sure
Extensions
stay
in
their
place
for
securities
for
security
reasons.
So
the
only
way
for
an
ex
from
an
extension
to
like
break
out
of
that
sandbox
is
through
commands.
So
when
we
bootstrap
everything,
we
can
actually
give
vs
code
a
set
of
predefined
commands
and
when
we're
bootstrapping
everything
we
are
inside
the
iframe
context,
so
we
can
make
web
requests.
We
can
do
all
that
stuff.
A
A
These
commands
include
things
where
we,
we
start
everything
by
like
fetching
the
tree
in
the
project,
branch
and
stuff
like
that,
and
it
includes
fetching
the
raw
file
content
that
we
have
to
do
over
an
API.
And
finally,
this,
like
we're
ready,
we
loaded
everything.
So
if
we
needed
to
show
we
needed
the
the
get
let
main
gitlab
project
to
show
some
sort
of
like
spinner,
then
we
would
know
when
to
show
this
stuff
when
it's
all
said
and
done
and
finished.
A
So
any
of
this,
like
things
that
need
a
side
effect
that
communicate
outside
of
the
extension
sandbox
these
these
the
way
the
only
means
of
doing
this
is
with
these
commands,
and
so
these
are
all
cohesively
lived
inside
mediator
commands,
and
this
is
really
the
only
consumer
of
the
gitlab
API
client,
which
is
the
gitlab
API
client
just
makes
API
calls.
So
that's,
that's
all
that's
happening.
C
A
A
Highlighting
specific
parts
that
are
very
relevant
would
be
helpful,
but
in
our
package
Json
that
vs
code
reads,
we
have
to
declare
everything
that
we're
going
to
contribute
here,
which
would
be
like
a
commit
command
or
in
our
case,
in
the
issues
of
opening
the
remote
development.
We
had
like
a
open
remote
development
command
that
that
we'll
need,
but
all
of
this
isn't
happening
to
leave
the
extension
sandbox.
A
B
B
So
thank
you
so
much
for
for
this
introduction.
I,
don't
know
like
made
an
extent
for
me
is
really
more
about
yes
plug
and
play.
Maybe
if
you
come
share
with
me,
some
links
at
the
to
the
documentation
about
vs
code,
API
yeah,
the
ones
that
are
very
relevant
to
me.
I,
have
to
read
about
that
and
where
I
think
that
I
missed
like
I
feel
like
to
know
more
about
is
about
the
feature
that
we
are
working
on.
A
A
Cool
yeah,
let's
plan
on
it
and
yeah
we
can.
We
can
deep
dive
and
maybe
even
just
pair
a
little
bit
on
on
this
issue.
So
a
great
place
to
start
would
be
getting
the
example
running
and
then
maybe
applying
this
applying
this
patch
and
what
you'll
see
is
from
the
screenshot.
The
terminal,
then,
is
given
this
like
welcome
View
and
an
action
happens
when
you
click
that
button
and
so
we'll
get
to
I.
Think
then
reading
the
high
level
flow
is
kind
of
how
we
expect
it
to
behave.