►
A
In
the
last
update,
I
demonstrated
a
wrapper
around
the
source
editor
that
allowed
to
do
two
things:
one
print
yaml
from
a
javascript
object,
similar
to
jsc
hamlet's,
dump
function
but
extended
with
the
ability
to
add
certain
properties
as
comments
and
number
two
highlight
certain
sections
in
the
editor,
as
triggered
by
events
since
the
last
update
I've
refined
this
and
created
a
source,
editor
extension.
A
Thanks
to
this
package,
I
can
now
not
only
stringify
javascript
objects,
but
I
can
also
parse
existing
yaml
files
and
get
an
abstract
syntax
tree
or
ast
that
the
extension
exposes
and
that
I
can
interact
with
the
extension
now
adds
five
important
methods
to
the
editor.
One.
The
set
data
model
function
can
be
passed,
the
javascript
object.
This
will
be
stringified
into
yaml
in
the
editor
two.
The
highlight
method
accepts
a
path
to
any
node
inside
the
yammer
and
then
adds
a
line
highlight
behind
that
property.
A
This
is
equivalent
to
what
we
had
before,
but
now
it
also
works
with
yaml
that
has
been
constructed
before
outside
of
this
extension
number
three.
The
get
dock
and
set
dock
functions
basically
are
an
interface
to
the
ast
exported
by
the
yama
package.
So
this
exposes
all
the
functionality
that
the
yaml
package
offers
like
functionality,
adding
comments,
updating,
notes,
anything
ready
and
number
four
the
locate
function.
A
A
The
yaml
package
itself
adds
the
ability
to
functionally
add
comments
in
this
extension.
I've
also
added
the
enable
comments,
construction
option
that
allows
comments
to
be
declaratively
injected
using
the
data
model,
the
syntax
for
that
declaration
hasn't
changed,
but
the
implementation
now
uses
entirely
the
yaml
package
for
stringifying.
A
A
If
it
starts
with
a
hash,
then
pipe
and
the
key
of
another
property,
it
will
be
interpreted
as
a
comment
to
that
property
and
inject
it
before
that
in
race.
It's
a
bit
simpler
if
we
have
a
string
that
starts
with
a
hash.
That
string
will
be
converted
to
a
comment
at
the
position
it
was
defined
in
in
the
array.
A
A
A
I
know
our
next
release
has
a
per
source
rate
limiting
for
access
to
pages,
which
is
a
measure
of
protecting
gitlab,
but
the
ideal
solution,
I
hope
to
see
at
some
point-
is
using
a
cdn
like
cloud
flare
or
fastly
in
front
of
pages.
That'll
not
only
get
the
pressure
off
the
gitlab
service,
but
it
will
also
boost
performance
for
users
outside
the
us.
A
A
lot
at
the
moment,
I'm
mostly
just
investigating
the
history
of
the
the
relation
between
cdns
and
gitlab
and
trying
to
come
up
with
ideas
on
how
to
implement
it
with
pages
on
a
very
high
level.
If
you
have
any
input,
let
me
know
and
there's
the
cdn
epic
in
the
jamstack
project,
where
I'm
collecting
just
ideas.
A
Another
item
that
came
up
in
october
was
the
jam
stack
conf
hosted
by
netlify.
It's
actually
targeted
more
to
end
users,
but
it's
a
really
great
resource
to
see
where
people
at
what
are
the
upcoming
issues.
I'm
currently
working
through
some
of
the
recordings,
and
I
hope
I
can
put
together
a
summary
of
the
parts
that
are
relevant
to
us
at
some
point.
There's
again,
this
jumpstack
conf
issue
in
the
jamstack
meetup
project,
I'll
update
that
as
I
go
along,
let
me
know
for
any
feedback
again
again.