►
From YouTube: GraphQL.js Working Group - 2020-10-28
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
C
I'm
actually
finishing
issue
with
steps
to
take.
I
think
we
need
to
wait
a
little
bit
and
plus
I
will
think
people
because
as
understand
the
earthquake
changes
in
to
winter
time
from
summertime
to
winter
time
and
it's
everywhere,
except
like
u.s
and
australia,
or
something
like
that.
So
I
think
it's
next
week
for
us
yeah.
It's
happened
already
in
ukraine.
C
So-
and
we
have
like
that's
why
it's
like
one
hour
earlier
than
probably
everybody.
D
E
E
Only
another
meeting
I
mean
yeah,
I
think
so-
he's
yeah
it's
in
progress
right
now,.
C
Okay,
yeah,
by
the
way
like
since
we're
small
group
and
the
situation
of
that
happening
in
future,
and
if
you
have
something
important
to
discuss,
it's
okay,
we
can
move
it.
It's
like
it's.
You
know,
since,
since
a
small
group,
it's
still
possible.
E
Yeah
I
mean
with
them
just
checking
what
was
happening
last
last
first
time
I
see
that
we
have
the
differ
and
stream
right
merged
into
master.
C
Yeah
we
will
discuss
it.
I
think
let's
wait
like
five
more
minutes
in
case.
If
somebody
wants
to
join
in,
I
think,
like.
C
C
C
I
think
like
we
can
start
from
introduction
and
I
forget
to
hit
myself,
but
I'm
iran,
I'm
from
ukraine
and
I'm
maintained
crafty
ljs
and
hopefully
it
will
be
more
people
in
future
to
share
with
work
with
so
woody
is
not
here.
I
think
it's
yeah,
it's
you,
but
how
to
pronounce
your
name.
C
A
E
Yeah,
so
I'm
camille,
I
work
with
the
guild.
We
do
yeah
pretty
much
graphql
and
episodes
all
around
it.
So.
H
Yeah,
hey
folks,
I
I'm
I
have
to
add
myself
to
the
list
here.
I'm
gonna
submit
a
pr
right
now,
but
I'm
mike
marcotti,
I'm
mostly
here
to
talk
about
typescript
conversion
of
the
graphical
js
library
and
some
some
particular
goals.
I
have
for
that.
So.
C
Yeah
another
question
for
agenda:
it's
yeah
by
the
way
we're
recording.
So
everything
is
about
to
youtube
and
like
if
you
joined
you
kind
of
agree
with
recording.
If
you
not
agree,
we
can
discuss
it.
And
second
thing
is:
there
is
some
links
in
agenda.
So
if
you
didn't
sign
code
of
conduct,
participation,
guide
and
specification
membership
agreement,
I
encourage
you
to
sign
it
and
actually,
in
future
it
will
be
automatically
checked
by
bot.
C
C
C
E
I
could
I
could
do
notes,
let's
say
tomorrow,
based
on
the
recording,
okay,
okay,.
C
Sounds
great
thanks
a
lot
and
by
the
way,
like
a
big
thanks
to
to
uri
for
creating
a
repo
and
doing
this
work
like
a
gem,
does
read
me
like
entire
infrastructure.
F
C
B
C
C
I
actually
miss
a
bunch
of
a
bunch
of
action
items,
including
this
one.
I
need
to
assign
myself
on
it
and
about
service
level
agreement.
C
Issues
being
answered
this,
the
like.
C
C
C
C
C
And
find
out
that
it's
not
mountainous,
it's
not
like.
We
have
six
maintainers
to
grab
tjs.
We
have
60
maintainers
or
something
like
50
60
people
in
in
graphql
organization
github.
So
I
need
to
contact
yeah.
I
also
need
to
do
it.
C
C
C
C
F
So
I
guess
the
first
thing
is
the
the
pr
for
async
intervals
in
resolvers.
There's
no
braking
changes
there.
It's
a
new
feature,
it's
it's
very
useful
for
stream,
but
it's
kind
of
a
standalone
feature.
So
I
guess
what
are
the
next
steps
for
that?
Is
that
something
that
could
go
in
graphql
15
or
do
we
want
to
it's
in
the
experimental
branch
that
you
publish
but
yeah?
So
I
guess
what
are
the
next
steps
for
that.
C
So,
to
clarify
basically,
first,
I
started
drafting
upon
for
typescript
migration
and
first
point
was
to
release
15.4.0
basic
to
clean
up
to
release
everything
that
we
have
on
master
right
now
and
afterwards.
C
C
C
It's
like
depending
on
timeline,
so
basic
idea
is
to
do
breaking
changes.
Do
migration
on
typescript
and
we
can
much,
I
think,
iteratable
in
parallel
with
squashing
like
final
immigration
banks,
but
right
now
like
it's,
it's
pretty
big
change
and
at
some
point
like
we
just
need
to
just
stop
what
we're
doing
and
just
finish,
typescript
migration.
There
is
a
lot
of
preparation
work
done
and
I
actually
like,
prolonged
it
for
one
time
too
much
like
some
some
stuff
like
deprecation
and
some
other
proposal
for
specification
pairs.
C
C
Let's
agree
that
I
think
iteratable
would
be
first
feature
in
pipeline
yeah.
So.
F
Okay
sounds
good,
so
I
so
so
we'll
just
see
if
we
get
any
feedback
from
the
experimental
branch.
While
you
guys
are
working
on
the
typescript
migration.
C
Yeah,
what's
what's
so,
since
our
goal
is
to
to
get
feedback,
I
feel
like
a
milestone
for
us
would
be
to
share,
like
example,
project
on
how
streaming
d4
working
or
some.
C
C
F
It's
mostly
compatible.
I
have
a
pr
to
relay,
but
they
had
kind
of
said
they
wanted
to
wait
for
it
to
be
merged
first.
So
it's
a
bit
of
a
chicken
and
egg,
but
I'll
I'll
ping
them
again
and
see
if
they
can
get
that
change
merged
in,
but.
B
C
So
I
think,
like
a
good
goal
to
work
in
parallel,
not
to
waste
this
time
for
typescript
migration
is
that
we
can
create
sample
project
by
the
way.
If
you
wanted
to
be
a
foundation
repo,
I
can
ask,
I
don't
think
it
would
be
any
problem.
You
can
just
create
a
repo
on
the
foundation
for
streaming.
D4
example,
and
I
can
give
you
a
commit
right
and
you
can
create
like
simple
server
and
simple,
like
front-end
demo,
if
it's
something
that
you're
interested
in
like
for
people
like
to
try.
F
C
Yeah
great,
it's
actually
yeah
yeah,
yeah
and.
H
This
is
all
talking
about
pr
2757
right,
the
the
racing
hitter
of
all.
I
know
that
there
had
been
a
couple
like
stabs
at
this.
C
No,
there
is
like
it's
actually
timeline
is
a
little
bit
different,
so
main
feature
is
stream
and
deferral,
but
problem
with
yeah.
Sorry,
because,
like
I'm
in
contact,
so
I
forget,
I
need
to
explain
like
a
context
plus
yeah
we're
on
youtube.
So
it's
important
for
people
to
understand
what
we're
actually
discussing
so
idea
is
that
there
is
a
spec
proposal
for
streaming
deferral
and
on
working
group.
Everybody
like
agree
with
current
current
proposal.
C
Fit
all
the
main
use
cases
and
basically
we
want
to
get
feedback.
So
it's
frozen
on
this
backside,
basically
like
lee
and
like
entire
work
and
group,
agreed
that
right
now
we
need
to
collect
feedback
and
to
collect
feedback.
We
need
to
release
something,
but
at
the
same
time
we
don't
want
to
for
people
to
be
dependent
on
something
that
it's
not
standard
yet.
C
So
that's
why
it
lived
for
a
long
time
as
pr
that
rob
and
lillian
created
together
and
maintain
it
and
the
rebased
big
thanks
for
of
this
effort
on
of
rebasing
it
it's
a
lot
of
work
not
only
like
writing
it,
but
constantly
replacing
it
so
and
part
of
this
pair
whisperer
have
two
parts
or
one
is
actually
add
stream
and
d4,
and
another
part
is
changing
internal
mechanism
of
execute
function
to
support
async
iteratables.
C
So
that's.
Why
rob
split
it
up
in
a
separate
part?
And
imagine
I
think
it
ratable
it's
not
broken
by
spec
changes,
so
we
can
merge
it
right
now.
Issue
here
is
that
its
affect
performance
potentially,
and
it's
affected
like
a
bunch
of
basically,
we
didn't
change,
execute
for
a
long
time.
C
Execute
function,
measure
away
for
a
long
time,
and
there
is
nothing
better
with
it.
We
actually
need
to
do
it.
It's
just
like.
We
need
to
review
it
super
careful
and
to
be
sure
that
they
don't
have
normally
leaks
and
rob
did
the
great
job
he
created
like
benchmark
for
it,
and
there
is
some
changes
to
benchmark.
So
I
think
iteratable
pr
is
is
a
purely
like
review
effort
and,
like
figuring
out,
if
every
every
corner
case
is
covered.
F
C
Yeah
and
for
394
it's
it
will
leave
for
some
time
as
a
feature
branch.
At
least
a
feature
branch
will
work
for
us.
If
it's
not
like
maintain
like
maintaining
nightmare,
if
it's
maintaining
a
nightmare,
we
can
try
some
different
approach,
but
basically
right
now
we
want
to
add
something
for
people
to
use
and.
C
But
when
I
review
pr
it's,
there
is
some
changes
that
we
cannot
add
under
experimental
fork
like
changes
to
typings
because
execute
return,
async
and
iteratable
for
streaming
default
purpose,
because
you
don't
getting
one
response,
you're
getting
multiple.
C
That's
why
we
discussed
with
rob-
and
I
suggested
that
we
try
feature
branch
approach
because
we'll
keep
different
flux
to
a
minimum
and
since
graphql
chess
is
good
dependency,
so
we're
already
paying
a
price
for
for
having
graphql
dependency,
and
you
experience
every
time
that
we
release
new
braking
version
because
entire
ecosystems
should
update.
But
at
the
same
time
we
have
positive
think
that
you
can
just
replace
graphql
15.4.0
with
15.4.0
experiment
of
3.4,
and
everything
should
work,
as
is
so
without
like
updating
dependency
and
bunch
of
other
packages
yeah.
C
So
we
try
this
approach
and
if
it's
work,
we'll
continue
to
do
that.
If
it's
not
work,
we
we
can
try
something
else,
even
though
I
can
return
back
to
like
feature
idea.
But
idea
right
now
is
to
try,
with
like
experimental
releases
cool
and
by
the
way,
by
the
way
we
can
try
it
for
other
features,
not
only
stream
id
for
any
big
feature
that
we
want
to
collect
feedback
on,
and
we
cannot
add
to
master
because
we
like
a
design,
is
not
fine,
otherwise,.
H
Yeah
that
makes
sense
yeah.
I
think
the
the
challenge
is,
is
always
going
to
be
finding
when
to
where
to
put
the
feature
freeze
right
because
like
if
we,
if
we
freeze
it
before
this,
we
have
to
then
separately
convert
all
of
this
to
typescript.
F
C
F
No,
I
don't
think
so
so
I'll
I'll,
keep
this
pr
to
date
or
I'll
I'll
have
to
I'll
have
a
local
branch
where
I
keep
it
up
to
date,
as
the
typescript
changes
emerged
and
then
I'll
need
you
to
force
push
it
to
the
feature
branch
on
graphql
and
I'll.
I'm
gonna
take
a
look
at
that
example.
Repo
and
maybe
I'll
make
another
one
too.
F
C
Connected
to
other
projects,
so
we
about,
I
can
help
you
with
releasing
express
version
and
if
you
need
any
other
help
yeah
we
can
ping
or
discuss
it.
I
cannot
help
you
with
it
away
because
it's
you
and
facebook,
but
without
yeah
with
everything
else.
If
you
need
like
to
have
more
visibility,
we
can
tweet
it
from
foundation.
C
A
tweet
twitter
account
to
do
anything
else.
Plus
we
have
a
book
foundation
book
if
you're
interested,
I
can
send
you
a
link
and
we
can
have
like
some
small
articles.
Just
saying
recover,
can
feedback
about
this
feature
thing
like
that,
both
like
technical
and
public
relation,
because
I
like
signed
contract
with
foundation
and
I'm
in
contact
with
some
guys.
So
it's
actually
my
responsibility.
The
community
management
is
my
responsibility,
it's
part-time
job,
but
so
feel
free
to
pin
me
about
that,
and
I
can
help
you
with
different
aspects
of
this
feature.
So.
F
Yeah,
so,
as
far
as
that,
express
graphql
is
ready
to
be
published.
The
same
way
that
graphql
js
was
for
the
for
everything
else.
I
think
ricky
is
working
on
supporting
graphical
and
yeah.
I
I
could
I'll
draft
up
a
blog
post
if
I
think
that
would
be
good
to
get
more
people
aware
that
this
branch
is
is
there
and
they
could
try
it
out
now.
C
Sound
sounds
great
qualification
about
experts
graphically.
I
want
to
do
the
same
as
graphql
js,
so
I
want
to
create
like
a
new
release.
G
C
C
So
I
feel
like
we
need
to
use
this
opportunity
to
do
some
other
things
like.
Since
we
have
a
feature
phrase.
We
can
switch
main
branch
from
master
to
mine
since,
like
all
the
projects
doing
that-
and
we
do
feature
freeze
anyway-
and
we
break
people
in
appears
in
major
way
anyway-
so
not
to
do
it
twice,
we
can
do
it
at
the
same
time.
C
C
So
right
now
we
have
mjs,
but
there
is
some
like
so
it
worked
with
webpack
and
it
worked
with
like
some
bundlers,
but
it's
not
working
with
it's,
not
working
with
recent
releases
of
node
js.
That's.
H
All
that
whole
story
is
quite
a
quite
a
thing.
C
C
It's
like
yeah,
so
let's
not
go
into
details.
I
spent
last
week
I
spent
like
a
day
if
trying
to
do
it
on
right
now
without
breaking
change.
I
don't
think
it's
possible,
but
there
is
that
we
break.
Somebody
is
big
and
next
person,
yeah
and
person
reported
in
like
a
week
and
we
stuck
in
typescript
conversion.
Technically
we
can
use
a
tag
and
release
new
version,
but
it's
problematic
so
yeah
and
another
thing
is
to
remove
flow
specific
workarounds.
We
have
a
bunch
of
them.
H
C
Yeah,
so
what
what
we
learn
from.
C
So
saheed
created
a
typescript
pr
and
I
basically
suggest
him
an
immigration
plan
and
he
executed
on
it,
and
so
current
concept
is
to
move
typescript
file
or
js
files
to
typescript
not
to
lose
commit
history
or
blame.
I
feel
like
blame
is
most
important
thing
like
on
open
source
project
with
big
and
with
long
history.
So
we
automatically
lose
four
typings,
but
idea
is
that
we
separate
all
the
braking
change
changes
and
do
them
before
typescript
migration.
C
So
after
typescript
migration,
we
can
try
two
approaches.
We
can.
There
is
some
projects
for
automatically
converting
dts
files
to
four
typings,
or
we
can
yeah
that.
C
Yeah
so,
ideally
it's
its
own
set
of
problems
because,
like
people
I
spoke
with
the
people
from
other
communities,
from
python
communities
and
from
other
languages
who
wanted
to
contribute
to
reference
implementation,
especially
stuff
that
they
learned
in
their
own
implementation,
and
they
said
that
four
typings
was
a
barrier
for
them
to
contribute
because
for
his
learners,
have
a
steep
learning
curve
and
it's
hard
to
find
resources
on
the
internet
about
it.
So,
ideally,.
H
Yeah,
you
know
who,
who
the
is
it
just
generally,
that
we
want
to
continue
to
provide
support
for
flow
or
like
this?
We
specifically
need
it
or
does
yeah
another.
C
C
E
C
H
I'll
create
an
issue
just
so
that
we
can
gather
people's
oh
yeah
yeah,
because
because,
if,
if
it
turns
out
that
nobody
at
facebook
and
not
many
people
in
the
community
need
flow
types,
it'd
be
nice
to
get
rid
of
them
as
part
of
this
breaking
change.
So
we
don't
have
to
do
it
as
a
part
of
another
breaking
change.
C
H
C
Like
maintainers
to
be
responsible
for
for
updating
four
types
for
everybody
or
like
to
block
releases
and
if
all
types
are
updated,
so
I
don't
think
it
will
work
so
yeah
starting
discussion,
I
think,
is
good.
C
I
I
don't
think
we
can
measure
it
somehow
if
somebody
depends
on
for
or
not
with
ideas
that
will
release
some
version
with
some
like
prerelease
version,
probably
bad
or
alpha
when
we
finish
typescript
conversion
without
flow
type-ins,
and
it
will
also
give
us
some
feedback
how
people
do
people
really
need
for
typing?
But
anyway,
even
if
we
decide
not
to
support
it,
I
think
we
need
to
try
to
make
life
easier
for
people
who
who
need
it.
C
So
we
need
to
two
steps
here
is
to
separate
breaking
changes
from
typescript
conversion
and
to
do
breaking
changes
before
at
least
like
breaking
changes
that
we
anticipate
to
do
it
before
typescript
conversion.
So
when
a
person
trying
something
they
can
yeah
before
going
too
deep,
like
yeah.
Sorry,
sorry
about
that
yeah
return
back
to
goals
like
does
anybody
have
some
feel
like
it's
list
of
goals
is
enough
or
we
need
to
add
something
or
remove
something.
H
I
I
I
might
make
it
explicit
that
the
that
one
of
the
goals
is
just
correct
typing,
because
it's
not
just
converting
the
existing,
like
definition,
types
from
definitions
to
like
actual
like
typescript
types
in
the
code
base,
but
like
actually
fixing
them
because
they're
kind
of
broken
at
the
moment.
H
Both
both
broken
in
in
one
sense
like
type,
for
example.
If
you
have,
let
me
think
about
it.
H
Okay,
if
you
have
like
arguments
that
are
defined
on
different
fields,
typescript
will
infer
that
the
arguments
between
every
field
are
the
same
unless
you
explicitly
specify
them
in
your
function
like
like
each
fields
resolvers,
if
you
just
provide
an
untyped
like
function
and
rely
on
inference-
and
you
use
oh
another
related
to
that
is-
is
if
you
do
type
them.
H
Actually,
if
you
do
type
arguments
it,
I
think,
at
least
in
the
most
recent
version
of
typescript
is
failing,
because
arguments
are
defined
as
like
a
a
object
with
keyed
by
string
and
like
unknown
values
or
something,
and
so
you
can't
like
destructure
directly
within
the
like,
like
function
arguments,
there's
there's
definitely
like
several
pieces
that
are
like
actually
like
a
little
broken,
but
then
beyond
that,
there's
just
a
greatly
reduced
amount
of
kind
of
like
specificity
that
you
can.
H
You
can
get
right
like
a
scalar
is
just
a
scalar
and
we
don't
really
have
any
concept
of
a
string,
scalar
versus
a
number
scalar
versus
you
know
what
those
like
actually
resolve
to,
if
I'm
correct
in
in
terms
of
like
your
return
types-
and
so
you
know
making
like
adding
generics
in
a
lot
of
places,
is
also
necessary.
I
mean
these
are
all
the
things
that
are
breaking
changes
from
the
type
definition
standpoint.
H
None
of
these
should
really
be
breaking
from
an
execute
from
a
like
a
standpoint
of
like
javascript
right,
like
none
of
the
none
of
the
the
functionality
in
the
runtime
really
needs
to
change
at
all,
but
I,
but
we,
like
my
understanding,
is
there.
There
is
my
goal
here
is
definitely
to
break
the
typescript
like
definitions,
so
that
they
are
more
correct
and
more
useful.
C
Couple
point
on
that,
so,
what's
definitely
goal
is
to
start
doing,
I'd
remember
how
it's
called
in
english,
dog,
feeding,
dog
food
and
so
eating
your
own
stuff.
So
when,
when
we
migrated
tests
to
typescript-
and
we
start
using
our
own
definitions,
one
of
the
problem
with
typescript
previously
was
that
we
don't
use
it
internally,
so
we
dependent
on
people
fixing
gts
files
sprs
so
like
we,
we
cannot
detect
yeah.
So
this
type
of
missing
features
and
this
type
things
is
happening
automatically
when
we
switch
tests
to
to
typescript.
C
So
we
would
try
on
the
later
stages,
not
the
first
stages
and
first
stages.
If
we
might
missing
something,
we
will
probably
put
ignore
chase
ignore,
but
on
the
later
stages,
before
release,
definitely
before
release,
we
will
try
to
address
all
these
workarounds
because
they
become
visible
in
our
tests
so
like.
If
type
inference
is
working
incorrectly,
we
will
try
to
fix
it.
C
C
The
thing
that
I
I
discussed
like
previously
is
kind
of
having
two
type
of
wines
active
wines
and
para
like
like
not
just
have
active
one
and
not
active
one
so
meaning
like
we
switch
main
to
be
kind
of
unstable
and
have
a
stable
line.
So
when
we
release
six
and
zero
zero
will
wait
a
little
bit
for
everybody
to
migrate
and
start
using
that.
But
after
that
we
can
switch
switch
like
mine
to
be
unstable
totally.
H
H
Constrained
by
the
release,
the
by
the
the
difficulty
of
major
releases
in
general
right.
So
so,
if
we
are
to
do
this
typescript
version
and
get
it
only
to
a
stage
that
is
as
good
as
the
current
flows
types,
we
miss
out
on
the
opportunity
to
make
it
better
than
the
current
flows
types
and
there
are
serious
opportunities
to
make
it
better.
H
And
if
we,
if
we
do
that
and
just
publish
them
as
good
as
the
flow
types
in
our
16
release,
we
have
to
wait
until
we
have
to
perform
another
major
release
to
get
them
better
because
they
would
kind
of
by
definition,
break
typescript
integrations
because
the
types
would
change.
They
might
not
break
any
runtime
anything
right.
They
might
not
even
change
the
outputted
javascript
in
any
way,
but
the
types
themselves
would
definitely
break,
and
so
is
that
something
you
would
want
to
do.
Two
different
major
releases
on
or
yes,.
C
In
that
case,
we
can
so
like
general
idea
and
what
we
tried
and
previously
is
too
much
is
too
much
new
releases
with
node.js
dropping
support
for
older
version
of
node
yeah,
because
it's
maintenance
headache
and
you
need
to
do
break
and
change
anyway,
because
all
that
dependency
and
other
dependencies
stop
supporting.
So
you
cannot
test
on
old,
node.js
version,
so
I
feel
like
we
will
need,
I
think,
it's
in
january
or
february,
not
just
doing
like
break,
dropping
note,
8
or
not,
not
10.
I
think,
like
it's
dropped
in.
C
So
I've
we
can
do
next
breaking
releaser,
like
one
thing
I'm
worried
about,
is
that
features
we
need
to
experiment
with.
So
I
type
script
typings
are
used
by
libraries
with
very
extensive
typescript
users
themselves
like
nexus,
and
so
I'm
worried
graphql
code
like,
for
example,
some
non-trivial
usages
as
an
example.
C
H
I
see
what
you
mean
here
about
like
trying
to
iterate
on
the
types
independently.
I
I
think
that
the
real
challenge
there
comes
in
with
that,
instead
of
iterating
on
a
d.t.s
file
right,
we
would
be
iterating
in
ways
that
actually
affect
that
are
actually
used
within
the
code
base
itself.
Right
so
it'd
be
very
it's
it's
much
more
difficult.
Once
we
have
everything
converted
into
typescript
to
make
changes
to
internal
types
without
changing
them
everywhere
else
in
the
source
code
that
references
them.
E
B
E
Add
that,
for
example,
if
we
want
to
check
if
this
type
document
node
think
it
works,
if
it
works
or
even
like
it's
a
graphql
js
either
even
on
like
super
extensive
usage
works
with
typescript.
We
have,
I
don't
know,
like
six
pretty
large
code
bases
fully
typed
with
typescript
with
some.
You
know,
with
some
pretty
complex,
subtypes,
etc,
and
also
with
the
cogen
and
base.
Even
with
the
code
gen,
we
can
ask
people
to
test
it.
E
So
if
we
have,
let's
say
a
graphql
js
that
release
with
let's
say
a
canary
release
or
like
rc0,
whatever
we
can
check-
or
even
like
I
don't
know
like
an
artifact
on
github
or
like
whatever
just
the
source,
we
can
make
sure
we
can
ask
a
bunch
of
people
and
we
can
test
it
on
our
project
and
see
if
it
works,
because
we
use
the
typescript
pretty
much
everywhere.
So
yeah.
C
C
We
definitely
want
to
improve
typescript
typings.
So
it's
like
some
some
things.
We
didn't
some
template
arguments
we
didn't
add
just
because
it's
full
limitation,
because
in
four,
if
you
had
even
one
template
arguments,
you
need
to
add
empty
and
go
brackets,
even
if
it's
optional,
which
is
pretty
weird
but
yeah.
C
So
that's
why
we
didn't
add,
like
template,
arguments
to
scours
or
anything
else,
it's
blocked
it,
and
second
issue
was
if
we
cannot
edit
in
full
it's
hard
to
keep
in
sync
dts
and
four
files,
especially
since
typescript
represents
majority
of
people
who
use
graphql
types
in
sla
type,
crypt
types,
not
as
full
types,
and
we
don't
have
any
way
to
test
it.
That's
why
idea
was
to
keep
it,
I
think
as
much
as
possible.
That's
why
we
didn't
introduce
new
things,
so
I
I
would.
I
would
separate
it
free
stage
stage.
C
One
is
just
to
migrate
files
stage.
Two.
Is
that
since
we
immigrated
test
files
and
added
bunch
of
this,
ignore
figure
out
a
way
how
to
address
it
to
clean
up
our
own
tests?
And
I
think,
like
our
own
tests,
represent
the
really
good
test
scenarios
and
it's
with
two
things:
definitely
going
into
1600.
C
C
D
H
Major
libraries
upgrading
in
their
own
release,
candidates.
C
It's
so
yeah
and
the
question
is:
should
we
at
this
point,
try
to
improve
typescript
typing
or
we
cut
a
release
and
do
and
one
type
improvement
for
next
version,
and
actually
it's
after
some
time,
actually
switch
master
to
next
version
and
release
like
alpha
version
and
start
working
with
typescript
things
with
the
goal
to
do
it
in
in
winter?
When
not
just
pro
drop
new
new
version.
H
And
just
to
throw
out
there
end
of
april
is
the
deprecation
of
v10.
C
C
That
people
can
create
new
prs
against
in
typescript,
so
we
don't
need
to
rebase
this
feature
or
like,
like
do
some
other
things,
so
I
guess
to
to
limit
the
scope
of
typescript
conversion,
but
I
agree
with
you:
it's
just
that.
I'm
worried
with
improving
typing
it's
a
territorial
process,
so
we
change
something.
C
We
need
to
get
feedback
from
from
people
and
from
major
libraries
like
nexus
and
graphical
compose
and
some
some
other.
We
can
break
them
and
they
can
figure
out
the
ways
to
improve
it.
So
I
prefer
that
we
pro
have
a
saturated
process
for
like
couple
of
months
to
know
that
we
have
really
good
typescript,
typings
yeah.
C
Yeah
and
I
feel
like
we're
like
slowly
moving
slowly
moving
project
since
like
right
now,
we
form
a
group
and
people
actually
volunteering
to
do
stuff
and
the
switching
to
type
trip
that
should
improve
contribution,
and
I
I
will
work
on
the
processes.
C
Why
I
added
then
here
is
because
some
people
get
like
manual
conversion
from
fall
to
typescript
for
this
file
to
be
usable
in
deno,
and
I
feel
like
we
can
capture.
We
can
use
this
effort
in
improving
graphql
for
entire
javascript
ecosystem,
not
for
white
people
doing
their
own
manual
conversions
to
then.
C
H
Items:
okay
in
terms
of
mechanics
for
this,
I
know
that
there's
there
are,
there
already
exist.
Some
the
types
pull
requests
for
typescript
converted
tests
is.
Is
that
the
basis
that
we're
going
to
start
with
or
are
those
probably
like?
Are
there?
Are
those
going
to
need
to
be
redone
or
are
those
kind
of
good?
The
way
they
are
might
get
merged
into
main?
Once
we
do
the
branch?
Conversions?
H
C
Yeah,
I
will,
can
you
send
it
in
a
chat,
so
everybody
yeah
link
to
it
so
sahih
to
work
on
guestbook
conversion,
but
since
now
guilt
helping
with
that.
C
If
you
look
into
commits
so
it's
have
this
idea
of
converting
everything,
so
it's
like
every
every
commit
changing
something
in
the
whole
files
so
like.
For
me,
my
challenge
was
reviewing
stuff,
because
when
you
do
something
inside
ed
id,
you
convert
some
type
photo
type
script,
you
do
it
iteratively
and
you
kind
of
ensure
everything
is
correct,
but
you
know
like
for
me
to
go
through
a
bunch
of
bunch
of
monotonous
changes
as
it's
really
like
killing
my
brain,
but
at
the
same
time
I
don't.
C
We
have
like
really
good
code
quality
on
graphql
js
and
I
don't
want
to
over
it
so
approach
that
say:
he'd
want
you
to
try
is
to
create
with
commits,
do
one
thing
across
the
whole
repo
and
for
now
it's
working
good
and
as
added
bonus,
we
can
it's
easier
to
rebase,
because
when
you're
basing
the
stuff,
you
basically
understand
what's
happening.
It's
not
like
the
whole
thing
is
changed.
That's
why
perfect
approach
is
problematic
because
files
have
interdependency
between
each
other
and
we
cannot.
E
C
C
C
H
C
Yeah
well,
I'm
I
think,
like
we
worked
with
saheed
for
like
a
week,
all
right,
yeah
yeah,
by
the
way
like,
can
you
share
feedback
on
how
it
was,
and
is
it
like
how
how
like
hard
it
is
like?
Is
it
do
you
think
it's
like
good
approach
on
or
we
need
to
try
something
else.
A
But
I
think
it's
like
better
way
to
do
this
because,
like
at
times
when
I'm
like,
I
can
just
do
mostly
like
command,
f
and
command,
replace
for
most
of
them,
like
those
were
the
easiest
ones.
And
after
that,
like
I
went
like
off
tangent
at
times,
because
I
was
trying
to
fix
something
else
like
semantic
issues
instead
of
syntax
issues.
A
But
then
we
came
back
on
fixing
syntax
issues
first
and
like
this
way,
works
better
and,
like
I'm
like
more
productive.
Doing
this
way
like
having
everything
it
is
one
chunk
and
like
then,
I
learned
tricks
from
one
like
how
to
do
get
read
this
like
edit,
the
whole
thing
and
like
I
can
revert
to
my
commits
back
like
it's.
F
C
And
for
me,
it's
most
important
thing
is
that
it's
easy
to
review
so
we're
a
name.
First,
an
intention
is
to
not
to
squash
with
commits
but
replace
them
and
merge
them.
So
we
can.
When
you
go
through
a
blame,
you
can
understand
why
certain
thing
is
changed.
It's
not
like
one.
One
giant
commits
that
change
everything
and
it's
hard
to
follow.
C
That's
why
first
commit
is
actually
renaming
js2ts,
so
we
don't.
You
know,
always
think.
If
we
change
too
much
stuff
inside
a
file,
I
git
doesn't
recognize
it
as
a
move.
It's
recognized
you
as
delete
file
and
add
the
new
one
yeah.
So
we
don't
want
all
the
histo
like
blame.
C
And
the
files,
so
what's
right,
first
commit
rename
it
yeah
and
for
me
like
I
can.
I
can
review
a
file
and
then
show
that
changes,
because
it's
like
okay,
you
remove,
plus
and
request,
is
that
it
only
it's
like
I
spent
30
seconds
on
reviewing
that
and
for
yeah.
So
basically
idea
is
to
continue
doing
that
and
also
I
will
create
a
couple
tasks,
because
why
people
want
to
help,
and
last
time
we
agreed
that.
C
C
C
It's
not
a
good
first
pr
or
it
is
it's
not
a
good
first
issue.
It's
like
really
complicated,
messy
stuff
with
defined
properties,
and
but
if
somebody
wants
to
attack
it,
because
I
don't
want
to
migrate
with
this
thing
into
typescript,
I
want
to
make
that,
like
properly
written
year,
six
class,
maybe
with
some
hacks
to
for
specific
things,
to
to
maintain
stack
traces
and
some
because
in
errors
we
need
something
in
this
course.
We
need
some
hacks,
it's
like
essential
complexity,
but
there
is
some
accidental
accidental
complexity.
C
Basically,
move
benchmark
into
separate
folder
and
make
it
independent
from
from
sfc
folder.
So
right
now
it's
basically
use
package
so
where
we
build
the
package
and
run
benchmark
on
top
of
packages
package,
so
we
can
migrate
benchmark
even
right
now
it
will
just
use
dts
typings
that
we
already
have.
So
I
will
create
issues
like
that.
C
And
somebody
can
start
experimenting
with
dts
to
flow
conversion
to
to
see
if
it's
like
at
least
like
converting
our
existing
dts
type-ins
or
it's
like
so
so
things
like
that
can
be
working
parallel.
I
like
with
one
thing
that
we
cannot
split
with
basic
conversion
between
people,
because
file
based
conversion
is
many.
People
can
work
on
it,
but
review,
and
this
would
be
a
nightmare,
so
mikey
your
own
mute.
C
H
Thank
you.
So
that
sounds
like
you.
You
really
have
this.
This
whole
first
step
like
well
underway
here,
so
I
I
I'm
just
gonna,
you
know
take
take
a
step
back
here
and
please,
let
me
know
if
there's
anything
that
I
can
do
to
help
you
just
like
yvonne
was
saying.
H
I
think,
there's
like
it's
impractical
to
have
two
people
in
the
you
know:
syntactic
conversion
kind
of
thing,
so
I'll
just
keep
keep
out
of
the
kitchen,
but
like
some
of
the
things
that
were
that
are
that
I
am
most
interested
in
in
getting
here,
are
kind
of,
as
you
were
saying,
some
of
the
more
semantic
changes
and
some
of
the
logical
changes
to
the
types
which
are
like
things
that
we
can
discuss
and
work
on
like
after
the
syntactic
like
kind
of
stuff
that
you're
already
working
on,
I
just
pasted
in
the
issue
that
kind
of
details.
H
This
is
the
piece
that,
like
I,
am
highly
motivated
to
do
I
working
with
a
lot
of
people
who
are
you,
know,
good,
really,
good,
javascript
developers,
but
are
relatively
new
to
typescript
and
relatively
new
to
graphql
and
the
the
flow
of
having
to
like
define
types
and
like
both
in
graphql
and
in
typescript,
in
terms
of
like
the
you
know,
like
resolver
types
or
the
fact
that
types
that
all
of
the
type
checking
that
graphql
js
does
currently
is
in,
like
a
runtime
kind
of
strategy
is
very,
very
difficult
for
these.
H
H
So
what
I
am
really
interested
in
is
getting
getting
the
just
the
the
linking
of
typescript
and
the
actual
you
know,
graphql
definitions
like
somehow
tighter
and
like
inferable,
and
so
whatever
I
can
do
to
that
like
for
that
goal,
whether
it's
just
helping
out
with
the
typescript
conversion
in
general
or
trying
these
things
after
the
fact
I
like,
let
me
know
where
I
can
be
useful
and
I'll
I'll
try
to
get
stuff
in
here.
C
C
I
use
it
just
as
like
basic
checks,
so
you
can
review
stuff
that
saheed
create
right
now
and
if
you
see
some
way
how
to
improve
like
every
every
commit.
Maybe
we
choose
like
not
not
the
right
way
to
convert
attack,
not
a
dramatic
way
by
the
way
go.
I
forget
to
write
it
and
go
list,
it's
not
to
convert
to
typescript
but
to
convert
to
a
idiomatic
type
script.
C
Yeah
we
want
to
to
use
like
to
write
stuff
how
it's
written
in
typescript,
if
it's
not
involved
like
a
huge
changes.
That's
why
that's
why
I
haven't
break
and
change
it's
beneficial
because,
for
example,
error
error
thing
we
want
to
rewrite
into
a
class,
so
there
is
couple
issues
like
that.
C
C
C
So
at
some
point,
if
you
see
this
ignore
somewhere
and
if
we
hit
something
we'll
ping,
you
and
yeah
yeah
and
like
people
who
are
interested
in
helping
how
to
convert
it
properly
and
when
we
convert
syntax
most
of
the
stuff
and
type
checking
is
working
and
we
like
create
is
a
great
branch,
so
merchant
master,
depending
on
like
other
activities
going
on
and
people,
can
help
solve
this-
ignore
things
in
parallel
with
factors
parallel
wise,
especially
if
like
issue
is
not
in,
is
inside
the
function
or
inside
the
file.
C
H
I'll
review
the
pull
request,
as
it
exists
currently
and
I'll
make
sure
to
follow
along.
C
Yeah
another
thing:
if
you
maintain
somewhere,
but
you
use
some
way
but
at
some
point.
C
Right
now
we
have
a
mechanist
releasing
experimental
releases,
so
we
don't
even
need
to
to
to
wait
for
15
for
like
switching
masters
or
something
we
can
just
like
release
experimental
right
now,
it's
too
early,
so
I
think,
like
we
still
have
a
lot
of
issues,
but
I
think,
like
in
a
week
we
we
would
have
like
some
early
version
of
conversion
that
people
can
test
against.
C
Yeah,
I
think
it's
if
yeah
and
yes
as
I
promised,
I
will
as
a
show
I
have
some
I
started.
Actually.
I
started
today
to
write
in
roadmap
yeah.
I
will
yeah.
I
will
finish
it.
C
It's
actually
good
that
he
pinned
me
on
what
to
do
next
and
what
to
move
so
it's
similar.
It
actually
does,
I
think,
and
for
us
I
I
feel
like
it's
a
good
opportunity
for
people
to
collaborate,
because
if
we
design
this
migration
process
in
a
way
that
easy
to
review
is
mean
like
more
people
can
can
be
sure
that
the
apr
is
merged
and
they're,
not
stacked
and
they're
doing
something
useful
because
for
new
features
new
stuff.
C
H
C
A
C
There
is
like
that
pure
typescript
conversion
task
yeah,
and
it's
involved
like,
for
example,
right
now.
You
we
need
to
make
everything
green,
every
check,
green
on
your
pr
and
at
some
point
we
need
to
enable
back
es
intervals
and
we
need
to
fix
tsd
validation.
So
I
think,
like
we
have
clearly
defined
work
for
for
next
couple
weeks.
Okay,
and
as
as
I
said,
I
will
report
all
each
all
stuff
that
can
be
done
and
for
our
separate
issues.
C
H
Everything
there's
only
one
person.
I
know
who's
properly,
put
in
the
effort
to
understand
that
at
all
and
you've
probably
worked
with
jaden
in
the
http
thing.
I
know
he's
a
big
fan
of
all
that
stuff.
I
can't
stand
the
all
the
workarounds
you
have
to
do
for
esm,
but
but
he's
a
resource
we
can
reach
out
to.
If
we
decide.
C
C
Yeah
yeah
one
thing
I
wanted
I
want
to
have
for
like
typescript
conversion
done,
because
I
feel
like
esm.
We
can
finish
up
like
typescript
conversion
and
like
some
stuff
and
clean
up
some
stuff
and
work
on
a
summon
parallel,
but
I'm
not
sure
because
immigration
to
typescript
involved
bunch
of
changes
and
builds
up.
I
don't
feel
like
we
can
start
this
and
before
that
yeah.
C
We
need
to
write
transformers
stuff
like
that,
so
I
feel
like
that's
why
it's
it's
coming
after
typescript
conversion
and
the
same
dinner
support
is
also
dependent
on
typescript
and
a
small
update
on
that.
I
I
spoke
exchange
some
emails
with
montana
of
dinner,
destroy
and
they
holding
graffiti
names
for
us.
C
From
squatting
by
other
packages,
because
previously
it
was
like
somebody
already
released
manual,
conversion
of
graphql
js
there
so
like
after
touchscript
conversion,
we
can
attack
esm
and
you
know,
and
parallel
and
finish
last
bits
and
pieces
of
type
three
conversion
and
make
maybe
some
improvements,
a
small
improvement
to
type
things
like
template
arguments
this
all
always
things
can
be
done
parallel
after
we
migrate
bunch
of
like
most
of
us
after
we
did
by
a
big
chunk
of
typescript
migration.
C
So,
like
answering
as
I
answer
a
new
question,
it's
like
a
lot
of
work
for
you
to
do.
You
know
like
with
syntax
conversion,
and
there
is
a
lot
of
work
to
do
on
other
aspects,
especially
after
after
like
syntax
conversion
when
stuff
can
be
paralyzed
and
we
can
unfreeze
by
the
way
like
if
somebody
wants
to
to
do.
Some
other
kind
of
you
know
trigger
breaking
change,
breaking
change.
That
is
not
involved
like
design
and
experimentation
phase.
We
can
also
add
it
into
1600
just
after
typescript
conversion.
C
For
example,
some
some
person
asked
to
rename
dangerous
change
to
something
else,
because
you
don't
think
it's
dangerous
like
or
some
other,
like
renaming
or
fixing
stuff
changes.
So
if
you
want
to
push
it,
it
can
be
done
between
finishing
merging
hit
pr
into
master
and
releasing
1600
and
what
time
frame
we
can
accept,
like
with
kind
of
trivial
breaking.
C
C
C
I
will
try
to
give
my
input
on
all
of
them,
but
it's
important
that
somebody
like
moderate
discussion
and
to
keep
people
on
topic,
and
I
will
open
like
technical
issues
like
issue
for
converting
graphql
error
into
es6
class
issue
for
converting
benchmark
into
typescript.
I
will
try
to.
C
C
And
yeah,
so
it's
like
basically
my
task
until
next
working
group
is
to
support
you
in
immigration
report
issues
for
other
people
to
volunteer
and
support
them
and
work
on
this
action
item
from
previous
time
to
finish
them,
to
have
contribution
guide
and
to
have
like
actual
step
by
step,
one
on
what
to
do
and
how
to
collaborate
on
1600
release.
H
Cool
sound
that
sounds
great.
I
I
am
going
to
just
create
those
couple
issues
that
I
said
and
I'm
going
to
review
the
pr
just
looking
at
it
also.
I
noticed
that
there
was
a
reference
to
some
slack
conversations.
C
C
I
will
try
to
release
them
some
of
them
this
week
and
I
will
tag
you
inside
the
issues
so
and
by
the
way.
Big.
Thank
you
for
creating
this
grakhiljs
working
group,
repo
and
action
items
yeah
there.
C
C
So
if,
if
you
have
some
ideas,
how
to
do
stuff
differently
and
some
technical
proposals
and
stuff
like
that,
we
can
do
it
asynchronously
inside
an
issue
and
yeah,
and
the
second
thing
is
there
is
like
something
urgent
that
people
want
to
discuss
before.
We
finish
with
call.
C
Thanks
everybody
and
like
we're,
actually
learning
how
to
do
it
on
the
official
way.
It's
like
for
me.
It's
a
first
working
group
that
I
manage.
I
like
manage
one
one
or
two
course
on
graphql
http,
but
other
than
that.
I
just
participate
and
work
in
groups.
So
I'm
also
learning
and
we're
improving
thanks
story.
We
now
have
for
repo
an
agenda
and
bunch
of
stuff
and
next
time
I
will
try
to
finish
more
action
items
in
timely
manner
and
we
can
continue
from
that
and
then
have
iterative
improvements
and
distribute
work
between
us.
G
I'll
just
add
that,
like
I
don't
know,
if
anyone
took
notes
but
I'll
I
can,
I
can,
even
though
I
did
I
wasn't
in
the
meeting
I
can
volunteer
and
I
can
look
at
the
video
later
and
just
fill
in
the
notes
later.
If,
if
it's
still
necessary.
C
Yeah,
it
would
be
great
by
the
way
I
will.
I
will
create
issue
in
this
repo
with
like
zoom
link,
because
graphql
foundation
have
automatic
transcript
and
I
bought
on
zoom
recordings.
C
So
it
would
be
easier
for
you
because
yeah
you
can
copy
paste
like
zoom
is
mostly
good
with
recognizing
common
english
yeah.
So
to
help
you
yeah,
I
think
it
will
process
in
a
day.
So
I
will
post
friends
for
entering
yeah.
Searchable
notes
is
important
on
on
that
note.
If
nobody
have
anything
to
add,
let's,
let's
finish,
it
continue
in
asynchronous
mode
in
communication
in
slack
and
issues
and
meet
next
month
in
last
wednesday,
wednesday
for
month
and
week
yeah.