►
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).
A
All
all
right,
I'm
gonna
close
that
on
your
neck.
Oh
all,
right
hello,
I
am
jeffrey.
This
is
jacob.
We
are
here
for
the
june
25th
2021
meeting
of
the
node.js
letters
team.
It
is
just
us
and
our
agenda
is
basically
to
go
through
jacob's
pr
that
I'm
hoping
to
land
soon.
So
I
think
we're
just
gonna
dive
into
that
and
if
anyone
else
joins,
we
can
do
other
business.
So
let
me
get
shut
up.
A
A
Oh
okay,
so,
rather
than
making
undefined
one
of
the
options
like
position,
is
obviously
either
integer
or
undefined
for
this
function,
but
they're
not
listing
undefined
here.
So
we
could
just
put
parent
url
in
brackets
and
then
say
string
and
that's
probably
all
we
need
to
do.
Okay,
cool.
A
But
yeah,
that's
just
a
minor,
a
minor
note
all
right,
so
where
is
it?
This
looks
good,
thank
you
for
making
that
change.
This
was
just
a
typo.
Let's
see.
B
A
A
B
A
Returns
the
resolved,
url
and
optionally,
it's
format
as
a
hint
of
the
load
hook.
A
I
don't
see
anything
else
so
so
it's
just
like
I
thought.
B
B
Okay,
I've
just
got
it
locally,
because
there's
extra
bits
that
are
relating
to
that
follow-up
story
we
were
talking
about
before
we
started
the
meeting
of
adding
a
nice
to
have
where,
if
a
resolve
hook
returns
a
format,
but
there
is
no
custom
load
hook,
provided
that
it
would
be
automatically
piped
to
node's
custom
load
hook
which
would
consume
it.
B
So
I
just
didn't
properly
separate
the
the
staged
unstaged
bits,
so
I
can
do
that
right
now.
A
Oh
okay,
well
anyway,
I
then
you
can
just
treat
this
as
like.
A
reminder
then
like,
if
you
already
have
it
somewhere
but
like
as
long
as
it's
somewhere.
Probably
in
the
resolve
section,
I
think,
would
make
the
most
sense
but
yeah.
This
is
just
like
a
first
pass.
There's
a
whole
bunch
of
things
that,
like
there
are
some
people
who
are
members
of
the
tsc
are
like
very
particularly
like
certain
technical
language
like
they.
A
They
don't
want
you
to
say
note
that
just
be
like
just
say
what
it
is
rather
than
note
that
such
and
such
they
discourage
using
the
word
you
node
always
just
be
written
as
node.js
like
there's
a
whole
lot,
there's
like
a
list
of
things
that,
like
you
kind
of
start
to
remember
as
you
write
these
a
lot,
but
it
can
be
very
frustrating
when
you're
first
starting
this,
like
you
know,
some
of
these
are
caught
by
the
linter,
but
a
lot
of
them
aren't.
B
Yeah
the
note
that
one
was
I
did
that
when
I
was
including
these
latest
things
and
it
complained
about
it.
I
was
like.
A
Okay,
sure
I
mean
I
guess
it's
just
considered
bad
writing.
You
know,
but
someone's
preference
essentially
of
what
is
considered
good
or
bad
right.
So
all
right
so.
A
A
A
B
Yeah
so
yeah,
this
is
fine.
Oh,
I
know
what
I
did.
I
added
on
new
line
722
and
also
in
added
format,
and
then
that
caused
the
lines
to
be
longer
than
80
characters.
So
then,
in
order
to
not
have
like
some
bizarre
break,
I
added
more
line
breaking
and
stuff.
A
A
All
right
I'd
love
to
be
wrong
in
that,
but
I
I
didn't
I
mean
we
just.
I
think
so.
A
Well,
you
might
have
done
it
before
in
code,
that's
being
transpiled,
because
if
this
is
transpiled,
this
will
work
in
the
common
base
equivalent
where
it's
like
require
infectious
promises
that
will
work,
but
I
think
that
this
doesn't
work
in
esm,
like
native
esm,
let's
just
just
something
to
check
I'll.
Just
add
a
note.
B
A
We're
actually
doing
the
so
I
I
think
the
way
that
this
was
well.
This
was
get
format
but
like
in
the
old
get
source.
Well,
I
was
just
using
default
transform
source,
so
I
think
the
way
that
this
example
should
be
written,
though,
is
to
not
like
actually
load
the
file
from
disk,
because
that
way,
this
means
that,
like
there's
no
possibility
of
chaining
this
hook
now,
obviously
we're
not
supporting
chaining
yet,
but
you
know
we
might
as
well
like
write
the
example
with
that
future
in
mind.
A
I
think
if
this
is
a
weight
default
load,
then
that'll
you
know
become
next
or
done.
You
know
whatever
the
change
version
is
we
replace
default
load
with
that
call,
and
then
this
works
fine.
You
know
what
I
mean,
whereas
here
it's
like,
I
think,
there's
this
becomes
a
dead
end
like
we're,
never
calling
the
the
next
book
in
the
chain.
If
we
do
read
file,
you
know
what
I
mean:
okay,
sure
yeah,
because
I
think
what
default
load
takes.
A
A
A
A
You
know
like
the
default
versions
of
the
hooks
we
needed
to
take
that
out,
like
whenever
the
loaders
are
fully
finished,
like
whatever
is
returned
by
this
hook
to
node,
for
that
node,
esm
loader
to
actually
go
and
execute,
like
all
the
loader
hooks
have
run
at
that
point,
and
now
it's
in
the
hands
of
node
to
do
something
with
at
that
point
is
when
we
want
node
to
check
like
do
I
support
this.
You
know
what
I.
B
Mean
give
me
one
second,
this
would
be
in
esm,
loader
get
module
job
or
something.
A
But
even
then
like,
if
we
had
a
loader
returning,
something
that
says
like
like
a
hook
returning
something
like
file
that
copy
well,
this
would.
This
is
just
returning
the
the
actual
source,
so
there's
no
file
extension
for
it
to
check
that
it
doesn't
support.
So
this
would
be
fine.
So
I
guess
it's
just
more
that,
like
inside
default
load
like
when
we
call
the
default
versions
of
nodes
like
default,
resolve
and
default
load.
There
shouldn't
be
any
error.
B
You
know
what
I
mean
now
that
you
mentioned
that
I
think
that
is
the
update
that
was
made,
I'm
trying
to
pull
it
up
right
now,
but
maybe.
B
Oh
yeah,
I
believe
it's
in
the
pr
currently
github
is
collapsing.
It
collapsing
that
file
because
there's
like
600
lines
of
stuff,
I'm
trying
to
pull
it
up
on
my
local,
but
it's.
B
Frozen,
I
believe
we
moved
all
the
checks
out
of
the
individual
methods
and
then
moved
them
just
to
the
end.
A
This
repo
has
that
example
right
here,
so
I
would
say
like
check
out
this
repo
on
your
machine.
A
You
know
next
to
your
node
repo
update
this
example
with
whatever
your
you
know,
whatever
the
new
version
is
in
the
docs
and
just
make
sure
it
runs,
you
know
what
I
mean
and
then,
and
ideally
with
something
like
this,
so
that
it'll
be
so
that
we
don't
need
to
update
the
example
again
when
we
add
chaining-
or
you
know-
maybe
we
rename
this
to
next
or
whatever
it
is,
but
other
than
that
it
doesn't
need
to
be
updated
right
and
then
because
we
don't
want
to
publish
an
example
that
breaks.
B
A
And
there's
no
way
really
to
do
that
within
like
unless
you
could
write
this
example
as
a
test.
Somehow
in
the
repo,
I
don't
know
how
you
I
mean
you
can't
realistically,
because
you
can't
put
the
covers
group
dependency
in
the
node
project.
So
that's
why
I
think
I
had
to
create
this
separate
repo
for
that,
and
the
esm
example
makes
a
poor
test
because
we
don't
want
to
actually
make
like
network
calls,
as
part
of
you
know,
running
the
unit
tests.
B
I
do
believe
some
of
the
unit
tests
that
I
wrote
for
this
have
custom
file
extensions
so
like
things
that
don't
even
exist,
so
the
resolve
hook
just
needs
to
tell
know
that,
like
this
is
okay
and
then
and
then
it
it
will
pass
to
the
load
hook.
Just
fine
and
the
load
hook
needs
to
be
like
looking
for
it
and
handle
it.
Otherwise,
if
it
eventually
passes
through
to
the
end,
then
node
will
barf.
B
B
Yeah-
and
I
remember
you
added
me
to
that
repository-
I
was
just
moving,
so
I
haven't
had
a
chance
to
actually
do
it
yet,
oh
and
then
yeah
I
saw
this.
This
is
good.
Did.
A
A
A
I
basically
wanted
to
be
like
what
would
be
a
loader
version
of
that
other
flag.
Experimental
model
resolution
equals
node
like
say
we
were
to
remove
that
like
there's,
never
going
to
be
consensus
to
make
it
non-experimental,
so
it's
either.
It
stays
as
a
flag,
that's
experimental
forever
or
we
just
remove
it,
which
also
might
not
get
consensus.
So
maybe
the
status
quo
will
stay
that
way
forever,
but
I
at
least
wanted
to
have
an
option
like
if
people
wanted
to
remove
it,
it
should
be
something
that's
doable
via
a
loader.
A
B
A
I
think
that
that
would
be
true
if
you
knew
the
like
root
point
of
the
project,
which
I
think
in
node's
case.
It
doesn't
because,
like
any
required
call
or
import
statement
could
just
be
load
from
anywhere
on
the
file
system.
You
also
don't
necessarily
know
that
the
that
say
the
root
of
your
project.
A
Maybe
it
has
a
million
non-javascript
files
in
there,
and
so
then
it's
like
the
file
list
is
incredibly
expensive,
for
you
know,
say
two
javascript
files
and
you're
mixed
with
a
million
images,
or
something
like
that.
You
know
what
I
mean
so
like
yeah
like
it
could
be
faster
depending
on
the
project
like
in
a
node
models.
Folder
would
probably
be
faster,
but
I
think,
like
node,
doesn't
want
to
make
those
assumptions
where
it's
like
you
know.
A
It's
a
linear,
a
linear
cost
to
just
like
for
every
for
every
module,
specifier
you're,
making
up
to
six
calls
lifestyle.js
file.jsonpile.node
file,
slash
index.js
file,
slash
index.json
file,
index
dot,
node,
you.
B
A
So
yeah,
that's
painful
to
potentially
make
six
file
system
calls,
but
you
know
it's
capped
at
six.
I
think
that's
probably
what
they
were
thinking,
but
anyway
yeah
I
wasn't
trying
to
re-implement
the
algorithm
I
just
wanna
or
re-imagine
the
algorithm.
I
just
wanted
to
take
the
algorithm
that
already
existed
for
required
for
finding
extensions
and
being
like
say
that
so
that
that
algorithm
just
doesn't
exist
in
esm.
A
Unless
you
use
this
experimental
module
resolution
equals
node
flag,
but
imagine
that
that
flag
doesn't
exist.
How
would
you
achieve
the
same
with
a
loader,
because
I
think
there's
a
lot
of
value
in
that
in
that
there
are
tools
like
webpack
that
do
just
that,
like
that
they
they
re-implement
nodes
resolution
and
typescript.
The
texture
compiler
itself
also
does
this.
They
re-implement
node's
algorithm,
like
a
typescript
case,
to
like
find
dot,
ts,
files
and
stuff
like
that.
So
it's
symptoms
already
happening
in
these
like
build
tools.
You
know
you
like.
A
So
so,
since
this
is
like
a
common
use
case,
that
lots
of
tools
kind
of
would
need,
I
was
thinking
like
we
should
be
able
to
make
a
loader
for
this
and
that
that's
a
good
proof
of
concept
of
like.
If
I
can't
do
this
using
the
current
loaders
api,
then
the
loader's
api
is
deficient,
because
this
is
something
that
should
be
doable.
You.
A
Our
movies
api,
so
these
two
contrast,
script
and
https
already
work,
and
that's
why
they're
in
the
examples,
I
could
never
get
this
one
to
work.
So
you
know,
maybe,
after
your
vr
ships,
it
would
be
something
to
revisit
derek
was
working
on
this
one.
I
don't
know
where
he
left
off
with
that.
I
think
it
had
to
do
with
like
it
was
a
loader
to
verify
like
checksums
or
something
like
that
of
the
files
being
loaded.
So
maybe
he
got
to
work.
I
don't
remember,
or
maybe
sorry
it
wasn't
derek.
A
It
was
aurelia
anyway,
there's
good
stuff
in
here.
So
it's
a
varying
states
of
workingness,
but
I
would
say
these
two
at
least,
let's
make
sure
work
under
your
branch
or
updated
version
of
the
work
on
your
branch
and
then.
A
The
docs,
with
whatever
the
final
versions
of
these
are
and
then
we
have
like
good
examples.
We
should
update
this
repo
too,
and
then
we
have
good
examples
for
people
to
follow
so
yeah.
I
I
would,
I
don't
know
if
we
want
to
go
through
all
of
this
together
live
because
I
haven't
read
all
this
part
yet,
but.
A
B
A
Okay,
yeah
here,
maybe
that's,
maybe
I'll-
just
give
it
through
looking
for
the
cop
for
any
other
comments.
What's
this
one.
A
Okay,
by
the
way,
I
know
people
keep
talking
about
like
package
scoped
loaders
that
came
up
a
lot
early
on
in
the
modules
team
discussions
like
even
before
we
were
talking
about
loaders.
We
were
talking
about
package
scope,
configuration
so
like
we
do
have
some
package
scope
configuration
which
is
like
tight
field,
the
exports
fields,
the
imports
field.
A
I
I
think
those
ended
up
getting
implemented
as
like
part
of
node,
specifically
because
implementing
package
scope,
loaders,
would
have
been
too
problematic
because,
like
like,
you
would
have
to
like
this
for
the
same
reason
that
loaders
currently
are
you
always
have
to
use
them
via
flag
because,
like
node
has
to
have
them
like
loaded
in
memory
before
it
loads
any
application
code
files?
Well,
how
would
you
find
all
these
loaders
hidden
in
packages
before
loading
application?
A
You
know
you
have
to
scan
the
entire,
like
subfolder
tree
from
the
current
working
folder,
to
find
all
loaders
in
all
subfolders,
whether
or
not
those
packages
ever
get
imported
by
the
project
and
then
you'd
load
that
and
then
you
load
all
of
those
and
and
keep
track
of
what
their
scope
was
like.
This
affects
this
folder
and
subfolders,
and
this
effect
this
software
and
then
you
would
like
load
everything
so
that
this
would
be
like
a
tremendous
performance.
Yet,
and
so
that's
why
this
was
you
know
not
pursued
essentially,
so
I
think.
A
You
know
not
to
say
that
it's
like
completely
unachievable
like
you
could
maybe
have
a
flag
that
enables
this
behavior
of,
like
you,
know,
a
dash
dash
package
loaders
flag,
that
only
when
that
flag
is
set
does
it
search
all
subfolders
for
loaders
and
blah
blah
blah.
So
it's
not
like
it's
not
like
people
are
opposed
to
it
per
se.
It's
more
that
like
once,
you
start
getting
into
the
details
of
like
how
would
you
actually
achieve
this?
It
gets
real
messy
real
fast.
A
So
it's
you
know
it's
potentially
doable,
but
I
I
I
feel
like
it
was
something
people
were
talking
about
with
regards
to
oh,
we
want
to
load
loaders
through
package.json
rather
than
through
flags,
as
if
that's
just
an
easy
thing,
but
there's
a
lot
of
there's
a
lot
of
extra
complexity
with
that,
like
maybe.
A
Maybe
like
there,
I
don't
think
we
have
a
concept
yet
of
the
like
entry
point
package
that
jason
so
like
you
have
to
give
node
an
entry
file
like
node
space,
file.js
or
something
like
that
or
entry.jsa,
and
node
immediately
has
to
find
the
nearest
parent
package
adjacent
to
that
file
to
know
if
that
file
should
be
treated
as
dsm
or
not
right.
So
yes,
we
have
loaded
that
package
of
json
before
doing
anything
and
if
that
package,
that
jason
has
stuff
in
it.
A
But
we
don't.
We
still
don't
provide
package
scoped
loaders.
It's
like
these
are
global,
loaders
loaded
as
part
of
loading,
your
app
as
if
you
would
set
them
as
a
flag,
but
I
have
a
feeling
they're
going
to
be
they're,
going
to
be
issues
with
that
approach
of
like
privileging
one
package
adjacent
over
another
or
over
all.
A
I'm
sure
people
are
going
to
be
pointing
out,
like
all
sorts
of
unintended
consequences.
Once
you
start
doing
that,
like
wait,
why
would
a
lo
you
know,
say
you
had
a
loader's
flag
to
package
up
jason?
Why
is
it
only
like?
Why
is
it
ignored
everywhere
else,
except
here?
Is
that
confusing,
or
usually
you
know
I
mean
like
people
will
come
up
with
complaints?
A
A
We
have
consensus,
at
least
on
a
whole
bunch
of
stuff
already
of
like.
Yes,
we
want
to
do
this
pr.
You
know
we
need
to
nail
down
the
specific
language
of
specific
code,
but
there's
consensus
that
we
want
to
do
what
you're
attempting
to
do
here.
You
know
what
I
mean,
like
the
hard
part
has
already
been
achieved.
There
is
consensus
that
we
want
to
add
chaining.
We
could
debate
next
versus
done,
but
I
think
for
sure
we
will
do
one
or
the
other
of
them,
and
there
is
consensus
that
we
want
to
do.
A
At
least
you
know
one
of
them,
something
like
that.
So
it's
like
I,
I
kind
of
want
to
focus
on
like
you
know,
we
have
a
path
forward.
That'll
get
us
a
long
way
and
getting
rid
of
needing
to
use
a
flag
feels
like
a
much
lower
priority,
especially
if
it's
going
to
be
difficult
to
come
up
with
a
design
that
satisfies
everyone.
So
yeah.
B
Where's,
the
oh
also
it
looks
like
brian
and
steven
are
here
too
they've,
probably
been
here
a
while
in
new
york
yeah.
I
didn't
until
bradley
started
posting
in
the
chat,
and
I
was
like.
B
A
C
Hey
one
minor
clarification:
we
already
take
that
perfect
for
the
directory
crawl
for
the
type
field,
so
it
doesn't
matter
all
right.
Well,
then,
take
it.
We
we
pushed
back
very
hard
against
the
type
field
in
the
early
days.
Well,
we
got
pushback
because
because
it
was
costly
to
do
and
then
eventually
it
was
just
too
hard
to
get
any
compatibility
with
the
ecosystem
without
it.
B
Yeah
I
was
going
to
ask
if
we
could
piggyback
off
of
that
type
search.
So
it
sounds
like
yes
yay,
so
we
actually
have
just.
A
C
There
were
two
main
concerns
you
kind
of
hit
on
them.
Performance
is
one
of
them
where,
if
you
have
loaders
in
every
different
package,
that
means
your
packages
act
reliably.
But
that
means
you
have
potentially
hundreds
of
loaders
right.
A
For
which
for
a
node
modules
project
like
I
can
imagine
there
being
a
handful
of
voters
that
are
really
popular
like
oh
this
one
about
adding
the
file
extensions
or
something,
then,
if
you've
got
you
know,
500
node
dependencies,
they
use
that
loader.
It's
like
how
much
of
a
performance
hit.
Does
that
give
you.
C
Well,
that
depends,
but
on
the
other
hand,
you
can
have
only
one
loader,
like
you
said
at
the
top
level,
your
application
loader.
But
then
your
dependencies
fail
to
load
if
you
run
them
as
bins
and
things.
A
C
So
one
of
the
big
concerns
was
typescript
is
costly
to
spin
up
really
costly,
and
so,
if
you
spin
up
the
typescript
api
and
server
compiler
whatever
you
want
to
call
it
you're,
adding
a
good
half
second
to
your
load
time
to
do
effectively
nothing
in
the
beginning.
A
Yeah,
you
may
not
even
use
it
right
and
there
might
be
lots
of
dependencies
that
they
just
want
to
ship
typescript
and
not
transpile
it.
They
don't
want
to
bother
set
up
any
build
pipelines,
they
just
throw
in
the
typescript
loader
and
then
package
it
json
and
call
it
done.
And
now
it's
like
you've
got
a
really
slow
dependency.
C
C
Basically,
you're
shipping
stuff-
that
is
not
runnable,
directly
off
registries
and
so
he's
the
main
voice
of
the
kind
of
compiler
registries
like
unpackaged.
He
does
system.js
in
jspm
and
so
like.
If
you
ship
stuff
up
there,
that
they
can't
run
it
kind
of
breaks
their
whole
workflow.
A
Arguably,
like
most
node
packages
already
have
this
problem
with
things
like
you
know,
missing,
file,
extensions
and
import
statements,
et
cetera,
so
they're,
like
those
package
registers,
are
already
doing
some
transformation
correct,
but
yeah
like,
if
you
add
at
least
the
transformations
they're
doing
it's
like
they,
it's
a
known
limit
of
what
they
need
to
do
to
transform
it's
like
all
the
stuff
that
works
in
node
and
not
in
browsers,
but
that's
at
least
a
known
quantity
whereas,
like
if
a
package
could
ship
a
custom
loader,
then
it's
like
something
like
unpackaged
would
have
no
idea
what
transformations
it
would
need
to
do
to
make
that
runnable
in
a
browser.
C
Yep
and
this
gets
more
complicated
because
per
package
loaders
may
pin
to
a
specific
version
like
say:
you've
got
a
coffeescript
version
that
introduces
a
breaking
change
for
whatever
reason
you
want
to
have
a
single
package
using
that
coffee
script
transform
if
it
hasn't
updated
to
handle
the
braking
change
and
other
things
may
have
already
updated.
So
they
want
to
be
on
different
versions,
and
so
that's
not
doable
from
the
application
level.
You
have
to
go.
C
A
There's
like
a
a
long
ticket
on
the
dino
project
that
I
got
tagged
in
a
long
time
ago,
where
so
like
dino,
basically
bundles
the
typescript
transpiler
in
inside
their
runtime,
and
they
they've
had
this
ticket
open
for
like
two
years
now.
It's
like
support,
other
transpilers,
and
so
like
the
first.
The
first
custom
one
would
be,
would
be
coffee
script,
because
I
mean
I
guess
it's
still,
the
second
most
popular
one
after
typescript.
A
So
then
the
quest,
and
so
then
my
question
was
like
wait
a
minute.
So
how?
How
are
you
like
dealing
with
versions
of
like
versions
of
tech,
script,
they're
just
like?
Well,
it's
just
baked
into
the
dino
run
time
like
just
as
node
has
a
particular
version
of
the
v8
runtime.
A
And
that's
it!
You
just
can't
run
your
typescript
code
with
any
other
version
of
the
typescript
compiler
with
you
know
it's
just
like
not
possible,
so
adding
support
for
custom
transpilers
also,
potentially
then
means
they
like
allow
you
to
potentially
use
a
different
version
typescript
with
dino,
which
then
opens
up
a
can
of
worms.
So
I
think
they
wanted
to
figure
out
that
issue
of
like.
A
C
During
this
time,
the
only
thing
I've
got
is
the
https
support
pr
for
node
isn't
currently
compatible
with
loaders,
because
it
separates
out
import
meta,
url
from
the
module
map,
storage
location,
which
loaders
don't
do
right
now.
This
has
been
a
long
running
issue.
It's
like
two
and
a
half.
No,
I
think
it's
three
years
old
on
the
modules
working
group
issues
where
you
can't
set
the
cache
key
is
what
we
called
it
at
the
time
of
a
resolved
module.
C
Import
something
correct
so
in
the
web
specs
you
can
have
two
different
module
instances
with
the
same
import,
meta
url.
We
don't
support
that.
Currently
with
the
loader's
design.
Sorry,
you
can
have
two.
Can
you
say
that
again
you
can
have
two
different
instances
of
a
module,
so
I
the
classic
one
is
you're
at
a
javascript
cdn,
your
load,
slash
react.
A
A
You
could,
you
could
add
it
to
the
like
one
of
the
it's
either
the
readme
or
the
roadmap
file
and
the
loaders
repo
just
added
onto
the
markdown
of
like
the
to-do
list
there,
like,
I
already
have
like
five
items
for
the
next,
like
five
pr's.
You
just
add
to
that.
Unless
there's
some
place
where
you're
keeping
track
of
https
related
stuff.
C
Not
really
so
that
was
one
thing.
There
was
another
thing.
We
have
an
outstanding
request
for
a
data
channel
to
be
added
to
loaders
so
that
your
get
global
preload
code
can
talk
to
your
hooks,
so
resolve
and
other
stuff.
I'm
probably
just
going
to
pr
that
somewhere,
it's
not
going
to.
C
C
I
can
wait
till
it
merges
before.
I
write
that
pr
sure.
A
A
A
A
But
yeah
I
mean
I
feel
like
I
I
haven't
developed
in
this
section
of
the
code
base
in
like
almost
a
year
and
a
half,
so
I
feel
a
little
rusty,
so
I
have
any
time
to
test
it.
I
think
I
might
have
already
done
it,
so
I
feel
a
lot
less
worried
that
I
would,
if
he
hadn't,
looked
at
it,
but
just
to
get
more
eyes
on
it
would
be
good
because
it's
a
pretty
big
one
like
he
does
the
first
like
three
bullets
of
our
loader's
to-do
list.
So.
A
All
right
we've
got
four
minutes
and
then
the
other
team
is
gonna
start
showing
up
anything
else.
We
should
cover.
B
I
think
no
all
right,
I
guess
if
anybody
had
any
opinion
on
the
issue
that
we
talked
about
before
you
guys
joined
of
automatically
passing
along,
resolves
format
to
nodes
default
load
hook
if
no
custom
load
hook
is
defined.
If
you
had
any
strong
opinions
on
that,
we
were
planning
to
do
that
as
a
follow-up,
so
yeah
I'll,
add.
A
Okay,
I
so
yeah
in
the
future.
I
will
I
thought
I
had
this
yeah.
I
did
have
this
up
I'll,
keep
the
my
slack
open
to
the
esm
channel
when
I
start
these,
so
that
if
I
don't
notice
people
on
zoom,
you
can
ping
there
and
I'll.
Try
to
add
you
and
and
yeah
I'll
see
you
guys
next
time
cool
thanks.
Everybody.