►
From YouTube: GraphiQL Working Group - 2023-02-14
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
A
A
B
A
B
A
So
it's
probably
just
gonna
be
us.
Today,
I
have
a
bit
of
an
agenda
that
I
wrote
that
I
wrote
down.
B
A
The
first
one
is
pretty
simple,
and
it's
just.
It
was
gonna
talk
with
the
group
about
the
Cadence
of
this
meeting
because
it
seems
like
we're
not
getting.
You
know
very
often
it's
just
been
Thomas
and
I,
or
nobody
or
you.
A
A
couple
of
us
so
I
wonder
if
I
wonder
if
we
need
to
either
just
keep
it
at
a
month,
and
you
know
if
people
show
up
people
show
up.
It's
fine,
like
it's,
not
a
big
deal,
but
I'd
like
to
get
more
attention,
I'd
like
to
get
more
folks
showing
up.
So
if
we
did
yeah
every
two
weeks,
we
tried
for
like
a
couple
of
months
to
just
do
it
every
two
weeks.
Maybe
it's
a
timing
thing
for
people.
B
A
B
So
before
Thomas
joined
the
project,
it
was
still
just
once
a
month,
but
when
Thomas
joined
we
felt
like
it
was
necessary
because
there
are
so
many
conversations
going
on
about
2.0
I.
Think.
Another
thing,
too,
is
that
we
lost
like
about
half
the
contributors
are
interested
because
of
Monaco
right.
So
half
the
people
wanted
to
contribute
towards
Monaco.
When
we
didn't
give
them
Monica
over
2.0
I
mean
we
kind
of
chose.
B
We
chose
that
path
and
I
think
it
was
still
a
good
choice
but
I
think
at
least
it
led
to
people
feeling
like,
oh
well,
now,
Monaco's
never
going
to
be
part
of
graphical.
You
know
this
kind.
That
kind
of
I
hear
that
kind
of
will
it
ever
be.
That
kind
of
a
question
which
has
me
wondering
like?
Did
we
not
make
it
clear
that
we
still
plan
to
support
Monica
like
somehow
we
we
made
it
seem
like?
B
That's
not
the
plan
and
so
I
think
some
people
got
kind
of
disillusioned
over
that
as
potential
contributors,
but
I
think
if
we
show
that
the
3.0
road
map
has
Monaco
like
the
jump
to
Monaco,
it's
part
of
it
and
that's
why
we
have
to
break
some
of
the
graphical
props,
API
I,
think
that
will
attract
new
attention
again,
but
I
think
people
just
have
to
know
that's
on
the
road
map,
because
if
it's
not
that's
like
half
or
more
of
our
contributors
are
not
going
to
be
interested.
Yeah.
A
That's
a
really
good
point:
I
mean
I'm
a
little
bit
disillusioned
myself
because
we
started
you
know.
August
was
a
was
launched
for
two
and
then
September
and
I
guess
it
was
October
where
we
started
just.
A
Talking
about
what
the
next
version
was
going
to
be
right
and
then
the
October
meeting
was
Postman
folks.
It
was
like
a
decent
group.
Patrick
was
here
and
we
talked
about
we
sort
of
narrowed
down
what
we
were
going
to
do.
We
decided
like
we're,
definitely
going
to
start
looking
at
Monaco
I,
don't
think
in
October
we
were
like
version
three
specifically,
we
were
just
like
here's.
The
next
features
that
we
wanted
to
focus
on.
It
was
Monaco.
A
Then
there
was
additional
enthusiasm
and
I
would
say
equivalent
enthusiasm
for
the
plugin
API,
which
is
sort
of
they
don't
go
hand
in
hand,
but
they
were
like
just
two
big
ones
that
were
left
out
right
in
the
Third
Kind
of
big
feature
that
was
left
out
was
the
visual
operation
building
right,
there's
a
lot
of
folks
that
are
also
excited
about
that.
A
Were
the
big
three
and
we
decided
in
October
that
we
would
try
to
take
a
stab
at
Monaco
and
that's
a
big
job.
Yeah.
A
A
B
But
I
think
I
think
we
can
still
get
there
I
think.
Maybe
we
can
find
some
ways
to
simplify
graphical
react
in
the
process
too.
A
B
Yeah
I
think
I
see
it
as
I
still
think.
It's
important
to
work
on
I
see
it
as
a
as
a
preliminary
step
and
yeah
to
to
the
Monaco
effort.
I
guess
yeah.
A
So
we're
just
jumping
ahead
here
in
the
in
the
agenda,
but
that
was
just
a
status
of
how
that
how
that
the
Monaco
editor,
situ,
The
Monaco,
editor
integration
situation
is,
is
here
on
the
agenda
like
yeah.
Basically,
we
need.
A
We
just
need
human
bodies,
this
is
the
the
classic
problem
right.
This
is
nothing
new.
We
need
human
bodies
to
care
enough
I.
A
B
A
A
A
If,
if
that
means
that
we
think
it
might
allow
a
little
more
like
more
people
to
just
possibly
show
up
and
get
involved,
even
if
it's
not
like,
even
if
we're
not
talking
absolute
specifics,
if
there's
other
people
that
we
can
talk
to
and
just
explain,
what's
going
on,
I'm
just
trying
to
like
offer
more
of
a
of
a
you
know
like
a
hole
for
people
to
jump
into
and
get
involved,
because
Discord
is
Discord
is
great,
but
we're
also
not
getting.
You
know,
there's
just
also
not
a
lot
of
conversation
there.
B
Just
trying
to
think
of
also
a
recession,
I
noticed
in
like
spring
of
2020
when
the
pandemic
hit,
and
there
was
a
big
initial
wave
of
layoffs
and
recessions
and
whatnot.
We
had
almost
no
activity
and
we
went
from
like
our
our
activity
dropped
by
probably
about
200
percent
and
it
hasn't
really
fully
recovered.
Yet,
like
you
think,
we
like,
we
used
to
have
a
lot
more
activity
in
our
repo
I.
Don't
know
if
it
was
just
because
things
were
a
little
bit.
B
There
was
still
a
lot
more
work
that
needed
to
be
done
or
what,
but
there
was
just
not
a
lot,
not
as
many
things
reported
now
we
still
get
the
like
instant
bug
reports
and
things
like
that.
That
are
helpful,
but
you
know
you
know
just
one
of
the
helpful
aspects
of
how
having
a
very
high
usage
repo
to
maintain
but
yeah.
Like
I,
don't
know
we
still
get
a
lot
of
involvement,
but
it
just
it's.
B
The
amount
of
people
that
are
approaching
us,
saying,
like
hey
I'd
like
to
contribute,
has
reduced
a
lot
and
I.
Don't
know
what
other
factors
there
are
behind
that
I
think
some
of
it
is
devrel
related
of
like.
Are
we
putting
out
The
Feelers
to
show
we
want
to
attract
more
people
to
help
or
do
people
think
that
you
and
Thomas
were
the
new
people
to
help
you
know
and
that
we
found
the
people
you
know
like
I,
don't
know
if
people
know
what
graphical
needs
or
the
graphical
needs
more
contribution.
You.
A
Know
yeah
I'm,
gonna,
I'm
gonna
say
that
that
seems
like
that's
a
that's
a
good
lead.
You
know,
because
the
me
and
you
you
and
Thomas
and
I
last
year
were
there
was
a
long
period
even
before
I
came
along
where
there
was
just
a
lot
of
activity.
Tim
was
was
super
involved
right
with
getting
2.0
off
the
ground
and
getting
it
delivered,
and
maybe
maybe
you're
right.
A
Maybe
maybe
there
just
isn't
a
lot
of
eyeballs
on
the
repo,
because
people
think
that
it's
getting
taken
care
of
I
would
like
to
suggest
again
that
we,
maybe
we
just
need
to
send
a
message
to
Benji
and
say
hey.
Can
we
get
this
on
the
larger
working
groups
radar
just
to
bring
up
for
like
a
five
minute
chat
in
the
in.
B
B
We
can
add
an
agenda
item
for
that.
One
other
thing,
I
think
is
going
to
be
important
to
to
make
Monaco
support
less
painful.
B
The
state
manager
knew
the
new
state
manager
implementation
with
when
when
Monaco
is
adopted,
it
just
needs
to
make
extensive
use
of
text
model
and
I.
Think
it'll
save
so
much
more
effort
than
trying
to
manage
everything
in
state
and
memory
instead
of
using
the
text
model
for
memory
state.
B
Yes,
but
but
I
think
the
problem
is
you
often
see
people
go
editor
set
value
instead
of
model
set
value
yeah,
and
so
this
is
something
that
will
save
a
lot
more
time,
because
then,
with
something
like
such
spend,
you
can
just
say
get
model
from
URI
set
value.
A
B
Models
can
switch
between
editors
if
needed,
but
you
should
have
one
editor
instance
for
for
all
tabs.
So
when
you
switch
between
the
tabs,
it
changes
the
model
yeah
yep.
A
I
went
over
the
Proto
prototype
code
in
detail
this
morning,
actually
with
the
some
folks
on
the
graph
based
team
and
so
I.
That's.
A
That's
the
way
that
the
Prototype
is
built,
there's
code
out
there.
That
does
exactly
that,
but
it
like
you're
saying
it
relies
on
like
non-context
State,
Management
solution.
It
needs
a
needs,
a
place
to
live.
That's
that's
yeah
Global,
that's
global,
app,
State
and
that's
something
that
we
don't
have
and
graphical
right
now.
B
Yeah
I,
just
I,
would
just
want
to
make
sure
that
there's
a
good
crossover
there,
because
that
was
where
we
had
some
some
pain
when
transitioning
to
Monaco.
Before
was
with
that,
and
we
had
to
kind
of
make
sure
to
go
through
and
Implement
that
again
properly.
But.
A
B
That
case,
we
just
kept
all
the
text
models
in
context
and
the
the
text
models.
Don't
log
as
Changed
by
context
when
you
actually
change
the
values,
because
context
can
observe
model.
You
know,
text
model
object
for
changes,
so
we
would
just
use
editor
or
a
model
on
change
hook
to
register
changes.
B
A
B
B
Something
we
often
forget
when
we're
when
we
work
in
a
company
or
vertical,
where
translation
isn't
important,
it's
just
like
yeah,
that's
the
thing.
Sometimes
people
need,
but
some
people
need
it
all
the
time
some
people
can't
use
graphql
because
graphical
isn't
translated.
You
know,
I
know
at
IBM.
That
was
a
requirement
for
a
lot
of
things
like
we
can't
use
this
technology
if
it's
not
available
in
multiple
languages,
you
know
so
that
was
a
a
baseline
but
yeah
so
cool,
but
yeah,
no
I,
think
that
makes
sense.
B
So
I
think
we
could
reduce
the
frequency
of
these
meetings
for
now
and
then
start
chiming
in
with
the
greater
working
group
to
to
bring
more
interest
in.
A
Yeah
I'm
gonna
add
that
to
the
I'm
going
to
put
in
the
pr
to
add
that
to
the
agenda
right
now
and
I
want
to
say
that
we,
probably
let's
not
reduce
I,
mean
once
a
month
is
fine
I'm,
happy
to
show
up
and
just
stick
around
for
15
minutes
and
be
here
because
I'd
rather
not
I'd,
rather
not
have
to
go
to
less
and
then
have
to
come
back
to
more,
like
this
seems
like
a
good
Cadence,
I.
A
B
B
So
cool
yeah
and
so
for
the
record.
We're
gonna
go
on
Thursday
to
talk
more
about
the
access
issues,
so
we
can
get
back
to
releasing
again
but
we're
trying
to
continue
things
either
way
without
the
ability
to
release
so
I've
been
working
on
the
pull
requests
to
migrate
to
Veet
and
I,
made
progress
on
your
PR
Jonathan
and
now
I'm,
stuck
on
a
special
character.
So
I'm
going
to
come
back
yeah.
A
B
A
Know
why
that's
there
and
I
I
looked
in
the
reach
repository
and
they
don't
use.
They
don't
use
that
character.
Maybe
I
didn't
search
right.
B
B
So
what
I
feel
like
is
there
must
be
something
I'm
doing
with
like
there's
a
v
plugin
that
I
was
using
to
get
around
some
of
the
require
issue
like
the
the
graphical
WS
require
issue
and
I
can't
seem
to
I'm
pretty
sure
that
that
plug-in
is
somehow
causing
this
issue
Downstream,
so
I
just
have
to
figure
out
yeah
just
the
order
of
build
tooling,
but
my
goal
is
to
replace
project
references
and
webpack
and
they
create
some
kind
of
Harmony
where
I
think
like,
for
example,
with
graphical
react,
I
think
we
might
actually
I
have
it
almost
working
where
it
will
use
a
different
tool
to
build
the
library
bundle
called
TS
up
yeah,
and
we
will
use
that
to
build
the
library
bundle
and
then
use
Veet
to
build
the
whole
bundle.
B
B
This
is
it's
a
new
trend
I've
seen
where
people
are
shipping
modules
that
are
installed
via
npm
with
all
their
dependencies,
bundled
which
feels
like
it
defeats
the
purpose,
because
you
have
your
your
bundlers,
automatically
or
node
is
automatically
installing
those
dependencies
anyways
with
npm
right.
So
why
do
you?
Why
do
we
bundle
our
library
dependencies
when
the
library
dependencies
have
to
be
installed?
B
Anyways
I
guess,
is
it's
something:
I'm
I'm,
it's
a
trend
I'm,
seeing
with
es,
build
and
stuff
where
it's
super
easy
to
bundle
your
your
library
now,
but
we
never
bundled
libraries
before
unless
it
was
for,
like
a
Browser
Bundle
for
a
very
specific
reason.
So
this
is
something
I've
been
wondering
about
and
because
I
noticed,
it
causes
multiple
issues,
because
we
end
up
with
a
bundle
of
a
bundle
and
the
source.
B
Maps
break
everything
you
know,
whereas
when
you
ship
the
unbundled
code
where
it's
just
the
source
files
and
the
actual
original
file
tree
and
everything,
then
you
can
much
more
easily
debug
and
and
the
source
Maps
work
and
stuff,
but
yeah.
A
I'm,
looking
at
graphical
react
right
now:
where
is
that?
Where
is
it
implicit
that
we're
bundling.
B
Because,
like
if
you
look
at
the
bundled
output
in
dist,
you
see,
you
know
a
bunch
like
react
is
made
external,
but
you
see
like
reach.
Libraries
are
all
being
bundled
into
the
graphical
react
package.
We
don't
need
the
reach
libraries
to
be
bundled
in.
In
fact,
we
shouldn't
do
the
bundling
and
we
should
let
the
consumer
decide
how
to
bundle.
Those.
A
I
think
I
think
so
I
agree,
but
I
also
think
it
would
mean
that
we
would.
Let
me
see,
graphic
graphql,
react
and
react
Dom.
So
what's
left
what's
left
is
the
reach
The
Primitives
code
mirror.
B
Yeah,
so
all
those
things
get
bundled
in
right
when
we're
already
telling
them
to
install
code
mirror
when
they
install
this
package.
So
that
means
that
they'll
ins
like
have
these
new
dependencies
installed,
but
the
the
code
never
gets
executed
because
we're
shipping
a
bundled
version.
This
causes
a
lot
of
confusion
in
other
projects
too,
and
I
think
it
causes
us
like
two
times
as
many
issues
as
we
normally
have,
because
now
we're
dealing
with
the
issue
of
bundling
other
dependencies
and
shipping,
a
library
bundle
with
bundle
dependencies.
A
But
so
are
you?
Are
you
suggesting
that
the
that
one
step
like
that?
One
initial
step
here
would
be
to
replace
in
graphical
reactor
place,
beat
with
TS
up
and
that
would
allow
us
to
set
the
builds,
the
dev
script
and
the
build
Scripts
to
not
have
to
build
graphical
react
con
not
have
to
watch
for
changes.
B
Well,
it
would
still
need
to
watch
for
changes
well.
Well,
there's
different
ways
to
do
it.
We
can
have.
We
can
configure
the
V
bundle
to
work
in
mono
repo
mode
where
it
will
automatically
import
the
source
files
of
the
bundles.
It's
the
library,
internal
libraries
from
the
mono
repo.
So
that's
one
approach
to
that,
but
I
think
what
I'm
talking
about
is
just
for
the
vconfig.
For
now,
for
example,
it
would
just
be
to
switch
es,
build
to
bundle
false,
so
it'd
be
Library
mode,
but
with
bundling
disabled.
B
B
B
Otherwise,
we'll
be
swimming
up,
River
we'll
be
saying
bundle
but
leave
everything
out,
and
then
we
have
to
manually
add
everything
that
we
that
yeah
so
the
way
I
understand
with
a
library
mode.
You
shouldn't
have
a
context
of
EX
have
a
concept
of
externals
like
if
you're
bundling
a
library
to
be
used
to
be
installed
and
consumed
by
other
bundlers.
You
don't
need
to
bundle
you're,
shifting
a
library,
not
an
end
application.
That
needs
to
be
bundled.
B
A
Okay,
well
I
I
support
that
I,
wonder
if
anyone
in
the
community,
that's
using
graphical
react
as
a
package
would
take
issue
with
that,
given
their
current
setup
or
like.
Maybe
they
would
just
need
to
change
the
way
that
their
whatever
app
they're
using
it
in
their
bundler
works.
B
They
shouldn't
have
to
yeah.
It
should
just
work
because
the
dependencies
are
already
installed.
So
if
we
ship
it
in
a
different
way
where
it
expects
instead
it
it
packages,
esm
module
Imports.
Instead
of
a
giant
esm,
bundled
file
that
has
all
the
modules
inside
the
file,
then
the
esm
module
Imports
should
automatically
just
pick
up
based
on
dependencies
that
are
installed.
When
you
install
graphical
react.
B
Otherwise,
like
with
the
way
it
is
now,
we
could
ship,
we
could
just
remove
all
dependencies
and
just
say
it's
a
lot.
It's
a
pre-bundled
library
and
nothing
else
is
installed
by
it
because
it
bundles
all
of
its
dependencies,
and
that
would
be,
in
my
opinion,
that's
that's
a
supply
chain
issue.
That's
that's
in
it
because
you're
you're
pre-bundling
other
projects
for
people
ahead
of
time.
So
that
means
that
you
need
to
put
out
a
release
when
one
of
your
dependencies
dependencies
has
a
security
chain,
the
security
fix.
B
A
B
Libraries,
we
don't
even
take
care
of
so
that
would
be
that's
kind
of
another
issue.
Just
just
there's
lots
of
supply
chain
issues
from
this,
but
yeah
it's
something
you
know,
I'll
create
a
GitHub
issue
about
it
and
we'll
hopefully
address
it
with
as
part
of
replacing
webpack
and.
A
Yeah
I
think
that
if
we
can
get
so
I'm
trying
to
move
through
just
the.
B
The
only
bundle
that
really
matters
where
there
are
is
actual
bundling,
like
the
only
like
bundler
bundle,
where
we
want
to
in
to
bring
all
the
dependencies
together,
is
for
the
graphical
Min,
not
jazz
and
they're
graphical.js,
like
that.
One
you
know,
has
to
have
everything
but
react
and
react
on
built
in.
A
Wait
isn't
but
isn't
don't
we
also
seat
ship?
A
CDN
bundle
for
graphical
react.
B
We
do
but
I'm
not
sure
what
we
use
it
for.
Does
anyone
use
that
CDN
bundle
version
I.
B
Because
the
whole
point
of
graphical
react
is
is
to
build,
is
for
an
SDK
for
building
stuff.
So
at
that
point
you
should
be
using
a
bundler
for
whatever
you're
using
graphical
reaction.
B
B
Cdn
bundle
for
graphical
is
because
most
of
our
users
aren't
JavaScript
or
typescript
users,
and
they
just
want
a
simple
way
to
look
at
to
use.
Setup.
Graphical
I
know
that
shocking,
maybe
to
some
people
listening
to
hear
that
most
of
our
users
are
not
JavaScript
or
typescript
users,
but
it's
definitely
the
case,
and
we
have
to
you
know
it's
it's
it's
part
of
our
kind
of
Mo
of
doing
things,
and
it's
why
we
have
to
explain
a
lot
of
things
and
it's
why
we
don't
it's.
B
Why
we're
not
documented
and
advertised
like
other
JavaScript
or
typescript
libraries,
because
we're
meant
to
serve
mostly
people
outside
of
JavaScript
or
typescript
communities,
so
there's
certain
lingo
we
can't
get
away
with
using.
We
have
to
include
more
steps
with
documentation
and
yeah
and
just
assume
that
some
people
that
are
trying
to
set
up
graphical
have
never
even
touched
JavaScript.
Barely
you
know,
and
so
we
have
to
make
it
yeah
excessive.
That's
why
I'm
still
talking
about
creating
a
Docker
image
for
graphical?
B
Oh
I
mean
they've
people
been
asking
for
years
for
it,
so,
but
someone
reserved
the
graphql
docker
Hub
org
already
for
their
own
commercial
purposes,
and
we
were
supposed
to
track
that
down.
So
we
don't
really
have
a
place
to
publish
to,
but
it's
it's
requested
very
often
because
a
lot
of
people
don't
even
want
to
have
to
deal
with
a
web
server
or
anything
right.
Yeah.
B
That's
but
I
created
a
Apollo
server
example
because
that's
been
requested
for
a
long
time
too,
and
we
could
ship
a
very
simple
plug-in
for
Apollo
server
and
yo,
and
yoga
already
has
graphical
a
lot
of
the
servers
already
have
it
built
in,
but
but
yeah
I
mean
we
could
ship
an
Apollo
plug-in,
but
then
we're
just
favoring
the
JavaScript
and
typescript
ecosystem
too
much
at
that
point.
Yeah.
A
B
A
A
That's
what
I
mean
I
also
did
that
for
somebody
on
Discord,
like
I
mean
that
we
have.
We
have
plenty
of
examples
of
that.
It's
relatively
simple.
If
you
understand
the
system
and
we
could
socialize
that
better,
but
I,
don't
know
that
we
want
to
like
officially
sorry
I
didn't
use
an
Apollo
plug-in
I
just
used
graphical
I'd
have
to
find
it.
I
have
to
go,
go
it's.
B
B
B
Happy
and
one
other
one
I
can't
remember,
offhanded
Co-op
right
so
there's
middlewares
for
all
of
those
and
then
a
render
function,
library
that
was
used
by
all
those
and
other
things
out
there
that
rendered
the
markup.
So
huge
security
issues
with
that.
But
notwithstanding,
if
you
filters
HTML,
it's
fine
and
then
yeah,
so
there's
there's
a
whole
like
there.
There
are
those
who
would
basically
say
well
if
I
can't
install
playground
as
an
Express
Middle,
where,
if
I,
if
I
can't
install
graphical
with
a
simple
Express
middleware,
then
it's
not.
B
B
The
special
settings
approach
instead
of
using
graphic
graph,
react
props
so
where
they
have
a
settings
string,
that's
a
parsable
Json
right,
but
you
pass
in
and
you
pass
it
in
as
a
whole
string,
and
so
it
looks
like
vs
code
settings,
but
they
use
that
to
configure
the
whole
playground
and,
as
as
our
settings,
get
more
and
more
complex,
I
really
really
still
want
to
keep
stressing
that
that
is
probably
the
better
example
to
go
with.
A
B
Settings
that
people
do
and
they're
gonna
need
more
we're
going
to
have
to
provide
a
different
approach
and,
as
I've
been
saying
for
a
couple
years
now,
playground
has
the
best
pattern
for
this,
because
playground
I've
made
a
diagram
and
explained
all
this
in
a
GitHub
issue.
Already
that's
marked
as
an
RSC,
but
there's
there.
B
This
is
like
kind
of
was
my
architectural
vision
for
2.0,
and
then
that
would
allow
people
to
create
either
either
import
the
whole
like
everything,
bells
and
whistles
the
plugins
and
everything
graphical
or
graphical
app
or
if
they
wanted
something
more
more
to
to
build
something
more
purpose-built,
more
customized.
They
would
use
just
the
graphical
component
and
Implement
logic
over
there
to
load
their
fetcher,
and
things
like
that
and
the
graphical
react
thing
was
was
meant
to
be
a
a
an
approach
to
that.
B
That
would
prevent
having
to
create
these
multiple
service
layers,
so
it
created
a
service
layer
inside
graphical
component
instead
of
creating
the
service
layer
on
top
of
graphical
component,
but
I
still
think
there's
a
justification
for
having
this
service
layer
on
top
of
graphical,
but
it
might
not
be
needed
anymore
so,
but
just
yeah,
just
the
thing
to
think
about
and
the
playground
repo
is
this
really
good.
Prior
art
I
feel
like
because
a
lot
of
the
same
kind.
B
Trying
to
solve
were
solved
there
in
some
degree,
some
of
them
at
least
it's.
A
A
B
Yeah
I
was
trying
to
point
out.
These
are
the
things
this
is
like.
I
had
a
whole
blog
article
about
it
and
saying
what
features
we
were
going
to
bring
over
from
playground
first
and
was
part
of
the
road
map
and
everything
it
was
all
planned
out,
but
we
ended
up
going
a
different
path
and
we
ended
up
not
adopting
this.
This
architecture
that
would
allow
make
it
very
easy
to
have
like
an
abstraction
of
extracted,
abstracted
concept
of
settings.
B
It's
more
like
vs
code,
vs
codes
type
like
settings
rather
than
using
props
for
everything.
So
the
idea
was
like
that.
B
The
service
layer
would
then
be
used
as
Supply
data
that
would
be
used
to
generate
the
props
for
the
graphical
component,
but
so
we
could
still
do
that
and
we
could
still
have
both
of
those,
so
I
would
I
would
suggest
looking
at
the
playground
Source
if
you
get
a
chance
to
and
and
seeing
how
that
part
is
set
up
and
then
and
then
like
also
the
Redux
implementation,
it
might
be
inspiration
for
zestan
too,
seeing
how
they
solve
certain
problems,
but
again
playground.
Never,
oh
no
playground
does
have
tabs.
B
So
there's
some
comparison
there
too,
so
yeah,
it
might
be,
might
be
interesting.
Some
of
the
Redux
stuff
is
kind
of
boilerplate
for
something
like
that,
but
you
know
a
lot
of
little
edge
cases.
A
lot
of
like
this
is
how
this
user
setting
was
passed
in
and
they
already
handled
things
like
schema,
change,
on
polling
and
and
schema
schema
change,
notifications
and
stuff
like
that
and
yeah,
and
some
of
it's
kind
of
broken,
though,
because
it's
just
play
I
haven't
had
time
to
maintain
playground
and
there's
a
lot
to
it.
So.
A
B
Yeah-
and
so
we
there's
probably
a
few
more
things
that
people
are
expecting
to
be
able
to
say
that
that
has
been
has
happened
and
then
we
can
go
all
up
in
the
playground,
issue
cues
and
say:
oh
this
is
closed.
You
can
do
this
with
graphical
now.
You
can
do
this
with
graphics,
on
that
we'll
get
to
do
that
someday,
but
and
in.
A
Cases
I
don't
know,
I
mean
let's
get
through
the
graphical
issues.
First,
I
think
a
lot
of
this
has
just
been
timed
out
right.
A
lot
of
the
a
lot
of
the
issues
and
a
lot
of
the
PRS
even
have
just
they've,
just
been
timed
out
whether
it's
because
people
have
you
know,
abandoned
an
effort
and
they
you
know,
or
they
switch
to
Apollo
sandbox
Explorer
or
they
switched
to
you,
know
cake
pop
or
whatever.
A
We
don't
have
a
way
of
quickly
identifying
who
is
still
waiting
I.
If
anyone
was
still
waiting
for
for
an
issue
to
get
fixed
from
six
months
ago
or
a
year
ago,
I.
A
B
A
Like
migrates
up
and
there
and
it
breaks
all
their
stuff,
then
we're
just
there
to
help
them.
You
know
make
that
migration
happen.
I
much
prefer
to
do
that
than
I
do
to
like
go
through
issues
that
are
three
years
old
and
have
to
try
to
it
just
seems
like
a
little
bit
of
a
waste
of
time.
Maybe
that's
just
my.
B
A
I'll
give
it
like
I,
just
I,
just
I
just
went
to
an
issue
from
a
few
days
ago
or
somebody
so
the
graphical
Explorer,
the
graphql
Explorer
plug-in
that
we
have
just
passed.
It
just
takes
all
the
props
from
that
plug-in
and
it's
and
exposes
them
through
the
use,
Explorer
plug
and
hook
right
that
we
that
we
use
in
the
examples
of
how
to
use
the
the
plug-in
and
there's
an
Explorer's
open
prop.
A
That's
a
Boolean
that
exists
on
the
the
in
the
source
code,
because
that's
how
it
determines
whether
or
not
it
should
be
open
or
closed.
That's
the
Shelf,
but
in
our
world
that
prop,
you
can
pass
it
through.
But
it
doesn't
do
anything
in
our
world
because
we
control
the
visibility
of
that
of
the
pain,
plug-in
view
differently.
So,
oh.
A
B
A
B
A
One,
that's
not
a
bug.
Number
two
I've
been
telling
people
anything
having
to
do
with
that:
Explorer
plugin.
If,
if
you,
if
someone
wants
to
jump
in
and
fix
it,
and
it's
a
bug
great
otherwise
any
effort
to
address
anything
with
that
Explorer
plug-in
should
be
put
into
building
the
new
version
of
that
plug-in.
It.
A
I
mean
it's
just
a
matter
of
like
rewriting
the
type
signature
for
for
that
plug-in
and
you
know
doing
a
part
doing
an
emit
or
partial
or
something,
and
only
really
using
what
we
want
to
pass
through
it.
Just
we
did
just
it.
Just
didn't
get
done
and
I'm
I
don't
want
to
do
it.
Yeah.
A
B
A
A
B
That
means
we
need
to
fix
something
and
the
dots
or
examples
or
in
typescript
to
make
sure
that
people
know
what
has
changed
or
how
it's
supposed
to
work
like
that's
to
me,
an
indicator
is
if,
if
like
multiple
people
are
using
something
wrong,
that
means
that
we
need
to
fix
something.
B
B
A
Supporting
it,
there's
someone
the
one:
it's
not
fixing
that
is
not
as
complicated
as
some
of
the
not
even
close
as
complicated
as
some
of
the
other
stuff
that
we're
planning
on
working
on.
So
that's
a
great
opportunity
to
for
someone
to
like
first
issue.
If
they
want
to,
you,
know,
jump
in
and
help
out,
but
I
I
don't
know,
let's,
let's,
let's
talk
about
PR's
that
I
need
to
get
merged
in.
B
A
B
Nice
yeah,
that's
a
good
one
and,
as
you
can
see
the
chain,
the
canaries
aren't.
B
You
can
merge
I
think
we
should
keep
merging
and
just
let
a
big
changelog
build
up,
I.
Think
it's
fine
and
yeah
I
I,
don't
I,
don't
think
we
really
have
a
choice.
Otherwise,
because
now
you
know,
there's
a
whole
changelog
set
for
to
3-0
that
isn't
going
to
get
published.
So
when
we
do
a
240,
publish
that'll
include
everything
from
230.
So
it's
it's
going
to
be
a
giant
release
anyways
and
there's
going
to
be
some
bugs
with
it.
A
B
Fixes
so
yeah
yeah
there's
a
couple
other
important
bug
fixes
I
think
we
can
get
a
lot
of
these
PR's
merged
before
we
have
access
to
release
again
and
then
we
can
watch
everything
integrate
in
the
deploy
previews
and
make
sure
that
it's
ready
to
release
when
we
are
ready
to
release
it
again.
So.
B
Yeah
and
I
want
to
get
your
VPR
merged
and
finish
up
that
effort
really
want
to
get
that
out
of
the
way
like
that
and
the
State
Management
PR
really
bugging
me.
But
there's.
A
B
A
A
B
B
This
build
tooling
and
the
bundling
of
libraries
is
causing
us
lots
and
lots
of
headaches.
So
we
we
really
like
we're
getting
bugs
where
the
way
we're
bundling
libraries
and
graphical
react
is
causing
issues
when
it
gets
bundled
Again
by
graphical,
using
webpack
or
when
it
gets
bundled
by
other
tools
and
so
I
think
the
solution
there
is
to
just
not
bundle
the
library,
as
we
discussed
so
I,
think
yeah
there's
some
major
changes.
We
need
to
make.
A
B
I
see
it
at
all
as
part
of
the
same.
The
same
effort,
though,
like
we
want
to
we
want
to
like,
if
we
just
just
replace
webpack
with
Veet,
then
we
will
we'll
have
to
work
around
a
bunch
of
other
issues
which
is
be
consuming,
beat
a
beat
bundle
consuming.
Another
beat
bundle,
there's
a
lot
of
there's
ways
to
do
it,
but
I've
run
into
so
many
issues
with
this
before,
and
it
made
that
the
tooling
even
more
painful
I,
think
what
we
we
need
is
is
a
separation
of
responsibilities.
B
B
So
the
other
option
is,
we
could
do
library
mode
without
bundling
which,
according
to
the
Veep
docs
is
oh
just
set
es,
build
bundle
false
and
that's
how
you
fix
that,
probably
according
to
to
the
the
issue
where
someone's
like
hey
I'm,
trying
to
use
Library
mode
with
Veet.
But
for
some
reason
it
keeps
bundling
all
the
dependencies
and
they're
like
oh
we'll,
just
disable
that
can
you
can.
A
B
B
A
Yeah
so
anyway,
that
PR
is
I'm,
excited
to
see
the
work
that
you're
doing
to
get
that
one
in.
B
I
would
love
that
I
would
love
to
get
back
to
where
it
was
where
you
could
just
run
one
command
and
watch
the
whole
repo
it
just
without
project
references.
It
seems
really
difficult,
but
we'll
figure
out
a
way
to
do
it.
Ws
run
allows
you
to
do.
Staged
builds
where
it
will
do,
builds
based
on
your
dependency
tree
so,
and
we
already
are
using
WS
run
so
I'm,
probably
going
to
use
that
to
run
TS
up
and
TSR
will
will
build
what
changed.
But
that
means
creating
a
watcher
for
every
workspace.
B
Of
these
tools
have
a
workspaces
run
command
on
their
own.
That
does
what
we
need,
but
WS
run
takes
care
of
that,
no
matter
what
package
handler
we're
using,
but
I've
used
yarn.
Three
workspaces,
I've
used,
pnpm
workspaces,
none
of
them
out
of
the
box
will
be
able
to
solve
this
problem.
We
we
will
need
to
use
our
own
tooling
to
do
a
multi
workspace
watch.
B
That's
totally
doable.
That's
probably
one
of
the
easier
parts
it'll
just
be.
How
do
we
make
it
perform?
It
will
be
the
more
difficult
part
yeah
yeah
like
it's
hard
to
match
project
references,
because
it's
it's
built
into
the
typescript
compiler
and
it's
already
meant
to
be
super
efficient.
So
we
we
just
have
to
find
a
way
to
build
something,
custom
or
or
yeah
I,
don't
know!
B
Last
like
we
built
our
own
beat
the
last
company
I
worked
at
just
because
we
couldn't
use
V,
we
couldn't
use
swc,
couldn't
use
turbo
pack
or
next
just
because
of
our
own
constraints.
So
we
basically
just
built
our
own
thing
like
the
using
ES
build
and
express
and
other.
A
B
Right,
it
was
just
a
quick
way
to
get
around
that
issue
and
I
just
wanted
to
start
working
with
a
different
bundlers
and
webpack
yeah.
So
that
was
my
fault
for
in
half
introducing
without
replacing
webpack
but
but
yeah
we
can
figure
out
some
ways.
I
wish
turbo
pack
was
serviceable
in
a
way
that
would
be
useful
here,
but
it's
not
like.
There's
like
there
are
no
options
or
config
file,
documentation
or
anything
for
Turbo
pack,
because
it's
built
into
next
and
other
tools.
B
The
best
you
can
figure
out
is
to
like
read
the
rest
source
code
and
figure
out
how
you're
supposed
to
call
it
from
JavaScript
or
look
at
the
the
next
JS
like
underlying
implementation.
But
yeah
I've
tried
the
swc
ecosystem
version
of
this
and
it
was
not.
There
was
a
lot
of
things
lacking.
B
You
can't
just
use
it
off
the
shelf
yet
so,
like
turbo
pack
has
a
dock
site,
but
there
really
isn't
a
lot
about
it
like
there's
no
way
so,
there's
no
such
thing
as
a
turbo
pack
config
file
from
what
I
know,
for
example,
I
think
you
have
to
you-
can
only
call
it
programmatically
so
far,
it's
not
even
from
what
I
can
tell
a
CLI
for
it.
B
But
again
it's
all
about
reading
the
rust
source
code
and
trying
to
understand
it
yeah
it
mostly
just
documents
like
it's
how
it
improves
on
webpack
and
things
like
that,
which
is
cool
but
yeah,
I'm
I
wish
we
could
just
use
turbo
pack,
but
I,
don't
know
if
we
can't
you
know
it's.
Just
yeah
I
couldn't
find
a
readme
I
couldn't
find
markdown
documentation
even
reading
the
rust
source
code.
I
was
just
kind
of
not
sure
what
to
use
it,
how
to
use
it
independently
of
next.
B
You
know
so
and
looks
like
like
the
the
distribution
swc
files
are
the
most
popular
way
to
download
swc.
So
it's
trying
to
see
yeah.
How
does
next
call
the
swc
repo
and
how
does
it
does
it?
How
does
it
call
Turbo
pack,
you
know
just
trying
to
understand
how
all
this
works,
let's
see
if
we
could
adapt
it
to
use
turbo
pack
ourselves
or
for
any
other
projects,
I'm
working
on,
but
I
just
don't
see
a
way
to
use
turbo.
A
A
B
Way
beats
fine,
I
think
we
just
need
to.
We
I
think
we
just
need
to
be
more
more
deliberate
in
how
we
use
it.
Yeah
like
it's
easy
enough
to
just
get
set
up
and
get
started.
A
B
A
project
with
v,
but
that
doesn't
mean
that
the
way
we
have
it
set
up
and
that
we're
bundling
it
and
the
way
everything's
configured
is
going
to
be
happy
so
yeah.
We
just
need
to
make
that
happy
and
we
need
to
to
I
think
not
bundle
libraries
unless
we
absolutely
need
to
and
I
think
that
will
I
think
that
will
speed
things
up
too.
Once
we
do
that,
because
then
we
don't
even
have
to
bundle
plugins
necessarily
or
do
we
that's
a
good
question.
That's
on
the
bundling
question
gets
really
complicated.
A
B
B
A
A
B
A
Yeah
yeah,
no,
no
yeah,
I
also
agree.
What
I'm
saying
is
that
if
it
were,
if
it
was
all
our
code
based
on
previous
conversations,
that
we've
had
about
bundle
size
of
graphical
and
how
it
kind
of
doesn't
really
matter,
because
it's
a
developer
tool
and
most
people
aren't
really
like
getting
it.
It's
not
that
big
of
a
deal
I
would
feel
more
than
comfortable
just
bundling
them
all
along
with
graphical
and
and
and
say.
That's
it
right
that
way
like
when
you
just
load
graphical
instead
of
having
to
pass
a
plug-in
into
it.
A
You
just
select
from
a
list
of
options
that
we
defined
as
redefine
as
like
optional
default
plugins,
and
it's
just
easy
enough
to
toggle
them
on
or
off.
That
would
be
great,
unfortunately,
like
the
way
that,
because
we're
stuck
with
these
two
older
plugins
and
haven't
built
that
ourselves
funneling,
that,
along
with
our
code,
just
seems
like
a
bad
idea
for
a
number
of
reasons.
Yeah.
B
Cdn
bundle
so
you're
saying
bundling
it
with
plugins
in
the
CDN
bundle
is
in
advised
because
we
don't
really
officially
support
those
plugins
they're
just
there
for
compatibility,
okay,
yeah.
Let
me
I
gotta
check
something
on
the
stove
I'll
be
right
back.
B
Right
so
yeah,
okay,
cool
yeah,
I
think
that
the
bundling
issue
also
gonna
work
on
those
next
examples
for
Monaco
graphql.
B
And
yeah,
and
just
merging
small
bug
fix
PRS
and
other
Improvement
PR's
that
you
can
like
validate
make
sure
they
don't
cause
regressions
and
whatnot
just
because
we
don't
have
a
normal
release.
Cadence
to
kind
of
you
know
more
thoroughly
test
against.
You
know,
implementations
in
the
wild
as
we
make
changes
as
we
usually
do.
You
know
I
think
it'll,
be
okay.
B
A
A
Well,
we
should
talk
to
Dimitri
about
that.
I,
don't
know
what
the
status
is.
I've
been
hoping
that
he
was
going
to
be
able
to
make
it
to
one
of
these
meetings
and
just
sort
of
give
us
an
update
on
the
status
of
all
of
that
linting
work
that
he's
doing
yeah
I
feel
like
they
made
they're
made
they're
passing,
but
I
feel
like
they're,
maybe
work
that
he
still
has
to
do
on
it.
So
I.
B
Definitely,
if
you
see
PRS
that
are
unfinished,
you
can
just
choose
to
convert
to
draft,
and
then
that
way
we
know
which
ones
I
did
that
with
your
beat
one,
for
example,
because
it's
still
a
v.
So
anything
that's
like
draft
or
do
not
merge.
We
just
make
it
a
draft
in
GitHub
and
then
that
way,
it's
very
clear
to
everyone
that
it's
still
in
a
draft
state
yeah.
Oh.
A
Okay,
well
I'm
gonna
get
up
and
take
a
shower
and
eat
lunch
because
I've
been
for
since
five
o'clock.
Oh.
B
A
But
I
wanna,
just
recap
here:
real
quick,
I'm
gonna,
put
in
an
agenda
item
for
10
minutes
for
the
working
group
meeting
on.
A
It's
the
that
that
working
you're
meeting
is
split
into
EU
and
there's
two
of
them
right.
What's
on
Thursday.
B
Yeah,
which
yeah
it's
I'm,
I
I,
don't
know
which
one
I'm
gonna
be
able
to
go
to,
but
if
I
don't
make
it
to
either,
can
you
be
the
one
to
give
an
update
about
how
we
can't
release
yet.
B
A
Yeah
yeah,
it
looks
like
it's
I
think
that's
6,
30,
CET,
Thursday
yeah
and
then
the
next
one
would
be.
A
I
guess
the
I
guess
number
one
was:
let's
see
when
was
it
anyway,
I'm
gonna
be
there
to
talk
about
this
graphical
thing.
I'm
gonna
put
that
agenda
item
in
now,
cool
and
I'll
be
in
touch
with
you
about
some
of
the
other
stuff.
Later
this
week
as
well,
yeah.