►
From YouTube: Node.js Loaders team
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
It's
it's!
I'm
I'm
looking
at
a
loading
indicator.
B
B
C
Stand,
I
think,
we're
sitting
pretty
good
on
the
design
documents.
They've
been
updated
with
all
the
various
things,
except
for
an
example
that
involves
short
circuiting,
which
I
will
probably
add
after
tonight's
meeting
just
because
I
haven't
had
time
to
do
that
yet
and
then
also
watching
bugs
for
esm
related
things.
Since
last
week's
release
I
saw
one
came
in
so
fortunately
that's
that's
about
it.
B
The
design
yeah
I
went
through,
I
went
through
them
again
last
night.
I
wonder
if
we
should
just
merge
in
like
what
we
have
or
maybe
you
know
we
should
respond
to
the
latest
like
set
of
notes
and
then
just
merge
in
like
what
we
have
and
then
we
can
keep.
You
know,
keep
iterating
on
it
in
pr's
or
something
because,
like
I,
don't
I've,
there's
no,
nothing
objectionable
about
any
of
these
documents.
I
think
at
this
point.
C
Okay,
cool,
I
think
that
sounds
good
and
then
I
can
add
the
short
circuiting
example,
probably
to
both
of
them,
so
I
could
get
in
what
is
currently
there
do
I
need
to
share
my
screen
still
or
we're
just
going
to
say
like
cool
yes,
why
don't
you
share
your
screen
because
then
it'll
be
part
of
the
reporting?
C
Okay,
so
the
one
on
actually,
I
should
switch
these.
C
The
one
on
the
left
is
with
the
original
proposal
that
has
the
sort
of
like
recursive
like
implementation,
and
then
the
one
on
the
right
is
the
iterative
chaining
one
that
behaves
more
like
a
promise
chain
or
a
a
for
loop,
or
something
like
that.
So
the
one
on
the
left
just
has
the
specific
document
related
to
the
recursive
design
and
the
one
on
the
right
has
the
one
related
to
the
iterative
design,
which
is.
C
So
the
one
on
the
left,
I
think,
does
not
have
too
much
that
really
changed.
It
looks
like
a
lot,
but
it's
mostly
coordinating
names.
C
Yeah,
so
the
main
takeaway
is
that
we've
added
a
short
circuit
optional
flag
in
the
return
which
will
potentially
signal
to
the
the
loader
like
stop.
B
Oh
never
did
we
mention
in
this
document
that
the
the
lack
of
short
circuit
that,
like,
if
like
say
you
have
you,
know
three
user
resolve
hooks
and
then
and
then
the
node
default
resolve
folks.
So
four
potential
resolve
hooks.
If,
for
a
particular
specifier,
not
all
four
is
not
all
four
called,
but
then
you
like
don't
do
short
circuit.
C
I
don't
know
if
I
incorporated
that
into
it,
but
no
that's.
That
is
definitely
a
thing
that
we
should
do
if
it's
very.
D
A
D
C
How
it
would
behave
in
the
other
one?
True,
yes,
yeah
yeah,
I
guess
we
should
change
to
say,
like
we'll,
allow
the
chain
to
shoot
circuit.
B
I
or
just
say
that
like,
but
you
know
because
any
hook
I
mean
allows.
B
Each
hook
is
for
because
each
hook,
if,
if,
if
any
hook,
fails
to
call
the
next
hook,
that
would
implicitly
short-circuit
the
chain,
because
this
is
because
this
is
often
a
user
error.
Node
will
throw
when
this
occurs.
Unless
short
circuit,
true
is
passed
to
tell
node
that
you
are
intentionally
short
intentionally
breaking
and
not
allowing
the
remaining
hooks
of
the
chain
to
be
called
something
along
that
along
those
lines.
I
think.
D
B
D
C
So
I
think
I
do
have
the
general
design
for
the
example
for
short
circuiting
ready
to
go.
So
I
think
I
can
oh.
B
If
you
want
to
add
that,
to
I
mean
we
could
add
all
that
before
merging
and
if
you
want
there's
no
like
hurry
in
virginia-
and
I
was
just
thinking-
there's
no
reason
to
keep
these
like
as
pr's
sitting
open
forever.
So
whenever
you
think
this
current,
like
revision
pass,
is
done,
let's
just
merge
them
in
and
then
we
can
like
open
new
pr's
as
needed.
C
Do
that
yeah?
I
think
that's
about
it
then
solicit
feedback
and
see
how
it
goes.
B
I
think
what
are
the
loader
chains
and
then
and
then
go
a
little
bit
further
down
to
the
first
example
like
I
think,
the
either
the
babble
or
coffee
script,
one
or
maybe
it's
the
https
one.
B
It
should
not
open
them
up,
yeah
that
so,
if
interim
result.source
and
then,
if
resolved
earl
starts
with
so
basically
it's
it's
like
every
loader
that
you
write
like,
so
they
each
have
pros
and
cons
like
like
the
the
the
one
on
the
left
like
yeah,
you
gotta
remember
to
not
short
circuit
right,
like
you're
gonna,
you
could,
you
could
easily
forget
and
accidentally
short
circuit
and
yeah,
we're
gonna
add
some
kind
of
catch
for
that,
but
there's
always
that
that's
the
risk
inherent
in
that
design
the
in
this
one.
B
You
have
to
be
explicit
about
on
the
one
on
the
right
you
have
to
be
explicit
about,
like
you
almost
have
two
two
inputs,
you
either
get
an
interim
result
or
you
get
the
original
the
original
source.
B
B
It's
like
forgetting
to
handle
enter
result
because,
like
if
I
was
developing
https
loader,
it
would
probably
would
be
the
only
loader
I'm
running
so
I
might
never
think
to
test
it
with
interim
result.
I
might
only
like
look
at
resolved
url
every
time
and
it
would
work
for
me
and
my
development.
I
could
write
tests
around
it.
I
could
ship
it,
but
then,
when,
as
soon
as
someone
tries
to
chain
it,
it's
unchainable
because
they,
because
I
didn't
think
to
handle
the
case
of
when
an
interim
result
is
passed
in.
D
B
C
Yeah
but
like
if
you're,
for
instance,
using
a
mocker,
you
wouldn't
read
interim
results.
You
would
intentionally
wanted
to
throw
it
away.
C
Right
well,
what
I
was
thinking
with
this
design
was
that,
by
putting
it
first
in
the
like
putting
it
as
the
first
argument,
it's
more
difficult
to
ignore,
for
instance,
you
can't
just
omit
it.
So
when
you're
writing
your
function,
you
would
have
to
see
like.
Oh,
there
is
an
interim
result.
I
should
probably
use
that
if
it's
there
and
then
putting
this
as
a
second
parameter
nested
into
something,
I
did
that
as
like
a
you
can
like.
This
information
is
available
to
you.
It's
not
readily
like
in
your
face
available.
D
Well,
I
mean
I
mean
it
depends
just
because
you
know,
there's
interim
result,
there's
nothing
forcing
you
to
actually
do
anything
more
than
like
return
it.
Maybe
you
don't
have
to
check
if
source
exists,
you
don't
have
to
do
anything.
B
A
B
A
C
That
differs
the
the
return
api
of
the
hooks,
though
the
recursive
one
only
has
the
skipped
this
wouldn't
actually
matter
when
they're
sort
of
settled,
but
more.
C
B
C
So
like
currently,
the
output
of
these
is
the
same
and
then,
but
over
now
it
would
change
to
additionally
have
an
extra
one.
I
don't
think
the
one.
D
It
wants
to
have
short
circuit
from
what
we
talked
about.
Oh.
D
Well,
it
is
complicated
because
you're
trying
to
control
the
fourth
essentially
so
everything
in
our
return
value
is
going
to
be
all
the
control
structures.
So
short
circuit
is
like
a
break
if
there
was
always
a
catch
or
throw.
If
you
don't
check
interim
result.source,
then
ignore
would
be
like
a
continue
that
skips
over
that
throw.
B
B
D
B
B
B
B
D
B
The
other
thing
I
noticed
between
these
was
that
when
one
when
one
hook
calls
the
next
hook
in
the
chain,
it
could
pass
in
any
argument.
So
so
it
could
give
the
next
hook
a
completely
different
context
if
it
wants,
whereas.
C
D
C
Okay,
I.
B
Hadn't,
you
might
want
to.
B
So,
like
you
want
node
to
like,
if
the
conditions
you
know
property,
if
the
package
json
has
a
browser
field,
you
want
to
tell
node
to
use
that
one
instead
of
whatever
node
would
have
picked
by
default.
Then
you
could
like
rewrite
the
like.
You
know,
oh,
the
node
condition.
Now
is
the
value
of
the
browser,
condition
or
something
you
know
whatever.
B
When
we
add
we're
going
to
add
import
assertions
here
soon,
you
could
rewrite
you
just
call
like
the
default
load
and
tend
to
tell
it
that
the
import
assertion
was
type
javascript
or
something
like
that
in
order
to
like
convince
it
to
load
the
the
thing
that
otherwise
it
would
have
thrown
like
you
know,
unsupported
import
assertion
like
I
could,
I
feel
like
there
are
lots
of
use
cases
where
you
might
want
to
muck
with
the
the
contacts,
especially
when
passing
it
to
the
default
one.
Now
you
can.
B
You
can
do
that
with
yours,
because
default
load
is
available
to
each
hook,
but
that
just
means
it
can't
be
chained.
You
know
sorry
watch
can't
be
chained
like
in
the
iterator
chain.
Any
hook
can
call
default,
but
first
off
you
might
get
there's
a
possibility
that
default
load
gets
called
multiple
times
because,
like
you
have
three
hooks
and
all
three,
you
could
call
default
load
which
isn't
really
ideal
but
also
like
that's
the
only
one
that
can
be
called
with,
like
an
altered
context.
D
Well,
we
talked
about
this
earlier,
like
three
meetings
ago
before
I
started
changing
jobs,
it's
about
just
adding
data
and
then
restarting
the
loop
from
the
beginning
is
what
you
want.
If
you
want
to
do
something
like
the
browser
hook,
because
you
don't
want
to
call
default
load,
you
want
to
call
your
next
one
with
a
modified
context,
so
we
could
change
it
to
like
interim
context
that
mutates
as
it
goes
along,
we
could
do
other
things.
D
C
Our
object
gets
passed
along.
D
On
the
right
hand,
side
modifying
it
and
passing
it,
it
doesn't
have
to
be
modify
the
actual
object
it
could
be,
like
context
is
if
it's
set
on
the
return
value
it
is
passed
along,
but
you're
doing
all
the
manual
data
passing
on
the
right-hand
side
on
the
left-hand
side,
you're
doing
all
of
it.
In
your
code.
C
B
I
would
I
would
find
it
much
more
intuitive
because
it's
just
a
function
call
like.
I
know
the
arguments
of
a
function
saying
that,
like
oh,
if
interim
result,
dot
context
is
set
to
some
value
that
becomes
the
context.
Argument
of
the
next
hook,
like
that's
like
you'd,
have
to
read
the
documentation
to
know
that.
That's
what's
going
to
happen,
which
is
fine,
but
it's
I
would
find
it
a
lot
less
intuitive
like
I
know
when
I
call
next
and
I
pass
an
argument.
C
Well,
I
was
thinking
the
the
mutation
of
context,
the
argument
of
context
versus
including
it
in
the
return,
I'm
thinking
maybe
mutating
context.
As
the
arguments
that's
passed
in,
we
shouldn't,
I
think.
B
B
But
a
lot
of
people
really
prefer
the
like
immutable
style
and
they
expect
that
they
expect
that
the
the
object
passed
into
the
function
is
just
for
that
function's
use
and
not
that,
like
it's
going
to
persist,
afterward
and
node
is
going
to
keep
using
it
or
something
like
that
yeah.
So
I
think
that,
like
that'll
throw
a
lot
of
people,
if,
if
we
don't
behave
that
way
like
if
we
treat
the
context
object
as
as
not
throw
away
like,
we
actually
keep
persisting
it
afterward.
B
B
B
You
know
we're
the
in
the
pr
about
import
assertions,
I'm
doing
the
same
for
the
import
assertions
object
because,
like
resolve
now,
has
context.import
assertions
in
addition
to
parent,
url
and
conditions,
and
so,
if
resolve
returns,
import
assertions,
it's
treated
as
a
hint
just
like
format
to
go
into
the
context
of
load.
So
that's
another
case
where,
like
yeah,
you
might
want
to
return
that
to
to
affect
how
load
behaves
like
returning
it
from
resolve,
but
also
within
the
chain
of
either
resolve
or
load.
C
Sounds
good
to
me,
I'm
also
in
the
immutable
argument
camp
by
the
way,
so
I'm
on
board
for
that.
C
I
mean
yes,
it's
more
performant
but
also
like
there
are
surely
other
ways
to
get
that
performance
and
there.
B
D
B
Anyway,
so
yeah,
it's,
I
think,
that's
the
like
look
jacob
you're
implementing
this,
so
I
feel
like
you
should
have
the
final
say
since
we
don't
seem
to
get
anyone
else
to
give
any
input.
I
was
hoping
that,
like
maybe
the
the
apm
folks
or
some
of
them,
some
of
the
people
who
are
like
more
loosely
part
of
our.
D
How
would
I
speak,
I'm
biased,
I
know,
they've
already
done,
implementations
on
express
connect
and
the
workflow
on
the
left,
so
they're
going
to
choose
that
just
so,
they
have
less
work
to
do.
D
The
only
thing
that
I
think
they're
gonna
want
is
whenever
loaders
actually
occur.
They
don't
want
to
pass
in
the
cli
fleck
and
neither
of
these
really
changes.
C
D
B
B
Then
it
just
becomes
a
matter
of
of
kind
of
preference
of.
Do
you
want
this
to
look
more
like
a
for
loop
or
more?
Like
a
you
know,
jquery
chain,
pipeline
chain,
yep.
D
B
D
D
Workflows
are
very
explicit,
like
what
you
do:
support
I'm
more
familiar
with
the
one
on
the
left.
I'm
never
going
to
have
a
clear,
unbiased
opinion.
So
I'm
not.
B
B
D
D
D
C
D
D
B
D
D
D
D
D
D
Effective
in
general,
they're
they're
only
sharing
like
bytecode
references,
they're
not
actually
doing
copy
ops.
So
if
they
were
to
share
a
shared
array
buffer,
it
would
have
no
effect
if
it's
threaded,
not
threaded.
C
D
The
browser
atomic
stop
weight
is
still
disabled
on
the
main
thread,
but
I
think
the
rest
is
all
unflagged
again.
Oh
hari
was
the
safari
or
firefox.
I
forget
one
or
the
other
recently
unflagged
it
again,
but
the
other
two
have
been
shipping
it
unflagged
for
over
a
year.
D
B
If
we're,
I
don't
know
if,
if,
if
you
know
jacob
you've
already
made
up
your
mind
or
something
but
like,
I
think,
if
maybe
what
we
maybe
one
way
forward,
if
we
could
just
make
a
decision
now
but
like
if
we
don't
want
to
another
way
forward,
could
be
we
finished
cleaning
up
these
documents,
we
merge
in
the
merge
in
the
pr's
and
then
show
just
now,
we'll
have
just
like
straight
up
links
to
each
kind
of
fully
written
out
design
doc
we
could
share
we.
B
I
can
just
open
another
issue
on
the
lotus
repo
tag,
all
those
other
people
like
that,
guy
who's,
the
maintainer
of
ts
node,
for
example,
the
guy
who's,
the
maintainer
of
pnp,
and
be
like
okay.
If
you
were
going
to
write
ts
node
as
a
loader
like
which
of
these,
would
you
know
work
for
you
which
of
these
would
be
easier
for
you,
you
know
and,
and
it
kind
of
gives,
that
feedback
to
like.
B
If
you
were
going
to
write
it
as
one
of
the
examples
like
we
have
here
for
https
loader
et
cetera,
like
you
know,
assume,
we've
also
done
the
work
of
giving
you
lots
of
utility
functions
because
that's
like
independent
of
either
of
these.
What
would
what
would
your
preference
be?
You
know,
and
then
we
could
kind
of
see
what
their
feedback
is.
Maybe
even
if
we've,
even
if
we've
decided
now
or
if
we
think,
we've
decided
now
that
might
still
be
worth
a
worthwhile
exercise
to
do,
is
like
a
check
on
us
cool.
C
So
yeah,
I
was
going
to
say
that
I
think,
actually,
I
am
sort
of
leaning
a
little
bit
left
because
my
main
concern
was
and
the
impetus
for
creating
the
iterative
design
was
the
short
circuit
and
users
accidentally
doing
things
that
they
did
not
intend
to
do.
But
with
these
extra
checks
that
we've
sort
of
talked
about
now
and
being
able
to
pass
along
the
the
various
bits,
I
think
that
mostly
addresses
the
concerns.
C
The
only
thing
is
just
the
like
wrapping
your
head
around
how
this
works.
I
I
still
have
a
little
bit
of
trouble
with,
but.
B
That
could
just
be
me,
I
mean
that's,
that's
a
real
I've.
I've
been
struggling
with
that
too,
like
I
feel
like
recursive,
isn't
the
best
name
for
it.
I
like,
if
you
could
scroll
up
to
the
the
example
right
there,
so
we're
like
like
babel,
where
I'm
like,
putting
like
a
function
inside
another
function.
B
That
was,
I
thought,
like
the
easiest
way
to
explain
it.
I
mean,
does
that
if
that
doesn't
make
it
make
it
much
easier,
then
I
wonder
if,
like.
B
The
thing
is
you're,
never
going
to
be
calling
them
outside
yourself
like
like
you're,
never
gonna,
like
you're,
never
gonna
write
it
like
jquery
style,
where
it's
like
babble,
parentheses,
input,
close
parentheses,
dot,
coffee
script,
parentheses,
input,
parentheses,
dot,
https
right.
A
B
It's
only
if
you
were
to
write
one
of
those
hooks
within
the
contents
of
the
function.
That's
getting
changed.
You
know
what
makes
this
most
sense
for
you.
B
I'm
just
saying
like
I
don't
know
what
what
how
it
may
what's
the
easier
way
to
I
mean
I
don't
know.
Also
if
I
were
to
put
super
in
here,
like
my
instinct
as
a
user
would
be,
I
would
assume
that
super
would
always
refer
to
the
default
like
default
load
or
default
resolve.
You
know
because,
like
I
would
think
of
like
my
hook,
is
you
know
my
resolve
extends
default,
resolve
type
of
thing
and
so
super.
Oh.
D
No,
I
meant
like
like
each
of
these
would
become
a
method
on
a
class,
so
you
export
default
class
babel
loader
extends
nest,
abstract,
nested,
loader
or
whatever.
We
want
to
call
it.
That's
a
gnarly,
terrible
name,
and
then,
when
it's
constructed
I
mean
it'll,
get
whatever
hooks
to
the
next
nested
one.
B
D
B
C
D
No,
no
just
like
object-oriented,
aesthetic.
C
Sugar,
I
mean
I
do
like
that,
but
I
think
in
this
particular
case
that
might
cause
more
confusion.
B
Every
version
of
this
is
going
to
be
confusing,
so
it's
sort
of
a
question
of
like
what's
the
least
confusing
one,
and
also
the
corollary
to
that,
is
like
how
what's
the
best
way
to
explain
it,
to
try
to
avoid
as
much
confusion
as
possible
up
front
because,
like
you
said
like,
if
I
had
thought
to
include
short
circuit
in
the
original
version
because,
like
I
feel
like
a
lot
of
people
are
going
to
react
like
jacob
did,
but
like
oh
this,
this
design
sucks
it's
too
confusing.
B
B
I
mean
alternatively
like
if
we're,
if
we're
getting,
I'm
also
I'm
just
worrying
about
like
we
don't
have
too
much
attention
span
of
the
people,
we'd
be
asking
to
review
this
like
we
could
just
kind
of
get
the
if
we're
leaning
towards
the
recursive
one.
We
could
just
kind
of
get
that
document
in
you
know
final
final
shape
like
clean
it
up
as
much
as
we.
Let's
get
both
of
these
at
least
cleaned
up
and
merged
in,
but
we
could
then
maybe
just
ask
everyone
we're
leaning
towards
the
recursive
one.
B
Can
you
please
review
it
and
let
us
know
your
feedback
and
then
based
on
that
feedback,
we
might
say:
oh
okay,
well,
why
don't
you
take
a
look
at
this
iterative?
One
or
bradley
writes
the
third
one.
We
asked
him
to
take
a
look
at
like,
rather
than
giving
him
three
things
to
review
and
evaluate,
which
is
a
lot
of
work
for
people
to
try
to.
You
know,
evaluate
three
options
and
weigh
pros
and
cons,
etcetera.
We
could
just
tell
them
like
this
is
what
we're
leaning
on.
C
C
Yeah,
I
think
that
works.
Okay,
I
have
a
heart
stop.
So
all
right!
Okay,
cool!
Oh
wait!
If
we
have
one,
we
have
one
minute
left
you.
You
were
saying
something
about
fixing
that
bug
where
the
heck
is
this.
That
should
be
fixable.
If
someone
has
the
time
yeah.
D
B
I
was
okay,
I
have
something
else
about
that,
but.
D
B
Before
I
lose
you
bradley,
the
something
is
I
that
I've
marked
well,
while
I've
been
working
on
the
pr
I've
been
working
on
something
I've
been
noticing.
Is
that,
like
the
the
esm,
loader
seems
to
do
a
lot
of
creating
of
promises
and
putting
those
promises
into
cash
without
awaiting
them,
and
it's
like
not
clear
when
they
ever
get
awaited
or
resolved
or
or
what
happens
when
they
get
resolved?
B
B
B
C
D
Yep,
okay:
we
can
set
up
a
meeting
I'll
need
to
make
slides
for
that.
That's
easy!
Okay!
Maybe
in
a
week
or
two
just
throw
something
on
the
calendar
and
we'll
see
how
it
sticks.
B
Okay,
yeah,
I
was
thinking
I.
B
All
right
go
for
it
bye,
yeah.
The
other
thing
I
was
thinking
was
trying
to
break
up
the
that
esm
loader
file
into
more
just
take
chunks
of
it
and
put
it
into
smaller
into
other
files,
just
so
it's
kind
of
easier
to
manage,
which
is
a
little
tricky,
because
it's
a
class
but
yeah.
I
was
just
going
to
say.
Yes,
I'm
loader.
B
B
C
But
yeah
in
guys
pull
requests
that
just
happened
that
we
were
commenting
on
that
was
in
resolve,
not
in
esm
loader,
oh
resolves
also,
which
is
huge
yeah.
It's
enormous
both.
B
Of
them
could
be,
both
of
them
could
be
split
into
many
files,
but
yeah.
If
you
look
at
the
the
pr
that
I
was
working
on
that
antoine
started,
I.
D
B
The
like
yeah,
it
starts
with
a
four
four,
oh
something
or
other
it's
a
draft,
so
it
might
not
show
up
as
open.
B
B
Oh,
you
were
telling
me
that
he
means
he
means
unflagged
like
he
means
on
flag,
like
harmony,
import
assertions
from
v8
right,
not
on,
because
there
is
no
like
node
cli
flag
related
to
import
descriptions,
but
yeah.
If
you
look
in
here,
I
added
a
file
called
like
assert.js.
B
Where
everything
related
to
validating
the
import
assertions
happens
over
here,
I
feel
like
there
are
other
parts
of
the
of
the
esm
loader
that
could
be
kind
of
split
out
into
files
like
this,
that
that's
all.
Okay,
that's
just
like
a
like
a
code
organization
thing
that
we
might
want
to
do.
It's
like
a
follow-up
vr.
C
Oh
yeah
sure
I'm
all
for
stuff
like
this.
I
remember
it.
B
It
does
kind
of
screw
up
get
history
a
little
bit,
but
these
files
don't
have
that
long
of
a
history.
So
I
kind
of
feel
like
now's
the
time
to
try
to
break
them
apart
into
a
small
as
because
they're
only
going
to
grow
like
a
certain
sas
is
50
lines
now,
but
once
they
add
support
for
other
types
of
assertions.
C
Yeah,
absolutely
on
board.
The
reason
I
didn't
do
it
in
mine
was
because
my
pull
request
was
already
significantly
bigger.
Oh
yeah,.
B
We
should
have.
We
should
do
that
as
its
own
pr,
so
it's
like
there's
a
commit
on
master,
just
doing
that,
so
that,
if
you're
trying
to
trace
the
history
of
these
files,
it's
like
it's.
It's
not
just
that.
Like
100
lines
got
deleted
here
and
added
over
here,
and
you
don't
want
to
do
that
and
have
changes
within
those
hundred
lines
on
commit.
You
know
so.
C
Okay,
cool
yeah,
I'm
I'm
down
for
that.
If
you
want,
I
can
rough
out
some
stuff
like
a
list
of
stuff
that
I
think
might
be
a
good
candidate
to
do
that.
B
I
mean
it's
not
a
high
priority
but
yeah
whatever.
Whenever
you
want
to
do
it,
I
mean
I
want
to
land
this
first,
that's
that's
what
I'm
working
on
sure
we
can
land
this
first.
Do
that
and
then
do
chaining
or
whatever
I
mean
it,
doesn't
matter
the
order
kind
of
kind
of
more
like
what
whatever
you
want
to
land
in
what
order.
C
Okay,
cool
well,
let's
see
I'll
put
together
the
list
first
to
see
how
much
stuff
we've
got
because
then
I'm
thinking
it
could
potentially
make.
If
we
actually
do
this
splitting
a
part
of
stuff,
it
could
potentially
make
the
chaining
implementation
easier
or
maybe
harder-
I
don't
know,
but
what
it
would
really
make.
B
Easier
is
that
other
that
other
issue
about
utility
functions
yeah
because,
like
splitting
met
like
if
I
met
like
getting
a
method
of
u
of
es
loader
splitting
it
out
to
be
a
freestanding
function
that
just
you
know,
didn't
have
any
references
to
this,
but
just
took
as
function.
B
Arguments
like
took
as
input
everything
it
needed
and
then
spit
out
as
output,
that's
kind
of
what
we
need
to
do
to
make
the
utility
functions,
because
then
that
becomes
a
function
that
we
can
export
off
of
module,
which
is
what
they
need
for
that
so
kind
of
declassifying,
yes,
loader
ism
loader
might
ultimately
be
a
good
thing
in
general.
So.
B
B
B
Well
sounds
great
all
right!
Well,
cool!
Thank
you
yeah!
So
let
me
know
if
you're
gonna
are
you
gonna
do
the
next
pass
on
the
design
I
feel
like
we
should
finish
the
design
docs
first
and
get
those
merged
in
so
last
night?
Why
don't
you
do
your
whatever
passes
you're
going
to
do
and
then
give
me
a
ping,
and
I
could
I
could
do
whatever
final
pass
about
short
circuit
or
anything
else
to
add,
and
then
we
can
merge
them
in.
C
C
I
can
do
this
clean
up
stuff
that
we've
got
here
in
like
the
next
hour
or
something
oh
yeah.
Okay,
I
don't
think,
there's
really
anything
to
look
with
that
and
then
I
can
do
the
the
which
I'm
gonna
call
it
the
examples
like
later
tonight
or
tomorrow
or
something
and
then
there's
less
less
urgency.
B
Yeah
I
mean
like
I'll
get
to
it
so
yeah.
If
you
want
to
do
that
and
just
give
me
a
ping
when
you're
done
I'll,
just
read
it
and
then
hopefully
we
just
merge
it
in
and
yeah.
Maybe
we
can
ping
the
rest
of
the
group
that,
like
yeah,
we
think
this
has
done
any
any
notes.
Before
I
mean
I
don't
think
the
notes
are
that
important
for
design
doc
like
if
they
have
notes
we'll
just
open
new
pr
to
address
them,
so
cool
yeah
we
just
merged
it
in
that's
good.