►
From YouTube: GraphQL.js Working Group - 2021-01-27
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).
B
A
I
posted
link
to
agenda
and
yeah.
One
thing
I
always
should
say
you
need
to
sign
a
membership
agreement
for
graphql
foundation.
If
you
didn't
do
that,
it's
pretty
easy.
You
can
sign
this
individual
if
you
don't
want
to
put
it
through
legal
department
of
your
company,
just
send
it
this
individual
by
the
way
how's.
My
sound
everything
is
good
on
the
camera
yeah.
A
So
the
same
code
of
conduct
and
participation
guides.
It's
very
easy.
You
just
go
to,
I
think,
like
docusign
and
just
leave
with
signatures
there.
So
let's
introduce
ourselves
using
like
a
order,
inanteneous
section
of
agenda
so
hi
my
name
is
and
I'm
maintaining
graphql
js
and
I
also
work
as
contractor
for
graph
hill
foundation.
C
Oh,
I
think
that's
me
yeah,
so
I'm
camille
and
I
work
with
the
guild.
C
Rob
I
work
for
first
dibs
I've
been
working
on
the
deferring
stream
spec.
A
A
Yeah,
I
think,
like
for
four
people,
and
since
we
actually
have
recording-
and
it's
every
time
go
to
youtube-
I
think,
like
we
should
capture
things
in
agenda
items
like
full
notes
is
less
important.
Maybe
when
we
have
more
people
and
more
topics
to
discuss
will
start
capturing
notes
plus,
if
somebody
wants
you
to
do
it
offline,
we
will
have
recording.
A
So
yeah,
I
think
if,
if
it's
like
a
particular
issue,
we
can
yeah
offline
and
figure
out
like
I
need
to
read
it.
A
Item
number:
seven:
I
think
it's
like
we
first
get
like
just
a
hit
update
and
when
we
discuss
it
as
part
of
discussion.
A
B
A
Yeah,
it's
a
lot
of
tops,
I
like
thompson,
chrome.
So
yesterday
I
missed
deadlines.
A
I
had
like
with
last
time
I
spoke
about
security
fixes
and
finally
figure
out
how
to
do
it
properly.
I
get
for
a
couple
iterations,
that's
why
I'm
like
book
release
a
little
bit
before
publishing
it
officially
scv.
I
need
to
update
14x6
version
to
move
fixed
to
14xx.
That's
why
it's
not
public.
Yet
after
I
release
new
version
of
photon
release
wine
published
cv.
Officially,
it's
not
a
big
thing.
It's
just
like
out
of
memory,
but
it's
nice
to
think
you
can
draw.
A
Server
pretty
easily
with
small
query,
so
something
I
wanted
to
fix
in
1500,
so
I
released
it
yesterday
and
there
is
one
issue
for
from
this
release,
but
since
there's
one
I
think
I
think
it's
more
always
working.
Maybe
I
broke
something
unintentionally
switch
master
to
mine.
It
is
done
big
thanks
to
it
for
his
pr,
so
I
basically
match
his
pr
and
press
like
a
github
button
to
do
it.
Item
number
three.
A
A
So
I
think
I
will
finish
it
tomorrow
so
and
I
also
working
on
this
one
still
have
because
we
want
to
remove
polyfills
in
full
before
releasing
alpha
one.
I
need
to
figure
out
how
to
how
to
disable
fall.
Typings
I
I
will
basically
go
on
standardly
for
standard
clip
and
fix
it
there,
which
is
strange,
but
without
it
we
will
break
flow
before
we.
A
This
thing
yeah:
let's,
let's
keep
original
deadline
because
it's
like
fair,
but
let's
this
one
by
the
way
it's
like
fixed
science
release
script.
We
fix
it
together
with
sahid
in
his
inside
his
pr.
So
it's
green.
The
last
thing
we
have
problem.
We
had
problematic
thing
test
coverage,
but
I
think
fix
it
in
16x6.
I
just
need
to
move
this
commit
into
main,
so
once
ahead
will
replace
his
pr,
it
will
be
green,
except
for
tc
check.
A
A
A
A
C
Yeah
about
the
polyfills,
you
mean
object,
values
and
object
entries.
A
So
the
issue
here
is
that
I
show
this
trick
to
saheed
in
his
pr.
Basically
idea
is
to
keep
2828
to
just
typings,
so
it
should
not
change
any
generated
code
because
we
use
bubble
for
flow
and
for
type
script.
A
What
way
we
ensure
that
we
don't
change
runtime
behavior.
We
will
only
change
types
from
fall
to
typescript
and
actually
like
once
a
hit.
Pr
is
like
that.
So,
if
you
go
to
2828,
generate
and
pam
and
pm
package
before
and
after
2028,
you
have
the
same
exact
javascript
code.
A
A
And
another
thing:
if
wait
or
somebody
will
have
issues
we
can
ask
them
to
test
the
project
or
something
against
alpha
one
and
check
if
it's
present
or
not,
so
we
can
basically
bisect
between
typescript
migration
and
like
code
changes.
What's
what's
why
ideas
and
removing
polyfills
is
the
only
like
issues
we
have
with
this
approach.
Everything
else
is
easily
addressable,
so
it's
strange
that
we
fixing
stuff
and
fall
before
script
migration.
But
what
way
we
can
sure
it's
like
double
check.
A
We
show
that
code
is
100,
sound
in
4
and
100
sound
type
script,
because
both
type
systems
have
their
own
quirks.
Yeah.
It's
like
to
explain
this
issue.
I
I
will
try
to
spend
the
night
like
a
couple
more
hours.
I
spend
like
two
three
two
hours
today
couple
more
hours.
If
I,
if
I
didn't
figure
out
a
way,
how
to
do
it
properly,
I
will
do
some
for
hacking
for
yeah.
A
C
I
mean
we've
got
some
quite
big
code
bases,
so
I
can
just
run
you
know
whatever
changes
we
do
on
them
open
source
and
like
internal
stuff
like
apps,
for
clients,
etc.
So
I
think
we're
good
in
terms
of
like
you
know,
removing
polyfills,
even
because
I
think
the
only
polyfills
that
we
have
is
just
entries
and
values
of
the
object
and
those
are
like
eight
imports,
these
eight
per
each
polyfill.
So
you
know,
there's
not
a
lot
of
change
in
the
code
actually
and
even
in
the
logic.
C
A
A
Yeah,
so
I
still
want
to
do
clean,
clean
migration,
but
if,
if
it
will
walk
a
process,
it's
not
worth
it
so
yeah
one
one
thing
I
can
do
in
parallel:
I
can
gives
a
hit
commit
rights
and
we
can
create
branch
for
2828.
A
A
And
so
we
can
match
official
branch,
so
we
can
create
branch
on
graphql.js
repo
and
we
can
match
like
stuff.
So
we
can
take
stuff
from
from
your
pr
or
stuff
that
you've
figured
out
how
to
fix
and
you
can
submit
it
against
like
a
saheed
pair
on
top
of
his
and
he
can
merge
it
and
that's
why
we
can
split
the
work
in
parallel,
because
right
now,
basically
I'm
booking
you
and
right
now
setup
previously
setup
was
complicated.
A
We
had
like
a
master
and
16x6
from
master
and
2828
from
16x6
with
which
was
bad
for
my
merchant
pair.
So
since
right
now,
I
will
finish
that
tomorrow,
sahid
branch
will
be
on
top
of
on
top
of
mine,
basically
so,
but
way
he
can
start
by
accepting
prs
and
we
can
work
in
parallel
before,
like
before
16x6
16
alpha
release.
Basically,
so
we
can
split
the
work.
A
Yeah,
let's,
let's
switch
to
a
second
topic.
No,
so
let's
see
up
here
so
stop
sharing
and
we
switch
to
second
topic.
Saheed
will
give
update
on
his
pr
and
we
discuss
how
to
how
to
collaborate
on
it.
How
to
like
move
it
forward.
A
B
We
need
to
compare
them
and
be
sure
that
they
are
the
exact
same
you're,
not
breaking
anything
and
then
once
that
is
fixed,
we
need
to
conver.
We
need
to
just
enable
eslint.
So
all
the
linting
rules
are
up
to
date
and
then
enable
the
typescript
eslint
rule.
So
everything
is
an
interface
because
we
bumped
into
an
issue
where
it
was
a
typescript
related
issue.
We
asked
on
typesc,
we
asked
typescript
team
on
that
we
opened
up.
B
B
B
So
that's
why
we
we
have
to
compare
the
dts
files
and
then
then
do
the
migration
to
use
interfaces
just
to
be
sure
that
we
are
not
breaking
any
current
types
in
the
new
system,
because
the
goal,
as
one
mentioned
is
not
to
break
many
big
things.
It
should
be
the
exact
same
from
going
from
a
15
5
to
16
just
difference
between
your
converting
to
ts
file.
Nothing
else.
B
A
A
A
A
So
it's
pretty
self-explanatory
and
I
can
review
it
like
in
in
matter
of
like
three
minutes,
five
minutes
and
just
like
review
and
as
he
said,
we
spent
bunch
of
time
and
even
in
simple
commits,
you
can
discover
some
some
strange
things
or
things
that
should
be
fixed
or
updates
updated
because,
for
example,
I
was,
for
example,
I
think
not
this
one,
but
one
about
yeah.
B
A
Yeah
it's
one
thing:
it
will
some
so
some
fixes
are
not
type
script
related.
They
make
sense
like
as
a
whole,
so
yeah
it
was
marching
to
master
one
thing
that
you
cannot
do
with
like
fast
and
simple
conversion.
A
We
cannot
remove
legacy
legacy
for
stuff,
so.
C
A
All
four
doesn't
support
functional
overloading
in
a
good
way
because,
like
I
think,
facebook
considered
a
bad
practice,
so
we
use
the
workaround
info.
So
if
you
just
like
convert
with
file
to
typescript,
you
basically
lose
ability
to
to
you.
You
keep
forward
around
and
you
will
add,
like
some
technical
grounds
on
top
of
forward
currents,
but
the
correct
solution
here
is
to
just
remove
with
work
around
with
this
declare,
remove
your
sling
command
and
just
do
function
overloading
that's.
Why
and
like
some.
Some
of
these
things
is
contextual.
A
A
So
that's
why,
with
approach
plus
when
we
we
don't
plan
to
squash
with
commit,
is
in
a
response
specifically
says
we
will
rebase
it
on
top
of
main,
so
we
will
keep
all
the
commits
and
since
every
commit
is
like
short
and
concise,
you
can
understand
why
certain
changes
are
so
you
we're
not
breaking
we're,
not
breaking
github
git
history,
so
we
still
have
a
blame.
A
We
still
can
understand
why
the
certain
line
was
added
and
yeah,
as
I
think
what
what's
why
actually,
I
think,
like
sahih,
spent
like
twice
more
time
doing
conversion
in
this
fashion,
but
on
the
plus
side,
it's
cleaner.
We
keep
commit
history
and
it's
easy
to
replace.
That's
why
it's
super
easy.
A
If
I
put
something
on
top
of
six
and
xx,
because
I
hit
this
like
five
couple
minutes
to
replace-
maybe
five
minutes,
there's
some
minor
conflicts
so,
and
so
I
want
to
ask
camille:
did
you
use
as
a
hit
pr
2828
as
a
basis
or
what
was
your
approach
for
doing
this
migration.
C
Yeah
I
used
as
a
base,
but
let's
say
two
weeks
from
now
something
like
that.
I
mean
two
weeks
two
weeks
before
so
yeah.
A
C
Those
are
just
flow
types
and
yeah
and
basically
the
types
that
were
before
and
on
the
second
pr
are
basically
the
same.
It's
just
that
I
changed
types
to
interfaces
and
applied
few
fixes.
Just
so
we
get
better
type
safety,
let's
say
so,
then
we
have
like
function,
overflows,
overloads
and
stuff,
and
then
it
gives
you
much
like
detailed
or
I
don't
know
more
precise
type.
Safety
in
typescript.
A
A
So
idea
is
like
my
proposal
on
how
to
cooperate
on
it
so
since,
since
it
would
be
strange
to
like
make
it
through
saheed
fork
and
it's
unreliable
and
have
other
problems,
we
create
migrated.
A
Ts,
official
branch
on
graphql.js
and
sahit
would
be
able
to
and
me
to
review
your
prs
against
this
branch
and
we
can
match
it
like
for
like
next
week
and
hopefully
next
week,
we'll
put
it
in
the
mail.
So
there
is
like
two
approaches:
we
can
collaborate
now
by
like
making
official
branch
rocket,
jazz
and
pr
from
it,
or
we
can
oh
right
around
one
week
and
we
measured
and
you
cherry
pick
like
fixes.
A
C
I'm
always
available
so
yeah,
it
might
be
even
tomorrow
or
you
know
about.
I
noticed
that
there
is
a
check
for
dano
dino
and
for
dino.
We
need
complete
strictness
completion
like
like
to
be
to
make
it
compatible
with
type
script
streak
mode.
C
So
as
far
as
I
can
tell
right
now,
so,
basically
for
my
pr
there's
the
basically
the
the
the
the
migrate
to
ts,
it's
a
base
for
that,
so
the
the
number
of
errors
that
we
still
have
to
go
fully
strict
is
around
750,
but
I
kind
of
can
get
it
work
with
like
a
code
modification
tool
just
to
transform
all
the
like.
For
example,
we
have
a
lot
of.
I
don't
know
arguments
without
types
and
those
arguments
are
basically
types,
but
you
know
yeah.
A
C
Yeah
so
I
could
yeah,
I
could
just
write
a
tool
to
actually
transform.
Let's
say
I
don't
know
like
20
or
something
from
just
to
make
it
work
yeah.
One.
A
One
thing
I
try
to
keep
with
try
to
keep
it
like
separate
pairs
on
topic.
So,
for
example,
you
said
about
this
transformation,
so
important
thing
for
this
transformation
to
be
reviewable
is
issue
and
to
have
clean
git.
History
is
to
have
it
in
separate
commit.
So
when
you
make
like
fixes
on
transformation
like
that,
try
to
keep
it
separate
pairs,
separate
commits
and
will-
and
I
will
I
will
create
basically
branch
tomorrow.
I
will
create
a
branch
on
graphql.js
for
youtube
collaborators,
and
you
can
apply.
A
A
Here's
like
one
modification
in
separate
pr
but
through
whole
code
base
so
yeah
it
would
be
great
to
have
one
commit
that
fix
this
issue.
Yeah.
We
actually
are
aware
of
it
and
it's
a
problem
it's
like,
and
so
it's
not
a
new
thing.
It's
like
a
problem
flow
to
typescript
migration
is
that
yeah
four
things
types
are
names
because
in
typescript
it's
like
a
name
is
required.
You
cannot
just
specify
like
a
function
type
without
names,
but
when
we
check
it
was
like
dozens
of
places.
A
Camille
about
this
plan
that
create
a
branch
on
graphql.js
and
you
submit
different
so
separate
pr's
against
with
branch
and
does
it
make
sense
for
you
yeah
sure
I
mean.
C
Usually,
what
we
do
is
just
have
very
small
pr's.
So
then
you
know
there's
one
pr
for
let's
say
changing
something,
because
then,
instead
of
the
comments,
because
then
it's
like
you
know,
from
my
perspective,
harder
to
actually
rebase
and
do
all
that
stuff
and
if
it's
like
super
granule
request-
and
we
have
like
a-
I
don't
know
like
one
main
pull
request,
slash
branch
and
then
we
just
you
know,
do
pull
requests
to
that.
I
think
it's
you
know
it's.
It's
helpful.
C
Oh
and
one
question
not
question,
but
one
point
about
the
flow
types,
it's
kind
of
impossible
at
the
moment
to
use
just
flow
flow,
gen
or
whatever
tool
to
transform
from
typescript
to
flow
without
any
issues.
There
are
not
a
lot
of
them,
but
actually
you
know
even
from
the
perspective
of
maintaining
it.
If
you
have
something
that
you
know
automatically
generates
it,
it
might
output
a
different
like
it
might
give
a
different
output
every
time.
C
Let's
say
you
change
something
in
the
code,
so
I
thought
we
could
do
something
like
typescript
has
before
in
graphql
js,
which
is
like
separate.
You
know
separate
declaration
files
for
types.
So
this
is
what
I
did
so
we
just
copy
pasted
the
flow
files
from
the
you
know,
main
branch
and
just
removed
yeah,
just
just
left
the
types
of
the
code.
So
then
it's
the
same
as
it
was
and
yeah
and
then
you
know
like
there
will
be
a
time
where
people
will
probably
move
away
from
flow
or
like
make
it.
C
A
Probably
we
need
in
future.
We
need
to
be
more
to
write
more
points
once
more
detailing
and
explain
like
reasoning.
So
current
one
was
yeah
twofold.
First
first
mic
open
issue
to
get
the
feedback.
If
somebody
actually
needs
a
full
type
or
not
only
mark
like
responded
on
it
say
anyway,
yeah
we
kind
of
need
it,
but
we
want
to
migrate
for
four
from
four
anyway
to
typescript.
A
A
It's
kind
of
ok,
if
we
add
new
functionality
without
4
types
info,
typed
repo,
you
know
like
there
is
definitely
typed
and
there
is
a
four
type
three
type
three
four
four
four
is
similar
idea.
A
To
keep
it
there,
one
of
the
problem
that
we
discussed-
and
I
think
maybe
my
outline
in
his
in
his
issue-
is
that
we
switch
to
typescript
to
allow
to
facilitate
like
more
people,
to
maintain,
to
submit
employers
and
help
with
maintenance,
even
if
they
don't
have
a
knowledge
of
wall
or
time
to
like
learn
from
so
what's
primary
reason
why
we
switch
to
typescript
and
if
we
require
them
to
to
write
four
types
for
all
the
changes
or
to
like.
A
So
at
the
same
time,
I
don't
think
it's
reliable
model
when
we
will
have
one
person
to
maintain
four
types.
So
I
might
idea
was
like
sunset
for
four
types,
so
make
always
breaking
change
everything
codewise
in
alpha
one
or
maybe
alpha
2,
and
if
somebody
need
the
typings,
they
can
switch
to
1600
alpha
1
and
generate
them.
A
Hi,
so
it's
to
explain
situations
with
four
types:
yeah.
C
C
I
did
open
source
and
stuff
and
it's
quite
unusual
to
get
feedback
from
people
that
actually
not
that
matters,
but
that,
like
a
good
feedback,
let's
say
just
you
know
from
for
example,
for
the
flow
types
we
can
get
it
from
yelp
right
from
the
the
guy
that
actually
responded
from
the
typescript
we
can
has
to
give
pretty
much
provide,
even
with
the
cogen
and
the
things
we
use
in
cogen
and
like
are
much,
you
know,
there's
a
lot
of
complexity,
so
we
can
just
check
if
the
types
are
actually
working.
C
So
I
don't
know
if
I
mean
I
understand
that,
there's
a
reason,
or
I
kind
of
accept
the
fact
that
you
know
we
want
to
go,
get
this
step
by
step,
but
at
the
end
of
the
day,
if
we
let's
say
release
alpha
one
and
there's
a
I
don't
know
a
week
before
between
one
release
and
another,
I
don't
think
anyone
will
actually
test
it.
For
example,
if
we
release
the.
C
Typescript
and
then
flow,
or
vice
versa.
You
know
at
the
end
of
the
day
they
will
test
the
latest
version.
So
then
you
know
you
can
have
those
two
steps
where
you
can.
Just
you
know
like
ask
people
to
just
go
one
version
before
and
check
if
it
works,
then
you
see
uh-huh.
So
you
know
there
was
a
change
in
between,
but
it's
already
on
master,
so
you
know
or
in
the
main
branch
or
even
you
know,.
A
Can
apply
fixes
so
idea
is
like
not
to
be
like
fanatic
about
it,
so
we
should
put
most
of
the
stuff.
We
know
about
into
alpha
stage
before
tax
creep
migration,
but
if
we
will
fix
some
like
small
things
or
a
couple
of
things
afterwards,
it's
like
not
a
big
deal.
A
One
thing
like,
as
you
said
you
generate
four
typings
from
a
master,
so
idea
is
to
do
all
code
changes
into
alpha
one,
so
people
can
do
the
same
and
we
can
try
different
approaches
if,
like
the
release,
1600
without
fall
types,
and
it
will
cause
big
problem
for
through
ecosystem,
we
don't.
We
just
don't
know
how
many
non-legacy
projects
use.
A
We
can
always
add
all
types
later,
so
we
can
try
to
release
without
it
and
if
it's
not
a
big
issue,
we
support
15x6
with
four
types
and
we
will
apply
a
security,
fixer
and
even
backboard
some
features,
if
the
if
it
makes
sense,
but
maybe
it
just
so
question
here-
is
not
like
writing
them.
A
question
here
is
maintaining
them
so
the
same
with
polyfills.
A
So
for
a
long
time
it
was
easy
to
write
polyfill,
but
it
was
hard
to
maintain
polyfills.
So
every
pr
that
somebody
opens
against
garakil.js,
I
need
to
expand
them.
Please
don't
use
object,
values,
please
use
our
polyfill
for
it,
which
is
strange,
so
it
it's
the
same
same
issue
here.
It's
not
a
question
on
writing
four
types.
It's
a
question
maintenance
for
us.
A
Another
big
issue
here
is
that
previously
our
four
types
was
in
better
shape
than
typescript
types
before,
because
I
enabled
I
think,
like
year
or
two
ago,
I
enabled
type
check
on
tests
which
helped
a
lot.
So
we
kind
of
have
test
suite
for
for
a
test
suit
for
typescript
types,
not
only
like
execution
here,
but
for
types,
because
it
will
run
tc
on
top
of
test
files,
but
for
four
types
we
in
section
after
after
mac
migration,
we
wouldn't
have
any
like
types
test
except
integration
tests
which
is
problematic.
A
How
can
you
maintain
like
correct
flow
types
without
having
tests
for
it
worked
for
typescript,
because
a
lot
of
people
use
typescript?
So
it
was
like
easy
and
fast
typescript
easier
in
a
sense
than
four
but
some
some
cool
stuff
for
her.
So
I'm
like
not
confident
that
we
can
maintain
low
quality,
oh
yeah,
so
it's
like
explanation
about
four
times.
C
I
think
the
there
was
the
person
in
the
flow
topic
in
the
flow
issue
and
he
responded
and
he's
from
yelp.
So
we
can
even
like
contact
him
and
I
think
he
will
be
very
keen
to
actually
help
us.
So
then,
whenever
there's
a
change
in
the
flow
he
can
just
you
know,
get
like
a
canary
release
and
just
or
even
like
a,
I
don't
know
a
tgz
file
or
whatever
and
just
just
run
it
I
mean
for
him.
C
It's
just
probably
changing
the
resolution
in
yarn
or
whatever
they
use
and
and
it
should
be
fine
and
we
should
get
a
feedback
in
let's
say
two
or
three
days.
I
guess
so
then,
and
I
think
you
will
be
very
keen
to
actually
do
this
collaboration
and
just
to
make
sure
that
we
don't
break
them
yeah
we're
not
breaking
them.
So
it's
like
yeah,
but
I'm
saying
you
said
that
let's
say
we
have
no
tests
in
flow.
So
we
cannot
be
sure
that
you
know
those
flows.
C
Definitions
are
in
fact
correct,
and
they
are
you
know
non-breaking,
let's
say
so,
then
this
is
my
response
to
that.
So,
just
to
get
this
magic
mic,
you
know
he
has
magic
in
the
name.
So
I
guess
he
you
know
he
can
help
us
and
yeah.
This
way
we
can.
We
could
potentially
make
sure
that
there
is
this
connect
correctness
between
releases.
A
In
it's
depends
on
how
much
coverage
so
I
I
expect
yield
call
code
base
like
ips
surface,
that
graphql
server
uses
and
tooling
uses
totally
different.
So
in
in
guild
projects
you
probably
use
visit
and
bunch
of
other
complicated
functions,
a
lot
of
projects
and
user
projects.
There
are
three
servers.
A
A
So
it's
like
a
question
of-
and
I
think
here
it's
like
a
procedure
homogeneous
faster
in
a
sense
and
more
for
experts,
so
I'm
like
I'm
more
for
the
naked
generated
types
from
16,
alpha
1
and
the
native
in
them
inside
with
so
I'm
generating
from
here
and
donating
them
into
protect
projects
to
for
for
community
to
to
maintain
them,
and
so
I
think,
like
is
a
good
transaction
period.
I
also
worried
that,
for
example,
he
said
they
want
to
migrate
to
yeah
soon.
A
So
it's
the
same
for
big
part
of
four
community.
By
doing
it
in
16x6,
we
don't
we
want
to
do
breaking
release
too
often,
so
we
will
start
with
small
types
for
some
time.
A
A
A
This
is
my
point,
but
the
cool
thing
that
we
can
always
add
four
types:
we
cannot
remove
them
after
six
and
zero
zero.
We
cannot
remove
them
because
it's
breaking
change,
but
we
can
always
add
them
based
on
community
feedback,
if,
like
community
feedback
would
be
like
fall,
typed,
not
working
and
it
causing
like
bunch
of
issues.
A
I
think,
like
four
community
already
used
most
of
the
project
already
useful
typed.
A
Yeah
any
any
other
question
on
the
release:
the
risk
one
or
or
like
four
types
or
many
other
topic.
A
A
I
think
it
would
be
pretty
easy
to
separate
the
changes
if
you
replace
your
pr
on
top
of
main
and
sahider
based
his
pair
on
top
of
mine,
you
can
basically
run
the
gif
and
one
thing
is
to,
as
you
said,
the
same
procedure
as
you
do
in
in
guild,
so
we
will
have
like
a
main
pr
into
mine
and
you
submit
like
small
pairs,
which
can
be
reviewed
like
and
maintains
the
same
style.
A
So
one
commit
per
change,
but
do
is
change
globally
if
it's
like,
if
it's
100
wind
of
code
or
something
it
don't
make
sense
to
break
it
into
multiply
commits.
But
if
it's
like
more
than
like
100
or
couples
hundreds
commit,
please
break
it
small
chunks
to
draw
easy
review
it
easily.
A
And
we
actually,
in
that
case
we
can
accept,
like
appears
from
other
people
and
maybe
figure
out
how
to
make
it
strict.
I
didn't
know
there
were
things
about
that.
I
didn't
know
that
dinner
is
not
accepting
attack
script
files
without
a
strict
check.
A
One
thing
I
wanted
to
ask
before
we
end,
I
forget
to
add
with
in
agenda
in
agenda,
but
how
do
you
feel
about
dropping
note,
10
support,
because
in
three
months
I
think,
like
three
months
or
four
months,
not
then
became
deprecate
and
like
there
is
some
with
support
for
not
then
make
it
harder
for
us
to
to
support
esm
esm,
I
think
like
after
not
10,
not
12,
basically
allow
you
to
just
provide
dsm
without
cgs,
so
it
like
makes
make
this
task
way
way
simpler.
If
you
just
drop
not
not.
A
A
I
think
let's
target
for
next,
like
minimum
expected
result
for
next
until
next
fall,
is
to
finish
like
this
item.
Until
you
finish
until.
A
Hopefully,
we'll
also
have
some
experiment
with
the
summon
dino,
but
basically
until
like
february
plan
is
to
finish,
everything
else
is
to
much.
The
heat
bear
much
like
camille
improvement
on
the
heat
power
and
everything
in
typescript,
maybe
without
like
a
strict
check
but
like
have
it
as
a
base
goal,
and
your
next
working
group.
A
So
if
it
was
pleasure
to
speak
with
you,
hopefully
we
will
all
collaborate
and
make
this
telescope
migration
happen
before
next
working
group
call.
So
thanks
for
collaboration-
and
you
can
always
be
in
being
smart
by
the
way
to
discuss
stuff.
I'm
a
little
bit
my
inbox.
It
happened
box
overflow,
so
I
can
like
miss
some
issues
or
appears,
but
if
you
want
to
discuss
something,
just
pin
me
in
graphql
and
basically
bye.