►
Description
All Jamstack Updates: https://gitlab.com/gitlab-org/incubation-engineering/jamstack/meta/-/issues/5
A
A
A
Let's
imagine
I
have
this
source
editor
here.
This
is
just
a
random
page.
I
threw
together
for
the
purpose
of
this
demo,
but
it's
loaded
with
the
yaml
source,
editor
extension,
and
it's
got
all
this
yaml
content.
Don't
care
about
the
content
right
now,
but
just
for
demo
now,
let's
say
I
want
to
interact
with
the
values
of
that
file
in
the
front
end.
A
I
now
have
several
abilities
and
I'm
going
to
demo
that
one
the
extension
contains
a
parser
stringer
file.
It's
this
one
from
this
package
called
just
called
yama,
so
I
can
now
go
in
and
say,
editor
get
doc,
and
now
I
get
this
document
object
from
the
yaml
package
that
I
can
now
interact
with
and
modify.
A
A
A
We
can
now
just
go
to
editor
set
data
model
and
it
will
do
the
whole
stream
stringification
for
us
and
it
works
the
other
way
around
too.
Let's
do
editor
get
data
model
and
we
get
a
js
object
again
now,
if
you
need
to
inject
comments
with
plain
javascript
objects,
this
is
also
something
I
have
added
to
the
extension
marker
property
as
a
comment
by
using
a
hash
asset
key
or
by
prefixing
its
key
with
a
hash
sign
or
for
erase
just
prefixing
the
string
with
a
hash,
and
it
will
become
a
comp.
A
That's
still
not
all
the
extension
can
do.
It
can
also
highlight
certain
parts
of
the
yaml
when
being
passed,
a
path
to
it.
I
can
call
editor.highlight
with
a
path
and
it
will
find
that
place
inside
the
yammer
and
add
the
line.
Highlights
and
it'll
also
expose
the
locate
function
that
is
used
by
the
highlight
method.
A
So,
if
there's
ever
the
case
that
you
need
to
know
what
kind
of
line
numbers
a
certain
part
of
the
yama
is
in,
you
can
just
run
locate
and
it
will
return
those
line
numbers
you
see
all
this
is
available
in
master
as
of
this
week.
So
this
is
pretty
useful
and,
of
course,
I'm
my
own
best
client
and
I'm
using
it
in
the
pages
onboarding
wizard.
A
I
mean
this
is
was
a
short
week
because
of
contribute,
but
I
went
down
another
rabbit
hole
on
that
in
order
to
make
the
tests
better.
I
needed
to
abstract
the
components
used
for
this
a
little
bit
more
and
when
I
started
abstracting,
I
thought
why
don't
I
go
all
the
way
attract.
Not
only
the
input
fields
also
abstract
this
step
page,
maybe
just
abstract
the
entire
wizard,
and
this
is
what
I'm
halfway
through
doing
today,
and
the
idea
is
that
I
create
this
pipeline
wizard.
A
A
It
then
contains
a
template
of
the
yammer
bit.
It
will
inject
into
the
users.gitlab
ci
yaml
in
the
front
and
later
so.
This
yaml
file
is
basically
going
to
be
an
instruction
to
the
onboarding
wizard
on
how
it's
going
to
look
like,
and
if
this
works
there
could
be
a
template
like
this,
not
only
for
pages
but
for
literally
anything
apps
deployments
packages.
A
We
could
get
the
community
to
contribute
their
own
wizards.
We
can
have
admins,
maintain
their
instant,
specific
wizards
yeah.
Okay,
I'm
getting
a
bit
ahead
of
myself,
we're
just
not
there
yet,
but
I
like
to
entertain
the
idea
and
we'll
see
how
it
will
go
now.
This
was
the
update
for
this
slightly
shorter
week
and
I
will
be
off
next
week
because
I'm
moving
to
germany,
but
we
will
see
each
other
again
in
the
week
after
that
and
until
then
I
say
goodbye.