►
From YouTube: Node.js Foundation Modules Team Meeting 2020-03-11
Description
A
A
B
Sure
so
for
background,
we
added
conditional
exports
to
our
building
loader
to
the
default
resolution
function,
but
we
never
exposed
it
to
the
custom
resolution
functions
that
users
might
provide
using
the
dash
loader,
and
so
this
PR
both
makes
this
information
available
to
custom
resolution
functions
and
also
allows
them
to
change
what
conditions
are
recognized
by
the
default
resolution
function.
So
if
they
want
to,
for
example,
have
support
for
the
browser
condition
they
can
inject.
That
condition
and
Note
will
recognize
it
when
it
does.
The
conditional
exports
evaluation.
B
Cream
status
is
that
it
is
implementation
complete
and
it
seems
to
work.
The
only
concern
was
from
joffrey
side
that
the
way
it
is
exposed,
and/or
explained
I
might
be
confusing
to
users.
So
I
think
we
are
looking
to
get
an
idea
from
the
working
group
or
the
feeling
in
the
room
is
whether
the
current
interface
and
how
it
is
documented
is
sufficient
or
if
it
needs
further
iteration
to
make
it
clearer.
A
C
I
was
just
asked,
I
posted
on
the
thread
for
this
meeting.
If
the
folks
on
this
and
the
models
group
can
just
look
at
the
link,
I
posted
there,
which
is
like
the
ESM
Doc's
in
the
PR,
and
if
it
makes
sense
to
all
you
guys,
then
you
know
I
I'm
not
gonna
hold
this
up,
because
I
think
the
UX
is
wrong
if
I'm
the
outlier
on
this.
But
what?
If
anyone
else
is
confused
or
think
we
should
do
this
differently,
then
we
should
keep
talking
about
it
and
discuss
alternatives.
C
A
C
C
My
thought
was
that
the
general
approach
that
this
PR
takes
is
that,
like
which
so
contact
stock
conditions
coming
into
the
hook
is
like
what
conditions
apply
to
this
resolution
and
young?
You
can.
You
know
please,
but
in
if
I'm
screwing
this
up
so
like
in
general,
it's
always
going
to
be
note
and
import
like
those
are.
The
conditions
that
would
you
know
evaluate
is
true
for
an
import
call
and
if
you
wanted
to
then
pass
this
along
to
default,
resolve
if
you
were
to
modify
those
like
add
another
condition
like
custom
condition.
C
My
thought
was
that,
like
node,
you
just
ignore
that,
because
it
doesn't
know
what
to
do
with
custom
condition.
It's
on
you
as
the
developer
to
write
a
hook
to
add
the
logic
for
what
node
should
do
for
this
on
known
condition,
but
this
P
are
basically
like
tells
no
to
just
treat,
as
you
know,
the
equivalent
of
node.
C
The
alternative
that
I
suggested
was
to
stay
closer
to
the
flow
of
what
resolution.
How
resolution
is
happening
and
be
like
you
know?
Well
at
some
point
in
the
process?
Node
is
looking
up
a
package
at
Jason
to
find
the
exports
field
and
then
does
something
with
the
data
and
exports.
Though
you
know,
we
could
just
override
that
piece
and
currently
that's
all
inside
resolves.
You
could
just
override
it
with
a
long
result
function.
If
people
want
to
splits
that
part
of
result
out
and
do
its
own
hook,
we
could.
C
C
C
I
can
find
the
link
and
I'll
put
it
in
the
chat
here.
I
mean
it's
a
it's
just
a
link
to
the
docs
for
this
PR.
It's
literally
like
one
paragraph.
So
you
know
please
click
this
link
and
read
it,
and
if
it's
fine
with
you,
then
just
make
a
comment,
and
then
you
know:
if
no
one
has
any
objections
and
we
can
just
land
this
and
move
on.
A
B
Great,
can
we
make
an
explicit
call
here,
though,
because
so
the
reason
report
after
that
is
agenda
is
because
we
were
at
an
impasse
where
we
just
disagreed
on
whether
this
is
acceptable,
API
or
nox,
and
one
of
the
goals
of
bringing
it
up
here
was
that
we
wanted
to
see
if
the,
if
there's
any
deciding
voices.
That
think
then
also
agree
that
the
current
API
is
confusing
kind
of
based
on
the
description
alone.
B
C
D
C
And
it's
more
that
the
should
what
should
happen.
If
say
it
does
have
one
of
the
other
of
those
on
it.
It
doesn't
really
matter
which
one,
if
you
were
to
modify
that
and
then
pass
it
into
default,
resolve
what
should
happen.
You
know
like
should,
like
my
my
instinct
as
a
user
would
be
I,
would
expect
whatever
you
pass
as
conditions
into
vault
resolved
to
behave
the
same
way
as
if
that's
what
node
had
read
from
disk
in
the
package
of
Jason.
C
B
Quickly
jump
in
here
and
to
kind
of
answer,
one
thing
address
just
said
directly
in
this
via
are
what
the
result
part
gets.
It
has
nothing
to
do
with
a
package
of
JSON
file.
It's
not
read
from
the
technical
jason
file.
It
is
not
associated
with
anything
from
the
texture
adjacent
file.
It
is
purely
the
conditions
that
will
be
used
to
evaluate
conditional
exports
for
this
import.
E
E
E
Well,
sorry,
but
what
I
mean
is
that
I,
as
the
loader
will
get
triggered
for
for
a
single
arbitrary
specifier
and
will
be
passed
some
conditions?
And
then
my
choice
is
to
continue
to
pass
those
down
or
to
alter
them.
But
how
do
I
like
if
I'm
a
loader,
that's
just
trying
to
be
like
oh
I'm,
for
the
browser
or
something
like
I
mean
I
can
see
that
that
would
be
the
simple
case.
B
One
canonical
example
would
be
it's
a
loader
that
wants
to
enable
the
production
condition
based
on
process
and
no
ten.
If
you
want
to
enable
that
condition
for
matching,
you
would
add
it
to
the
array
and
then
the
default
resolution
function
would
find.
The
experts
object
to
all
the
paths
walking
and
then
use
that
condition
when
it
is
walking
through
the
exports
conditions
and
say
hey
instead
of
just
matching
the
ones
that
ship
by
not
with
nobody,
called
and
also
matching
this.
Your
new
condition
that
you
bury.
B
E
So
I
mean
what,
if
I
want
to
determine
if
I
need
to
transpile
a
file
or
not
based
on.
If
there's
you
know
just
like
some
syntax
is
safe
districts
transpile
some
is
not
so
what,
if
I
want
to
like
make
a
decision
about
that
or
like,
but
I
need
the
contents
of
the
file
in
order
to
to
make
that
decision.
Is
that
possible,
with
the
current
with
your
proposed
API.
B
C
E
B
But
if
you
wanted
to
you
could
in
theory,
call
default
resolve
with
two
different
condition:
sets
that
one
includes
browser,
the
other
one
doesn't
or
whatever
the
sets
are.
You
can
then
load
the
resource
from
that
resolved.
Url
do
whatever
tests
you
want
and
then
return
one
other
one
or
the
other
based
on
the
contents.
So
it
will
be
possible
with
this
implementation.
Okay,.
E
So
essentially,
the
answer
the
generic
answer
to
my
question,
because
I'm
sort
of
coming
up
to
contrive
to
use
cases
here,
but
the
generic
answer
is
that
I
would
use
default
resolve
with
like
a
single
condition.
Let's
say
if
I
wanted
to
see
what
that
was:
yeah,
okay
and
then
Geoffrey
with
your
suggestion.
How
does
is
that
different
at
all,
so.
C
With
my
version
that
I
proposed,
where,
if
it's
like,
rather
than
passing
into
conditions
in
use
it
pack
it
passes
in
play,
essentially
what
would
the
package
at
Jason
have
been
loaded
for
this
path?
So
it
doesn't
bother
at
least
yet,
but
I
was
only
thinking
about
specifiers
that
start
with
the
package
names
to
like.
C
You
know,
package
/foo
right,
so
you
essentially
do
like
require
that
resolve
package
to
and
then
figure
out
that
path
get
the
package
with
Jason
at
that
path,
parse
it
and
then
that's
sent
in
to
the
context
as
context
not
package
metadata.
That's
what
I
was
calling
it
then
you
I
mean
the
resolved
hook
is
not
meant
to
like
the
design.
All
the
hooks
are
generally
meant.
The
the
general
pattern
is
like
either
do
something
different
and
return
that
or,
like
you
know
else.
C
Let
know
do
its
thing
by
default
like
this
idea
of
like
modifying
stuff
and
then
passing
it
to
no
to
the
default
version
is
like
not
really
a
it's.
It's
not
a
pattern
that
any
of
the
examples
have
followed.
It's
not
a
pattern
that
we
like
had
in
mind
when
we
designed
these
so
that
that's
another
difficult
thing
for
me.
I
I
I
want
to
object
at
that.
B
Point
because
I
don't
think
that's
correct
all
hooks
support
passing
different
arguments
to
the
defaults.
If
you
want
to
let
go
example,
if
your
get
sauce
hook
wants
to
get
the
sauce
from
a
different
file
name
by
modifying
it,
it
could,
if
your
result
hook,
wants
to
modify
the
specifier
or
the
context
URL
it
can
and
node
will
totally
honor
those
new
values
right.
C
So,
anyway,
that
the
the
other
version,
the
other
approach,
this
would
be
you
get
the
pole,
packers
of
jason.
Then
then
you
either
take
one
one
approach
to
the
other.
You,
the
one
approach
would
be
you
parse
it
yourself
and
parse
the
exports
thing
and
find
the
custom
condition
you're
looking
for
and
find
and
get
the
path
for
it
and
assemble
it
and
find
that
file
and
return.
The
URL
of
that
file.
You
know,
like
you're,
doing
the
whole
work
of
resolution
within
your
hook.
C
B
Would
disagree
because
what
you
described
so
far
does
not
allow
access
to
the
actual
conditions
that
node
would
apply,
especially
for
future
versions
of
note
that
might
not
be
hard-coded
to
exactly
note
an
import.
So
your
hook
even
getting
the
whole
package
space
and
would
not
know
which
conditions
I
acted,
but.
C
That's
just
a
separate:
can
that's
just
a
separate
concern
like
if
we
want
to
provide
you
know
some
lists
of
like
what
are
the
currently
supported
conditions
like
we?
Can
you
know
that
doesn't
need
that's,
not
contextual
information.
That's
like
more
information
about
each
node
version,
not
like
about
every
specifier
that
gets
resolved
in.
B
The
case
of
input
and
require
nice
conditions,
it
is
about
the
current
resolution.
It's
not
global
to
note,
and
also
it
might
in
the
the
conditions
I
explicitly
currently
attached
to
a
specific
resolution,
conceptually
so
I.
Don't
think
that
we
would
want
to
have
a
design
that
locks
us
into
conditions
that
always
need
to
be
globally
active.
C
B
B
The
default
was
over
twice
because
you
need
to
resolve
the
package
twice
or
it
just
doesn't
doesn't
work
because
you
don't
know
where
the
package
Jason
is
when
you
call
the
custom
loader
hook,
because
the
question
notice
with
loader
hope
is
responsible
for
calling
the
default
resolver,
which
will
actually
find
the
package
traced
in
the
first
place.
Yes,.
C
C
But
you
know,
that's
I,
think
that's
a
low
I
mean
that's
just
a
performance
hit
I
suggested
we
could
make
this
make
the
package
metadata
property
a
getter
so
that
it
never
actually
gets
looked
up
and
unless
the
user
uses
it,
but
yeah
I
feel
like
most
of
the
time.
If
the
if
a
specifier
is
like
package,
/foo
you're
gonna
want
the
package
Jason
you're
like
a
lot
of
the
things
you
would
do
with
such
a
specifier,
involve
reading
the
package
metadata.
So
it
seemed
like
a
pretty
safe
shortcut
to
give
users.
B
Right,
but
now
you
describe
something
that
is
completely
orthogonal
to
this
PR,
because
in
this
PR
it's
about
providing
the
conditions
which,
as
we
established
now,
you
made
any
how
even
if
you
would
get
the
whole
thing
straightened.
So
it's
just
this
different
API
that
has
a
different
this
case.
Well,.
F
B
Not
really
because
the
resolver
might
also
like
the
customers
over
the
only
things
that
back
it
only
subsumes
the
use
cases.
If
you
assume
that
every
single
resolution
will
do
the
export
conditionals
using
the
default
resolve
hook,
that
is
built
into
node.
But,
for
example,
if
you
would
ride
a
hook
that
does
resolution
itself
completely
without
calling
default
resolve.
B
Making
the
package.json
metadata
mutable
doesn't
help
you,
because
if
you
are
rendering
our
import
Maps
ahead
of
time
and
your
loader
hook
just
uses
the
conditions
to
find
out
which
important
map
to
use
and
then
that's
all
the
resolution
using
the
input
map,
you've,
never
call
him.
Your
fault
resolve
getting
the
package
Jason.
It's
just
bad
information,
because
your
packages
might
not
actually
be
in
Northmoor
use
at
all.
So
you're
just.
C
B
C
B
It's
not
theoretical
if
you
want
to
be
able
to
implement
the
same
resolution,
algorithm
that
the
default
result
represents
at
all,
which
is
not
very
theoretical,
like
we
know
of
people
that
want
to
re-implement
the
grow
them
with
slight
modifications.
If
you
want
to
match
the
built
in
behavior,
you
need
that
information,
so
not
theoretical.
It's
just
that
is.
The
capabilities
of
the
report
was
all
work
exposed
to
the
customers
or
hook.
A
A
Think
it
seems
like
the
folks
who
care
the
most
have
been
chiming
in,
but
you
know
those
who
had
some
points
to
bring
up
today.
Please
please
do
so
and
then
I
guess
Yan
from
the
issue.
Are
you
currently
blocked,
or
are
you
like
just
trying
to
make
sure
that
you
don't
that,
like
everyone's
input
is
taken.
C
I
was
just
asking
him
to
add
the
doc,
so
I
guess
I
can
I
can
remove
that
for
now,
but
I
just
wanted
to
see.
If
any
way
you
see
if
the
the
Doc's
actually
made
sense
to
other
people,
and
if
they
do
then
that's
fine,
we
can
land
it,
but
there's
all
I
was
walking
for
was
to
add
some
documentation
about
what
this
conditions
Amish
boys
yeah.
C
Cool
I
mean
we
can
have
both
api's,
where
we
have
both
properties
passed
in,
but
I
don't
know
that
this
idea
of,
like
essentially
passing
in
configuration
data.
What
feels
to
me
like
configuration
data
rather
than
just
input
data
to
default,
resolves
strikes
me
as
a
bad
pattern,
but
if
I'm
the
only
one
who
feels
that
way,
then
it's
fine
I'll
be.
A
Okay,
moving
on
to
the
next
issue,
work-in-progress
ESM
loaders
moved
to
worker
thread.
This
is
a
work
in
progress.
Pr
Brad
we
talked
about
it
last
meeting.
It
does
not
seem
like
there
has
really
been
movement
on
it.
Since
does
anyone
object
to
removing
the
modules
agenda
from
this?
For
now,
until
you
know,
any
movements
happened.
B
A
I'm,
just
gonna
drop
that
in
the
chest,
so
people
can
see
it
ad
hook
for
global
preload
code.
It's
from
eight
days
ago
looks
like
Gus
who's,
unfortunately,
not
on
the
call
right
now
had
some
opinions
and
you
two
have
been
going
back
and
forth.
Brad
jumped
in
there
I
see
guys
commented
also.
Is
there
any
thing
particular
other
than
an
FYI
that's
important
to
bring
up
about
that
one
you're
on
no.
A
C
A
A
A
B
A
A
Brad
communicated
that
there
likely
isn't
a
clear
path
to
supporting
module,
DUP
parents
API
contracts,
so
he
doesn't
personally
think
we
have
too
much
to
talk
about
except
what
was
in
the
thread
currently,
which
is
kind
of
documented
there.
Someone
suggested
maybe
deprecating
module
dot
parent
in
common
Jas.
E
Mean
the
looking
at
that
module
parent
thread,
it
seems
like
they're
looking
for
the
like
is
they're
trying
to
figure
out
if
it's
like
a
command
line
thing
or
not.
The
module
dot.
Parent,
specifically
to
me
I,
feel,
like
that's
a
very
just
a
huge,
miss
feature
because
of
the
module
cache
it's.
It
should
be
largely
meaningless.
What
the
parent
like,
what
who
required
the
module
or
who
imported
it?
Who.
F
E
Imported
it
yeah
fair
yeah,
like
that's
a
route
that
shouldn't
be
useful
and
the
only
module
I've
seen
that
actually
uses
it
deletes
itself
out
of
the
require
cache
after
it
extracts
the
value
so
that
it
gets
great
career
required
every
time
which
is
just
gross
so
like
I'm,
supportive
of
some
sort
of
import
net
away
to
like
determine
if
you're
the
entry
point
or
not,
maybe,
but
like
the
ability
to
find
out
who
first
imported
you
at
that.
I
would
be
very
happy
to
see
that
deprecated
for
commonjs.
A
There
was
discussions
with
the
web
assembly
group
about
knowing
whether
or
not
you're
like
the
entry
point,
and
there
were
a
couple
different
discussions
around
how
that
could
look,
including
I,
think
Yan
suggestion
of
a
particular
named
export
always
being
like
being
executed
automatically
on
the
main.
There's
a
need
for
something
like
this
for
web
assembly
modules,
so
they
are
kind
of
interconnected
here.
But
it
sounds
like
to
me
Brad's
supporting
here
a
Brad's
comment
here.
So
I
do
95
is
pretty
much
in
line
with
how
folks
are
feeling.
Would
you
say
that
that's
reasonable.
A
A
Not
not
all
these
pull
requests
are
necessarily
ready
to
land
yet,
but
I
do
think
that
this
is
a
signal,
at
least
to
me,
especially
if
you
look
at
some
of
these
issues
and
the
issues
people
are
running
into
that
I
don't
feel,
like
modules,
are
entirely
ready
to
remove
the
warning.
Yet
people,
please
feel
free
to
disagree
with
me
and
bring
it
up.
I
know
we
talked
about
discussant.
A
So
if
we
look
at
the
issues
here,
no
stack
trace
with
missing
async
keyword
and
dynamic
imports
has
nothing
to
do
with
it
missing,
inter
that
module
does
not
provide
an
export,
has
nothing
to
do
with
it.
Patrik
past
package
exports,
false
not
working,
doesn't
have
to
do
with.
Loaders
cannot
find
module
when
main
is
not
index
with
experimental
resolution.
Node
is
not
package.
Exports
required
dot,
slash
in
front
of
path
or
resolved
for
module.
Pre-Loading
suggestions,
yes,
modules,
loading
with
absolute
path,
tails
and
windows,
self-referential
modules,
not
supported
by
Red
Bull,
yes,
M
doesn't.
E
E
C
F
F
A
So
I
understand
the
assessment
or
the
characterization
that
guy
is
coming
from
and
saying
these
aren't
necessarily
bugs.
Some
of
them
may
be
ways
in
which
we
can
improve
errors.
A
handful
of
them
are
like
ways
in
which,
like
when
we
import
even
commonjs,
it
still
goes
through
kind
of
the
es
loader
before
we
have
a
chance
to
hook
it
I
all
I'm
trying
to
point
out
is
like
there.
A
There
are
usability
issues
here
that
make
it
confusing
and
make
it
confusing
for
people
to
use
and
I
am
personally
not
confident
that
we
could
remove
the
label
in
a
period
of
like
a
month.
I'm
not
saying
we
can't
remove
it.
Eventually,
it
couldn't
be
in
six
months,
I'm
just
saying
I,
don't
feel
like
we're
in
a
position
where
the
label
could
be
removed
prior
to
14
X
being
cut,
for
example,
and
if
people
disagree
with
me,
I
think
would
be
a
good
time
to
bring
that
up.
Well,.
D
A
Can
even
remove
the
warning
after
14
has
gone
into
LTS.
There's
no,
like
I
think
when
we
talked
about
this
two
weeks
ago.
The
time
frame
that
we
discussed
may
be
basing
this
on
was
when
tens
end-of-life
as
long
as
we're
able
to
keep
12
up
to
date,
then
like
and
end-of-life,
is
next
next
April,
so
we've
got
about
a
year
and
change
so
I
think
by
I
would
like
us
to
see
it.
A
Have
the
thing
completely
stabilized,
so
not
just
no
warning
but
also
marked
as
stable
in
the
docs,
at
least
4:14
by
that
point,
but
you
know
I
think
we
can
work
backwards
from
that
time,
which
was
something
we
were
talking
about.
Writing
writing
an
issue
for,
but
I
know
that
you
know.
Guy
has
a
blow
request.
That's
open
right
now,
I,
don't
believe
it's
landed
to
remove
experimental
modules,
warning
and
I.
Don't
think
we're
quite
ready
for
that.
Yet
personally,.
G
G
G
Like
I
think
in
terms
of
the
signal
that
it
sends
to
users
I
think
it's
a
terrible
signal
to
send
as
a
project,
because
it's
basically
saying
take
another
year
before
we
actually
encourage
people
to
use
modules
so
I
think
pushing
users
into
other
ecosystems
and
I'm.
Not
gonna,
argue
against
that.
But
I
think
for
a
project.
I
think
that's
incredibly
dangerous
to
go
down
and
detrimental
actually.
H
Yes,
I
just
wanted
to
say:
I'm,
not
really
sure
what
we
expect
to
change
that
would
actually
break
user
code
like
as
in
standard
user
code,
not
loaders
and
such
I.
Don't
really
have
a
strong
opinion
about
fourteen-point,
oh,
but
I
think
it
would
be
pretty
unfortunate
if
the
warning
we're
still
there
for
the
LTS
release,
just
because
if
the
first
LTS
doesn't
silently
support,
yes,
M,
then
that's
a
whole
nother
LTS
cycle
that
would
have
to
go
end-of-life
before
you
know.
Maintainer
z'
would
be
willing
to
go
fully.
Sm
anyways
that
just
might
okay.
G
A
A
Think,
to
an
extent
I
mean
for
what
it's
worth.
If
everyone
in
here
thinks
that
we
should
remove
the
warning
and
I'm
the
lone
objector,
I
won't
block,
we
can
remove
the
warning.
I
just
think.
It's
premature
I
think
there's
a
signal
that
we
should
give
people
that
things
are
still
rough
around
the
edges.
I
think
removing
that
warning
is
a
strong
signal.
I
think
that
Cory
has
made
our
an
extremely
strong
argument,
though,
that
if
the
warning
is
still
there
at
the
beginning
of
14
LTS
that
maintained
errs
may
be
uncomfortable
with
supporting
it.
A
Even
if
that
warning
is
removed
later,
we
can
still
keep
it
as
experimental
in
the
documentation
like
removing
the
warning
is
kind
of
a
step
towards
stability,
but
doesn't
mean
that
it
has
to
necessarily
be
stable,
so
I
think
that
that's
definitely
something
that
we
can
work
towards.
I
would
love
to
see
us
lower
this
issue,
q,
even
the
ones
that
are
more,
a
need
for
documentation
or
a
need
for
improving
warnings.
Those
are
like
to
me
just
as
important
as
bugs
when
we're
talking
about
saying
that
something's,
production-ready
and
I.
Think
to
me.
A
C
Like
I
feel
like
we
almost
want
to
like
triage
these
issues
and
be
like
well
how
many
of
these
actually
are
bugs,
and
also
how
serious
are
they
like
is
this
is
for
each
one,
whether
it's
a
documentation,
failing
or
a
missing
feature
or
even
for
a
feature
request?
Is
it
important
enough
that,
like
oh
well,
because
node
doesn't
have
this
or
because
no,
it
has
this
bug
I
shouldn't
be
using
USM
in
production?
That's
that's
kind
of
like
a
yes
or
no
question
that
we
should
ask
of
each
open
issue.
I
mean.
A
C
Pull
requests
and
like
if
we
get
if
the
answer
is
no
for
all
of
them,
that
like
no
it's
not
a
concern,
then
yeah,
then
we
probably
should
remove
the
warning
like
yes,
this
will
continue
improve
over
time,
but
you
know
if
we
think
it
could
be
used
in
production,
as
is
even
even
though
we'll
improve
later
then
I
think
that's
when
we
remove
the
warning.
Is
that
I
think.
A
A
And
I,
and
with
that
I
would
say
our
ability,
as
a
team,
to
triage,
manage
and
update
the
things
in
the
repo
is
another
thing:
that
is
a
gate
for
this
being
production
ready
just
because
it
would
work
in
production
doesn't
mean
that
getting
it
to
production
is
going
to
be
a
good
task.
Yawn.
You
have
your
hand
up,
yeah,
I,.
B
The
problem
is
that
that
that
incentivizes
us
to
classify
things
that
are
on
the
edge
or
they're
confusing
or
that
are
misleading,
or
that
might
waste
people's
time
as
something
that
well
I
mean
if
they
would
have
guessed
the
correct
solution,
they
would
have
succeeded,
but
that's
not
a
good
bar
I
think
for
going
out
of
experimental,
because
we
are
fighting
an
uphill
battle
against
existing
patterns
in
the
ecosystem
and
against
existing
messaging
that
happens
and
in
the
past
about
modules
and
how
to
use
them.
So
I.
G
I
I
think
that's
an
excellent
point
and
I
completely
agree
with
that.
So
thank
you
yarn
for
staining
it.
Sir
Kelly
I,
like
its
certainly
I
agree.
It's
it's
a
big
signal
and
as
a
big
signal,
it
should
be
incredibly
coordinated
and
there
should
be
a
real
effort
to
make
sure
that
it's
carefully
communicated
and
if
we
as
a
group,
do
not
have
that
level
of
coordination
and
communication
together
then
yeah.
It
should
just
delay
as
long
as
it
takes
for
us
to
reach
such
a
point
like
the
the
Ducks
PRS
that
are
going
through.
G
Our
huge
steps
towards
this
stuff,
seeing
Anna's
refactoring
today
was
was
great
to
see
because
it's
showing
that
we
can
kind
of
make
the
resolve
a
code
more
accessible
to
to
improvements
from
from
jeaious
contributors,
and
so
yes,
that
there
are
a
lot
of
steps
that
are
happening
in
in
directions
that
that
we'll
be
able
to
get
us
to
a
point
of
stability.
But
I
think
it's
important
to
realize
that
there's
no
technical
blocker
here
from
an
from
a
bug
and
feature
perspective,
I
think
we
have
stability.
G
You
know,
of
course,
there's
always
bugs
in
software
and
in
terms
of
stability.
It's
an
incredibly
stable
piece
of
software
at
this
point-
and
you
know,
as
far
as
software
goes
I
mean
it's
it's
it's
been
worked
on
for
many
years
and
it's
you
know
been
attacked
from
every
angle,
but
in
terms
of
getting
together
the
communication
and
the
documentation
and
the
working
out
where
the
captures
are
and
making
sure
that
everything
is
definitely
handle.
G
H
A
Thank
you,
Cory
I,
think
the
last
bit
and
then
and
then
just
a
thought
here
and
then
maybe
we
can
follow
up
on
this
more
next
time.
I
think
about
this.
From,
like
a
product
perspective,
we
ship
products
at
Google.
We
have
a
number
of
different
sign
offs
and
some
of
those
sign
offs
include
Deverell
and
documentation
and
for
things
to
get
to
beta
and
for
things
to
get
general
availability.
A
They
can
require
sign-off
that
the
documentation
and
the
developer
experience
is
that
a
high
bar
and
as
high
of
a
bar
as
the
engineering
and
so
guy
I
absolutely
agree
with
you
that
this
is
extremely
well
engineered
and
reliable
from
an
engineering
capacity.
I
think
that
there
is
still
just
a
little
bit
of
work,
not
a
ton
of
work
to
be
done
from
the
developer,
experience
standpoint
and
the
documentation
standpoint
I
think
we're
really
close.
A
What
may
be
helpful
here
and
less
frustrating
and
I
will
try
to
find
time
to
get
something
down
and
I
will
concede
that
if
I
cannot
find
time
to
do
this,
we
should
maybe
just
move
forward.
But
I
will
try
to
find
a
way
of
having
a
better
bar
of
making
it
clear
what
at
least
my
expectations
would
be
for
me
to
sign
off
on
it.
So
it's
not
just
arbitrary
or
kind
of
feel
like
a
moving
goalpost,
because
that's
not
really
fair
to
you
or
anyone.