►
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
All
right,
we
are
the
node
loaders
team,
it
is
september,
28th
2021,
all
right,
it's
our
regular
meeting
and
there
we
go
we're
live
on
youtube.
So
brian
did
you
want
to
say
anything
else.
We
were
just
starting
to
talk
about
instrumentation
before
I
decided
to
start
recording
so.
C
D
Sure
so,
since
a
few
days
ago,
when
we
had
our
last
meeting,
I've
made
the
pull
request.
Well,
actually,
jeffrey.
You
made
the
initial
request
to
pull
this
stuff
apart,
and
then
I
made
the
subsequent
one
that
created
the
two
proposals
of
the
quote-unquote
recursive
version
and
the
iterative
quote-unquote
version
of
how
loaders
might
be
implemented
and
updated.
The
examples
per,
I
think,
all
the
things
that
we've
talked
about.
D
I
started
to
add
the
example
for
gail's
mocking
so
so
much
as
we've
sort
of
gleaned
from
that.
I
only
got
about
like
three
quarters
of
the
way
through
that,
so
I
didn't
include
it
in
my
most
recent
push
to
the
pull
request,
but
those
things
are
up
and
basically,
as
I
was
kind
of
going
through
those
sorry
to
repeat
myself
for
those
on
slack,
it
seems
like
they're,
largely
similar.
D
D
So
when
I
was
making
the
the
updates
to
the
various
things
I
had
to
make
them
multiple
times,
because
I
kept
updating
them
incorrectly
and
that
in
basically
all
cases
we,
I
think,
have
universally
agreed
that
a
short
circuit
should
be
explicit
rather
than
an
implicit,
because
it's
as
it
was
previously,
it
was
too
easy
to
accidentally
do
it,
and
then
you
end
up
with
like
very
weird
results
that
are
difficult
to
figure
out
what
happened.
So
I
have
not
added
that
to
the
recursive
proposal.
B
I
did
have
a
thought
about
that,
which
was,
I
think
it
could
be
as
simple
as
like,
like
every
hook
needs
to
return
an
object
because
it
either
needs
to
like
short
circuit
and
return.
What's
intending
to
be
the
final
object
or
it
needs
to
call
next
and
then
return
the
return
value
of
that
so
you're
always
returning
something.
So
I
think
what
we
could
do
is
we
should
there
should
be
some
way.
B
I
would
think
to
track
whether
a
function
has
been
run
so
like
as
say,
you've
got
three
resolved
hooks
like
three
user
defined
resolve
hooks
and
then
the
node
resolve
hook.
Maybe
we
don't
care
about
the
node
one,
but
the
the
other
three
like,
as
we
like,
take
them
from
the
loaders
that
the
users
have
to
find.
B
We
could
like
wrap
them
in
some
kind
of
simple
wrapper
that
just
tracks
if
it's
been
run
or
something
like
it
just
passes
its
same
input
into
the
loader,
the
exported
resolve
hook,
that
came
from
the
user
loader,
and
then
we
inject
something
that
says
like
okay,
you
know,
loader
number
one
resolve
hook
has
been
executed,
you
know,
and
so
what
we
could
do
is
like
for
a
particular
specifier
if
a
loader,
if,
if
there's,
if
we
don't
get
all
three
of
those
flags
set,
so
that,
as
in
like
all
three
user
defined
resolve
hooks
haven't
been
run,
then
you
you
look
into
the
return
value
of
the
object
which
currently
the
return
value
resolve,
is
just
an
object
with
one
property
url.
B
So
if
not
all
of
them
have
been
run,
then
you
also
look
in
the
return
object
to
see.
Is
there
also
a
short
circuit,
true
property
on
that
return?
Object,
if
not
error.
D
Cool
I
like
that
idea.
I
was
toying
with
basically
exactly
the
same
thing
of
like
setting
a
short
circuit
property
on
the
return
to
say
true
and
that
being
the
flag,
rather
than
having
to
inject
another
argument
into
the
thing
and
blah
blah
blah
blah
so
yeah.
I
like
that.
B
You
know,
stay
there's
already
so
much
input
for
each
function
that,
like
the
more
things
we
cram
into
the
input
for
the
function,
it's
almost
almost
makes
it
more
difficult
because
then
it's
like,
when
you
get
to
chaining,
then
it's
like
all
other
hooks
need
to
kind
of
handle
all
potential
input,
and
so
it
was
trying
to
kind
of
keep
it
simple
in
that
regard
like
like,
we
were
initially
talking
about
like
like
right
now.
B
It's
like
the
last
property
is
next,
which
replaces
the
current
shift
versions
like
default
resolve
because
it's
always
like
we
have
the
recursive
chaining
model
is
in
node
right
now,
but
it's
always
just
like
user
to
node
and
no
other
user
ones,
and
so
there
was
discussion
of
like
well
instead
of
just
replacing
that
last
parameter,
which
is
default,
default,
resolve
or
default
load
with
next,
maybe
we
should
have
both
like
a
next
and
then
a
fourth
parameter
is
default,
and
that
way,
if
you
need
to
call
the
default
one,
you
always
can
you
can
like
kind
of
call
it
out
of
order
or
something
don't.
E
E
B
This
is
the
discussion
like
a
year
ago
so-
and
I
think
that
was
the
result
was
like
for
whatever
reason
we
decided.
That
was
a
bad
idea,
but
I
think
I
think
they're
probably
reason
specific
to
default,
why
that
was
a
bad
idea,
but
also,
I
think
there
was
desire
not
to
make
the
hook
so
complicated,
because
then
you
have
to
handle
all
these
extra
cases.
B
D
I
definitely
am
on
board
with
limiting
the
number
of
arguments
I
feel
like
after
you
get
beyond
like
three
like
you
should
reconsider.
Well,.
B
E
It
is,
I
do
not
think
number
of
options
is
necessarily
bad
for
api
data
points.
The
problem
is,
you
have
two
different
resolvers
or
hooks
that
you
chain
into
and
almost
a
hundred
percent
of
time,
when
I
was
looking
at
it.
If
you
compose
loaders,
you
never
want
to
call
the
default
one,
because
you're
gonna
break
your
composition
model
yeah.
Maybe
that's
what
it
was.
Maybe
it's
not
maybe
it's
not
just
options
specifically.
So
things
like
a
loader
that
always
wants
to
intercept
the
fs
module
is
not
possible
if
somebody
can
always
call
the
default.
B
D
Unless
the
default
loader
also
uses
those
matched
or
whatever
fs
things,.
C
Right,
the
assumption
here
is
that
the
the
the
fs
module
modification
is
done
through
the
use
of
loaders
and
not
through
something
else.
B
B
B
To
like
resolve
can
mock
like
resolve,
can
see
like
if
you
create
a
resolved
hook.
It
looks
for
a
specifier
of
fs
and
then
return
it
and
then
decides
like
oh
we're
not
going
to
return
format
built
in
we're
going
to
return
format,
module
and
then
here's
the
function
to
or
object
or
whatever
to
return
when
that's
resolved.
So
now
you
just
suddenly
replace
calls
for
fs
with
your
own
logic,
but
that
affects
like
user
code
like
the
user's
application
and
any
any
dependencies
and
node
modules
it
doesn't
affect,
like
node
internals.
D
B
I
think
we
were
talking
about
maybe
creating
a
whole
separate
type
of
hook-
that's
like
specific
to
fs
of
like
if
you
want
to
override
fs.read
file
or
something
like
that,
here's
a
different
hook
that
does
that-
and
maybe
it
even
is
used
for
node
internals,
but
that
was
like
a
whole
separate
issue,
real
unrelated
to
modules.
That's
like
fs
hooks
or
whatever
you
know,
file
system
hooks
or
whatever,
like
a
whole,
separate
feature
that
we
could
build
into
node
right.
D
But
I'm
thinking,
if
we
do
do
that,
then
if
fs
sorry
fs
if
a
default,
loader
or
you
know
whatever
default,
resolve
and
default
load
would
also
consume
those,
because
it's
interesting
that.
E
B
E
You
want
that
mock
or
user
land
library
to
entirely
subsume
all
possible
references
to
the
actual
built-in,
and
so
you
absolutely
can
never
have
the
default,
because
it
will
not
use
that
user
land
loader's
replacement
and
the
default
can
do
things
without
the
userland's
replacement.
In
fact,
it
needs
to
it
must,
but
the
userland
is
just
augmenting
the
building.
A
D
I
think
he
froze
did
he
freeze,
or
is
he
thinking
it's
frozen?
Okay?
Oh,
he
did
mention
before
we
joined
that
his
computer
has
been
restarting
all
day
so
hopefully
well
we'll
know
in
a
second,
because
won't
this
suddenly
crash.
D
B
Yeah
at
work,
I
met
someone
recently
who
found
out
that
I
work
on
node
and
he
was
like.
Oh
I've
been
monkey
patching
the
dns
module
for
10
years.
Why
doesn't
it
support
caching
like
every
project?
I've
ever
done
that
monkey
patch
dns
to
add?
Caching,
when
is
that
going
to
be
added
to
node
node
core,
and
I
was
like,
I
told
you
a
few
years.
B
Well,
maybe
that
maybe
you
can
give
me
a
better
answer
to
give
him,
but
I
told
him
a
long
story
about
how
hard
it
is
to
add
things
to
core
and
small
core
and
blah
blah
blah.
But,
like
that's
that's
my
point.
Is
that,
like
there
are
things
like
that
that,
like
you
know,
someone
wants
dns
to
behave
differently
like
like?
Maybe
it's
pandaro's
box
and
we
add
hooks
all
over
the
place,
but
but
that's
probably
better
than
monkey
patching
or
allowing
munchie
pack
monkey
patching
of
like
all
core
modules.
B
So
it's
just
something
something
to
consider
or
we
do
allow
monkey
patching
the
same
way
on
the
browser
you
can
like
monkey
patch
fetch
and
xml
http
requests
and
do
some
wild
things
once
you
once
you,
you
know
once
you
hijack
like
network
requests
from
the
browser,
so
I
don't
know
maybe
that's
an
option,
but
I
you
know
we
could
also
just
debate
this
later
like
these.
This
is
like,
I
almost
feel
like.
You
should
build
loader
hooks
first
and
then
talk
about
if
we
want
to
have
hooks
for
other
things
and
though
you
know.
C
Yeah,
so
I
mean
enabling
monkey
patching
is
something
that's
you
know,
kind
of
near
and
dear
to
the
product.
I
work
on
that
being
said,
like
loaders
is
kind
of
tangential.
C
Diagnosis
challenge
provides
pretty
much
all
the
stuff
similar
to
monkey
passion
that
will
pretty
much
ever
need
in
in
terms
of
observability
and
things
like
diagnostic
channel
or
perhaps
a
future
replacement
for
diagnostic
challenge
is
probably
going
to
be
the
answer
to
these
sorts
of
questions,
and
so
to
me,
it's
a
little
bit
tangential,
at
least
for
now.
C
D
C
Oh
interesting,
I
I
got
no
notification
that
I'm
the
host
now,
which
is
interesting,
but
we're
still
reporting.
D
C
E
So
two
different
models
as
the
only
agenda
item.
So
is
there
anything
in
particular,
we
want
to
talk
about
this
week.
It's
a
little
bit
shorter
than
our
normal
cadence
between
them.
D
I
think
nothing
in
particular,
although
I
do
like
the
idea
from
jeffrey
about
the
adjusting
the
return
to
have
that
like
secret,
well,
not
secret,
but
the
like
special
short
circuit,
rather
than
a
method
in
terms
of
not
exposing
the
default
loader,
I'm
a
little
bit
confused
because
a
few
meetings
back,
we
talked
about
potentially
exposing
that
in
the
iterative
approach,
because
I
forget
who
several
people
were
saying
that
they
needed
access
to
it
and
now
bradley.
E
And
the
iterative
approach,
it's
you
have
to
have
it.
Oh
okay,
in
the
iterative
approach
you
you
can't
make
as
many
assumptions
about
your
caller
as
you
can
in
the
recursive
approach.
You
just
note
somebody
called
you.
You
don't
have
control
over
who's
going
to
be
called
next
in
particular,
so
you
have
to
have
the
default
because
you
need
re-entrances
so
that
the
first
loader
can
do
partial
operations.
D
E
So
in
order
to
support
a
resolve
further
down
the
line,
so
say
you
have
a
loader
one
supports
zip
archives.
One
has
some
sort
of
weird
file
renaming
scheme.
They
have
to
talk
to
each
other
in
a
re-entering
way
and
to
do
so
with
recursive,
you
do
it
by
return
value
and
calling
the
other
loader
repeatedly.
Until
you
get
to
some
sort
of
agreement
with
iterative,
you
don't
have
that
level
of
control,
and
so
you
have
to
basically
have
the
first
one.
Just
called
the
default.
E
Loader
get
a
result
which
is
essentially
the
same
as
the
most
nested
recursion
layer.
So
it's
the
first
action
and
then
it
passes
it
on
to
the
next
iteration
step.
That
iteration
step
needs
to
coordinate
with
the
previous
iteration
step.
So
it
has
to
send
it
back
to
the
front
of
the
iteration
loop
and
do
it
again
until
there's
some
sort
of
match
up.
E
Why
does
it
need
to
set
it
back?
So
this
is
all
the
examples
we
have
where
you
mutate
something
about
the
result
right.
So
whenever
you
mutate
something
about
the
results,
you
have
to
send
it
back
to
the
start
of
the
iteration
loop
in
case
the
other
resolver,
for
example,
you're
in
a
zip
archive
suddenly,
because
the
first
resolver
has
decided
after
default
resolve,
we
we've
resolved
inside
of
a
zip
archive.
E
Well,
the
next
resolver
doesn't
know
how
to
deal
with
zip
archives
at
all,
and
so
it
can't
use
the
defaults
and
it
needs
to
do
some
extra
work
against
the
original
result
of
the
first
step
inside
the
zip
archive.
So,
for
example,
the
zip
archive
could
use
a
specifier
it
resolves
to
a
directory
within
a
zip
archive.
The
second
one
does
file
searching
within
the
zip
archive.
E
B
D
But
wouldn't
it
have
been
the
responsibility
of
the
zip
loader
to
return,
something
that
everybody
can
understand?
D
No,
so
it
says,
like
I
receive
a
zip
archive
and
it's
like
cool,
I
am
your
babble
stone
or
whatever
rosetta
stone
here
you
go.
This
is
what
this
means.
E
D
Okay,
I
admittedly
do
not
know
so,
let's
careful.
E
E
Know
I
feel
like
it
just
knows
how
to
resolve
it.
It
just
knows
how
to
resolve
into
that
directory.
It
doesn't
do
magic
file
searching
that's
a
different
loader
loaders
can't
do
everything
that
every
loader
ever
wants
so
like
you
could
have.
You
could
have
this
searching
loader
and
it
would
work
against
http.
For
example,
it's
built
to
work
against
urls.
It's
not
built
to
work
against
the
fs.
E
D
E
D
So
you're
for
seeing
a
situation
where
you
need
to
have
repeated
calls
so
like
I
am
sitting
above,
let's
say
I'm
on
this
fs
loader
and
I
see
oh
there's
a
zip
thing
here.
I
don't
understand
this.
Send
this
off
to
my
interpreter,
my
zip
interpreter
a
zip
interpreter
comes
back
and
it's
like
cool
go
back.
I
need
this
other
thing.
It
comes
back
and
then
it
says,
wait.
One
more
thing.
D
E
E
E
A
E
D
Loop
going,
let's
say
your
third
argument
is
restart
you
feed,
restart
whatever
you
have
and
then
kind
of
like
you
go
away
and
then
restart
jumps
back
to
the
start
of
the
loop
they
run
through
all
the
stuff.
It
eventually
gets
back
to
you
and
you're
like
cool
here's,
some
new
stuff,
restart.
E
D
D
Definitely
more
complex
than
just
a
plain
iteration,
but.
D
Situations
I
was
thinking
when,
for
instance,
you've
got
like
an
https
loader,
a
coffee
script
loader
and
a
babel
loader
https
fetches,
the
things
from
remote
that
passes
it
on
to
it
returns
a
coffeescript
file
that
coffeescript
file
goes
to
the
coffeescript
loader
coffeescript
loader
converts
it
to
javascript
turns
out
that
it
has
like
some
bleeding
edge.
Javascript.
E
Linear,
as
long
as
for
any
given
url,
there
is
no
reentrancy
and
no
multi-mapping.
It
works.
Okay.
The
moment
you
do
things
like
having
pre-compilation,
where
you
could
load
the
pre-compiled
or
optimized
form
from
byte
cache,
or
something
like
that.
Now
you
can
load
two
different
forms,
the
raw
form
or
the
pre-compiled
form.
If
you
do
something
like
file
path,
searching
that
means
for
any
given
url,
you
can
have
a
result
from
multiple,
so
you
actually
have
to
go
and
test
multiple
routes
in
your
loader.
D
Okay,
because
I'm
thinking
that's
going
to
be
most
of
the
things
no.
D
Even
if
we
expo
that's
what
I
was
talking
about
in
slack
earlier,
that
I
was
thinking
that
if
we
expose
these
utilities
that
that
would
potentially
have
a
significant
impact
on
what
the
the
loaders
themselves
need
to
do,
because
they
kind
of
do
that
work.
So
if
you're
trying
to
like,
I
don't
know,
find
a
package
json
or
find
a
ts
configure
resolve
this
extensionless
specifier,
those
things
could
handle
that
and
then
that's
those.
E
D
E
D
E
Yes,
one
more
you
you,
this
is
all
in
resolve.
We
never
exit
resolve
ever
in
this
whole
conversation
cute,
oh
okay,
https
is
resolve,
it
sees,
it
doesn't
do
anything,
and
so
it
needs
to
pass
something
to
coffeescript
and
coffeescript
could
also
have
typescript
after
it
yeah.
So
like
at
what
point,
and
how
do
you
call
the
utility
function
that
it
has
all
the
loaders
various
extensions,
properly
managed.
E
Would
receive
the
input?
Unfortunately,
it
can't
do
that
because
path
searching
has
conflicts
and
you
need
to
know
the
total
sum
of
all
extensions
in
order
to
know
if
you
can
so
a
good
example.
Let's
say
we
have
coffeescript
and
typescript
and
we
just
call
it
with
the
coffeescript
extension
searching
on
the
first
one,
and
we
only
call
it
with
the
typescript
extension
searching
on
the
second
one.
E
D
But
then,
who
does
what
so,
let's
say
I
found
both
of
these
things?
How
how
does
it
know
what
to
do
like
if
it
you've
got
the
copy
script?
Loader
and
you've
got
the
typescript
loader
and
it
says
hey.
This
could
be
either
of
these
things
like
someone
has
to
choose,
and
I
would
expect
the
coffee
script
loader
to
choose
itself
and
the
typescript
literature
to
choose
itself.
D
D
E
D
E
Work
scenario:
it
doesn't
work
in
either.
The
problem
is
the
helper
function.
Idea
like
the
helper
function
needs
the
total
of
aggregate
information
in
order
to
work,
and
so
okay
doing
it
as
early
as
possible
is
actually
really
bad
because
it
needs
to
build
up
the
aggregate
information
it
needs
as
it
goes
through.
All
the
loaders.
D
Well,
actually,
sorry,
I
I
need
to
retract
one
of
my
earlier
things
I
would
expect
the
this
helper
to.
D
I
would
expect
this
helper
to
to
do
that,
like
it
would
not
necessarily
be
looking
for
a
particular
file
extension
or
something
it
would
be
looking
for
everything
else,
that
sort
of
matches
what
it
knows.
So,
let's
say
you've
got
foo
and
then
it
says
I
found
foo
dot,
ts
and
also
food
slash
index
index.coffee.
E
So
we
don't
do
that
in
node's
core
right
now
that
is
asking
for
a
full
directory
traversal.
You
can't
be
like
match
this
pattern.
You'd
be
saying
for
any
given
resolve.
Please
read
the
entire
directory.
E
D
E
D
D
E
D
E
It's
not
just
a
million
files,
it's
also
just
you've
kind
of
taken,
something
that
was
very
selective
and
added
a
new
phase
to
it.
Timing-Wise
and
the
timing-wise
means
there's
slower,
perf
and
potential
for
race
conditions
which
file
operations
are
already
race
conditions.
So
that's
fine
perf-wise!
E
This
is
going
to
be.
People
have
to
sort
things
instead
of
it
being.
You
know.
First
found
wins
now:
you're
having
to
manually
sort
results.
E
E
E
D
It
foo
and
we're
currently
in
some
directory,
so
it
would
find
it
would
say:
oh
there
is
in
this
same
directory,
there
is
a
food.s
and
there
is
a
foo
directory
that
contains
indexed
coffee.
So
it
would.
E
E
E
E
Directory
read
list
way:
okay,.
E
So
we
haven't
designed
for
this
case
in
either
direction,
but
the
recursive
way
as
it
goes
through
instead
of
calling
the
default
loader
is
the
first
thing
it
would
go
through
the
https
loader,
the
https
loader,
wouldn't
add
any
information,
it's
nothing
relevant
to
it.
Then
it
would
go
to
the
coffee
loader,
the
coffee
loader,
when
it
passes
off
to
the
next
one
would
be
like
hey.
Do
this
resolve
also,
please
add
the
dot
coffee
extension.
E
E
D
E
E
Which
just
complicating
things
at
this
point
we're
adding
books
everywhere,
and
so
you
get
to
be
less
and
less
explicit.
You
also
get
to
a
point
where
registration
denial
becomes
hard.
So
here
you
could
have
a
like
no
typescript
loader
at
the
end
that
ensures
that
that
list,
when
it's
passed
to
the
default
never
includes
ts
or
dot
node
in
particular
dot
node
is
the
more
important
one.
You
don't
want
to
load,
c
c,
plus
plus,
so
no
matter
what
the
other
loaders
do.
E
D
D
E
So
it
the
we
don't
need
to
be
so
specific
to
iterative
versus
recursive.
The
whole
thing
is
just
about
hey.
You
need
to
aggregate
the
data
as
you
go
along
for
all
these
designs
and
trying
to
make
it
so
you
never
need
to
aggregate.
The
data
is
always
going
to
be
like
we're
going
to
add
another
hook
to
loaders,
basically
and
so
you're
going
to
say
we're
going
to
aggregate
our
data
elsewhere
in
a
different
hook.
E
E
B
Hey
sorry,
I
missed
a
big
chunk
of
this.
I
I'll
try
to
do
a
pr
that
adds
the
stuff
we
were
talking
about
about
short
circuit
to
the
recursive
design
dock
and
I
guess
jacob.
If
you
want
to
ping
us
when
the
other
dock
is
kind
of
ready
for
review,
then
we
can
start
kind
of
maybe
doing
discussion
async
of,
like
you
know
pr
reviews
and
stuff
like
that.
Maybe
we
could
talk
about
at
the
next
meeting.
B
Cool
I
the
one
last
thing
we
should
probably
talk
about
that
that
whole
import
assertions
thing
I
I
don't
know
if
I'll
be
able
to
find
the
time,
but
I
was
thinking
of
trying
to
find
the
time
to
adapt
that
pr
that
antoine
opened
to
just
do
what
we
discussed
in
the
tsc
meeting,
which
is
just
make
a
cert
required
for
import
of
json,
and
that's
it
there's
not
any
version
of
assertions
being
optional
anywhere
in
the
code
base,
whether
flagged
or
not,
they
would
just
always
be
required
for
json,
never
required
for
anything
else,
and
that
would
be
it
for
now
and
then,
if
he
wants
to
add
support
for
making
them
optional
for
jason,
that
could
be
like
a
separate
pr
that
he
opens.
B
I
suppose,
does
anyone
see
any
issues
with
that.
D
No,
the
only
issue
I
foresee
is
like
a
human
one
of
like
someone
being
unhappy
with.
E
B
Complain
that
they
insist
on
it,
but
I
mean
well,
I
mean
he
asked
the
tsc
to
get
involved
and
they
made
a
decision,
so
it's
sort
of
like
you
know.
He
went
straight
to
the
supreme
court
right
off
the
bat
and
they
didn't.
They
didn't
rule
the
way
he
wanted
and
so
he's
kind
of
stuck
with
it.
He
can't
really.
I
mean
he
can
go
back
to
them
a
second
time,
they're
going
to
say
the
same
thing.
B
So
if
anyone
you
know
blocks
the
pr
that
I
make
at
least
on
those
grounds
of
like
no,
we
want
this
other
behavior.
I
mean
they
could
block
it
for
technical
reasons
or
something
but
saying
just
saying:
no,
we
want
to
be
optional.
I
think
the
tse
is
just
gonna
swat
him
down.
Okay,
because
the
tsc
one
like
miles
in
particular
wants
this
landed
and
shift.
So
I
think
he's
gonna.
B
This
is
the
clearest
way
forward
for
that
and
they
could
open
the
pr
for
the
other,
and
I
think
it's
going
to
just
sit
there
indefinitely,
because
I
mean
I'm
opposed
to
it.
I
think
miles
as
opposed
to
it.
You
know-
maybe
you
and
bradley
I
don't
know
but
like
there
certainly
isn't
consensus
to
land
on
it
and
it
would
take
a
vote
of
the
tsc
to
override
the
lack
of
consensus,
and
I
don't,
I
think
the
tsc
is
not
in
any
hurry
to
do
so.
B
B
I
mean
it's
more
of
a
question
of.
Do
I
have
the
time
I
mean
if
you
want
to
tackle
it
by
all
means,
I'm
not
sure
when
or
if
I'll
have
the
time
for
it.
So
that's
that's
the
big
question,
but
if
you're
excited
to
do
it
by
all
means,
go
for
it
just
let
me
know
so
we
don't
both
work
on
it,
but
but
yeah.
D
Yeah,
basically,
I
guess
it's
a
matter
of
priority
of
because
I
yeah.
B
D
B
The
chaining
is
probably
more
important,
but
if
you
get
blocked
on
that
like,
if
you
you
know,
are
waiting
on
design
questions
or
something
and
you
wanna
do
do
other
work,
then
this
is
another
option
but
but
yeah
whatever.
D
Whatever
you
think,
okay
cool
yeah-
and
I
guess
there's
also
the
option
of
like
tagging
you
I
don't
know
how
big
this
request
is.
Gonna,
be.
B
I
think
it's
small
like
his
pill
request
that
adds
it
is
optional
with
the
flag.
Isn't
all
that
large
like
it's
something
like
25
files,
but
like
half
of
them
are
tests
a
big,
a
big
chunk
of
it
is
documentation,
there's
not
that
much
actual
code
in
there.
The
biggest
chunk
that
like
actually
needs
to
be
rewritten
is
the
there's
a
bunch
of
logic
that
he
adds
to
esm.
Loader,
that's
like,
instead
of
like
checking.
If
job
is
undefined,
he
checks
a
job
is
like
falsely
and
then
does
a
bunch
of
things.
Yeah.
B
Yeah-
and
it
doesn't
look
like
good
code
like
I
don't
like,
he
adds
a
bunch
of
weak
maps
for
tracking
these
type
assertions
and
stuff,
and
I
feel
like
none
of
this
is
necessary,
like
we
should
just
pass
through
the
assertions
as
another
bit
of
metadata
about
the
import
statement.
Just
like
the
specifier
and
check
it
and
move
on,
I
don't
it
doesn't
need
to
become
part
of
the.
B
Right
but
that's
his
pr
that
would
be
like
you
know
him
rebasing,
on
top
of
my
pr,
would
be
adding
the
weak
maps
to
add
it
to
the
key
and
blah
blah
blah.
Like
you're
saying
like
I
was
trying
to
not
add
that
complexity,
the
loader
like
until
we
needed
it
like.
If
and
when
we
ever
have
optional
assertions.
B
B
D
Question
about
well
actually
we're
getting
a
little
bit
over
time.
Maybe
we
can
move
to
another
one
sticking
it
into
context.
That
sounds
like
a
good
idea,
but
how
would
we
like
if
a
loader
is
getting
involved
here?
The
loader
must
respect
the
assertion.
Doesn't
it
must
it.
B
E
E
E
B
E
B
B
Right,
so
that's
what
I'm
saying
like.
If
the
loader
returns
format
json,
then
it
you
know
it
needs
to
be.
It
needs
to
have
the
import
assertion
for
json,
or
else
it'll
fail,
but
okay,
yes,
but
like
if
the,
if
there's
an
import
statement,
that's
like
import
data
from
data.json,
assert
type,
json
say:
that's
your
import
statement
and
our
user
letter
changes
that
to
like
import,
foo.js
and
then
returns
like
type
module
source
and
then
javascript.
B
A
E
B
Well,
whatever
you
advise
is
fine
with
me
bradley,
I'm
kind
of
more
of
the
opinion
that,
like
you
know,
the
whole
point
of
loader
hooks
is
to
let
people
override
things
so
like
let
them
override
whatever
they
want,
and
you
know
it
needs
to
get
cl.
It
needs
to
be
cleaned
by
the
time.
Node
gets
it
and
starts
to
like
create
the
module
record
and
so
on
and
register
with
v8.
B
But
whatever
happens
before
that
point,
like
is
kind
of
like
whatever
you
know,
because,
because
someone's
going
to
want
to
write
a
loader
that
makes
assertion
this
import
statements
of
json
work
so
like
and
that's
reasonable,
because
there's
lots
and
lots
of
code
out
there.
That's
like
you
know,
require
package.json
or
import
package.json,
and
so
we
want
people
to
be
able
to
write
a
loader
that
makes
those
make
that
interruptable
no.
D
E
The
assertion
is
always
incorporated
into
the
cash
keeper
the
spec
now.
Thank
you.
I
don't
like
that.
I
fought
against
that,
but
the
assertion
being
in
the
cache
key
means
that
when
you
do
an
import
with
and
without
the
assertion,
you
get
two
different
results
and
we
have
to
manually
redirect
the
job
to
be
the
proper
one.
Unfortunately,
even
beyond
this,
because
of
http
timing
and
remote
code
loading.
So
due
to
this,
that
means.
Basically,
if
you
have
these
two
different
forms.
E
At
the
same
time,
you
have
to
introduce
some
sort
of
system
to
determine
who
wins
and
if
the
win
is
coalesced,
as
in
json
and
with
the
type
and
without
the
type
point
to
the
same
module
or
if
they
point
to
two
different
modules.
The
default
according
to
the
spec
is
two
different
modules,
so
you
have
to
have
a
way
to
coalesce,
that's
one.
E
E
If
we
don't,
we
have
to
introduce
a
coalesce
operation
and
coalesce
operations
are
complicated
and
I
don't
want
to
think
about
them.
Somebody
else
wants
to
come
with
their
user
loader
demands
and
give
me
a
question.
B
I'm
going
to
do
the
most
simple
version
as
part
of
my
pr
just
to
get
it
shipped.
You
know
for
public
cases
and
then
it's
like
we'll
have
to
figure
out
what
to
do
with
loaders.
If
it's
passed
into
the
resolve
hook
and
is
it
overrideable?
Is
it
something
that
should
be
returned
by
one
of
the
hooks
like
that's
those
are
all
questions
we
need
to
resolve,
but
maybe
maybe
maybe
they
don't
need
to
be
resolved
all
in
one
pr
with
that,
just
enables
it,
for
you
know
the
non-loader
use
case
like
that.
D
If
it
doesn't
do
we
run
the
risk
of
like
borking
loaders
so
like
making
it
so
that
they
can't
function
as
they
need
to
to
pass
the.
B
D
Would
be
the
word
right
right,
but
the
loader
needs
to
be
aware
that
that
exists
and
like
that,
if
the
assertion
was
set
so
that
it
needs
to
respect
it.
Well,
exactly
can't
just
be
like.
D
I'm
just
saying
like
in
terms
of
limiting
the
scope
of
load,
I
think
I'm
just
calling
out
that
we
need
to
at
least
expose
to
the
loaders
the
information
that
it
needs
to
not
run
afoul
of
something
rather
than
like
kind
of
just
chunking
it
into
the
darkness
and
saying
like
good
luck.
Yeah.
B
D
I
think
it
would
be
reasonable
for
that
to
be
step
two.
If
that's
the
case,
then
that's
the
case.
I.
B
B
Well,
I
mean
that
could
be
the
solution.
It's
like
you,
the.
If
users
really
want
to
be
able
to
say
right
without
the
import
assertions,
then
some
kind
of
transpilation
loader
needs
to
add
it
because
like
they
would
never
have
a
initial
entry
for
a
new
json
file.
So
whatever
the
initial
entry
point
is
you
know
index.js
or
index.coffee
or
whatever
that
initial
flash
say
it's
index.copy
right
and
say
there
are
no
assertions
in
there
when
index.copy
is
transpiled
into
javascript.
B
That
translation
would
need
to
add
the
assertions
and
then
only
and
then
it's
that
transpilation
result,
then
that
gets
parsed
to
look
for
more
import
statements
to
follow,
and
then
those
import
statements
would
have
the
assertion
as
node
wants
them
to
and
so
on
and
so
forth.
So
that
could
be
how
users
do
it
is
like
they
just
transpile
to
make
it
a
you
know
a
proper
json
import
before
node
reads
it.
Essentially,
you
know
yeah
almost
like
a
build
step,
yeah
yeah,
so
that
should
always
be
possible.
D
B
D
B
Yeah
I'll,
hopefully
I'll
have
the
the
jason
assert
pr
or
if
you
want
to
do
it
before
the
next
meeting,
which
I
think
is
in
two
weeks
and
then
maybe
that
can
put
that
whole
question
to
bed
and
we
don't
have
to
talk
about
it
in
a
meeting.
B
I
hope
and
then
then
hopefully,
maybe
the
next
meeting
can
be
like
now,
we'll
have
more
finished
design
docs
for
the
two
proposals
and
we
can
like
run
them
by
people
and
get
feedback,
although
I
could
also,
I
would
love
to
just
get
them
merged
in,
and
you
know
if
you
have
the
time
to
start
implementing
one
of
them
before
two
weeks.
D
Okay,
cool
yeah.
I
definitely
if
you
want
to
have
the
json
stuff
implemented
by
next
meeting.
I
would
not
have
time
to
do
that,
but
getting
the
docs
and
stuff
updated
yes,
and
possibly
starting
on
an
implementation
of
one
of
them.
Yes,.