►
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
right,
we
are
live
on
youtube.
It
is
the
october
12
2021
meeting
of
the
loaders
team,
and
the
only
item
on
the
agenda
today
is
antoine's
pr
about
import
assertions
specifically
for
jason,
but
potentially
for
all
sorts
of
things.
So
antoine
I
wanna
hand
it
off
to
you,
and
I
think
everyone
on
the
team
knows
what
this
pr
is.
So
maybe
I
guess
what
are
the?
What
are
the
questions
that
would
be
useful
to
resolve?
While
we
have
everyone
together.
B
So,
let's
see
so
we
we
have,
of
course,
a
little
discussion
maybe
to
to
have
on
how
we
can
implement
the
cash.
So
either
we
find
a
way
around
having
to
have
the
importer
session
part
of
the
cache
key
or
how,
if
we
have
to
make
it
part
of
the
cache
key,
how
we?
How
do
we
do
it?
I
think
that's
the
first
big
technical.
B
Discussion
we
need
to
have
and
other
than
that,
what
would
be
the
the
api
with
regards
to
loaders,
like
would
loaders
will
have
access
to
importer
sessions
and,
if
so,
which
loader
hooks
and
how
could
they
do
it?
So
we
we
started.
I've
opened
an
issue
to
discuss
that,
so
it's
under
loaders
repo.
What's
the
number
again,
you
wanna
share
the
link
to
that
yeah.
B
And
jeffrey
has
started
working
on
an
implementation
of
the
of
one
or
well
one
of
the
possible
implementation.
So
I
think
that's
that
would
be
no
it's
not
on
the
table.
So
I
need
to
update
the
table.
Mr
freeze
implementation.
A
Well,
how
to
how
to
handle
it
within
loader
hooks
is
very
much,
I'm
not
sure
what
makes
the
most
sense.
So
we
should.
We
should
talk
about
that
while
we
have
jacob
and
everyone,
but
I
think,
like
maybe
in
terms
of
what's
the
best
use
of
miles
this
time
while
he's
here,
I
think
so.
A
I
I
pushed
some
code
last
night.
I
didn't
quite
finish
everything
I
wanted
to
do,
but
I
want
to
just
push
what
I
had
up
before
this
meeting.
I
basically
like
on
that
on
here.
I
can
put
the
link
on
that
pr.
A
The
last
time
I
spoke
to
antoine,
I
had
like
put
a
comment
summarizing
where
yeah
that
one.
So
if
you
look
at
my
last
like
meaningful
comment
on
there,
not
like
replying
to
chargos,
but
the
the
last
comment
that
I
that
wasn't
in
a
reply
to
a
pr
review,
I
put
like
a
list
of
four
to
do.
Items
and
I've
been
working
on
just
more
antoine
was
gracious
enough
to.
A
Let
me
just
just
commit
right
to
the
same
branch,
so
I've
been
working
on
adding
additional
commits
so
that
he
could
see
what
I've
done
versus
what
he
did
to
try
to
implement
those
four
things-
and
I
I'm
very
close
to
finishing
all
four
the
last
bit-
is
the
thing
that
he
was
talking
about
of
like
do.
We
have
this
as
part
of
the
cash
key
and,
if
not
well,
if
so,
how
do
we
handle
that?
If
not?
How
do
we
handle
that?
A
Basically,
I
wanted
to
try
to
keep
it
if
possible,
not
as
the
cat,
not
as
part
of
the
cash
key,
and
I
think
I
know
I
I
this
morning.
I
think
I
came
up
with
a
way
to
do
that,
actually
to
try
to
implement
it
and
see
if
I'm
right,
but
basically
that
that
would
preserve
kind
of
the
way
loaders
work
where
it
all
kind
of
resolves
around
the
you,
the
resolved
url
like
resolve
the
resolve
hook,
has
to
give
a
url.
A
That's
the
hinge
point
of
the
load
hook,
which
then
returns
the
the
source.
If
we
have
the
assertions
as
part
of
the
cache
key,
I
would
think
that
that
then
means
that
that
resolve
needs
to
return
both
and
then
load
needs
to
take.
A
Take
both,
and
you
know,
treat
that
as
a
combined
key
to
return
something
and
that
just
feels
like
a
lot
of
complexity,
especially
if
we
want
the
loaders
to
potentially
mess
with
the
assertions
like
if
we
want
to
write
a
loader
that
ignores
the
assertions
or
something
like
that,
then
how
does
that
gel
with
the
assertion
is
part
of
the
key?
You
know
what
I
mean,
so
that's
why
I
was.
I
was
going
to
try
to
keep
it
out
and
and
maybe
I'll
fail,
but
I
think
I
think
it's
doable.
A
So
I
guess
the
question
is:
let's
assume
it's
possible
to
do
it
either
way
it
do.
We
want
the
assertion
to
be
part
of
the
key
for
some
reason
and
if
so,
what?
Why
would.
B
B
So
we
we
are
between
the
the
resolve
and
the
load.
There's
uncertainty
and
that's
why,
on
my
pr,
I
I've
made
it
part
of
the
gheshke
basically
and.
C
A
No
default
result,
doesn't
I
don't
think
returning
format
so
right,
we
could
default
like
the
overwhelmingly
common
case,
where
there's
no
user
loaders
involved.
We
don't
know
the
format
until
after
load
completes.
C
Right,
we
could
update
it
to
that.
I
think.
Oh
no!
You
couldn't
because
it
needs
to
have,
for
instance,
if
you're
losing
it
over
https.
You
would
need
to
have
the
actual
result
of
the
thing
to
know
right.
D
I
think
that's
why
we
put
it
there
in
the
first
place,
so
I
guess
like
if
we
step
back
from
the
cash
key
itself
and
just
think
about
like
loaders
in
the
information
they're
given,
let's
say
I'm
writing
I'm
an
apm
and
I'm
writing
a
custom
loader
to
completely
override
nodes
loader
altogether.
D
It
seems
to
me
jeff
that,
like
knowing
the
values
of
what's
in
the
assertions,
independent
of
whether
or
not
it's
served
as
part
of
the
cash
key
will
likely
be
necessary,
it's
something
people
may
want
to
configure
if
they
want
to
write.
I-
and
I
have
I
have
mixed
feelings
about
this,
but
let's
say
people
want
to
write
their
own
custom
assertions
that
that
they
can
extend
or
use.
D
I
know,
for
example,
I
can't
remember
if
it
was
babble
or
react,
but
like
a
couple,
different
folks
were
definitely
interested
when
we
were
first
kind
of
specking
it
that,
like
for
some
of
these
platforms,
maybe
even
touch
with
that
like
extend
the
language
and
then
run
through
a
transpiler,
or
something
like
that
that
they
may
want
to
write
like
custom
assertions
that
are
part
of
their
own
platform
and
so
independent
of
the
implementation,
where
it
sounds
like
cash
fees
and
implementation
concern.
D
I
do
think
that
loaders
will
likely
need
to
be
aware
of.
Are
there
assertions
and
what
the
assertions
are
as
part
of
like
the
internals
of
the
loader.
If
we
want
to
be
able
to
support
people,
writing
custom
assertions,
extensions
that
don't
need
to
be
like
pre-processed
or
transpiled
in
order
to
work.
A
Yeah,
that's
that's
already
in
the
pr.
I
think
we're
in
agreement
on
that
that
it's
just
an
additional
right.
Now,
it's
just
an
additional
thing
on
the
context,
along
with
conditions
so
and
it's
currently
getting
passed
into
both
resolve
and
load
because,
depending
on
like
where
you're
getting
the
stuff
from
you
might
know
in
one
or
the
other,
like
what
the
what
to
do.
A
Based
on
the
assertion,
as
I
was
working
on
this,
it
did
occur
to
me
that,
like
so
that
the
basically
like,
if
it,
if
it's
if
it
so,
if
it's
part
of
the
cache
key,
that's
really
like
a
technical
way
of
saying.
A
Do
we
want
separate
module,
cache
entries
for
say
the
same
specifier,
but
with
different
assertions
either
either
it
has
an
assertion
or
it
doesn't
or
there's
two
import
statements.
One
says
you
know
a
certain
type
json
who
says
absurd
type.
A
I
don't
know
css
or
whatever
more
likely
it
would
just
be
like
one
has
insertion
one
doesn't,
but
if
they're,
if
there
are
both
and
they
both
resolve
successfully
like
it's
not
going
to
throw
an
error
on
one
of
them
and
that
currently,
that
would
only
happen
if
you
write
a
custom
loader
that,
like
it
just
ignores
the
validation.
A
You
know
what
what
should
the
intended
behavior
be
like.
Would
that
should
there
be
two
separate
records
in
the
module
cache
and
then
we
have
like
another
version
of
the
the
dual
package
hazard
or
should
there?
You
know
if
there's
only
one
key
that
ignores
the
assertion,
then
it's
like
it's
kind
of
a
race
condition
of
like
which
one
happened
to
get
put
into
the
module
cache
first
and
then
it's
like
it's
on
them.
It's
on
the
loader
author,
who
ignored
the
validation.
To
like
be
aware
of
that
possibility.
B
So
from
what
I
understand
from
the
the
spec
same,
specifier
has
to
return
the
same
module
now,
maybe
we
want
our
users
to
be
able
to
write
loaders
that
do
not
respect
the
spec
but
wanted
to
point
it
out.
B
D
Yes,
that's
what
I
understand
from
the
respect
that
maybe
I
would
have
to
double
check
on
the
exact
language
in
the
spec,
because
that's
one
of
the
things
that
like
would
change
back
and
forth
and
we
could
bring
in
like
for
clarity.
I
was
more
involved
in
this
deck
in
the
early
stages,
when
we
were
just
trying
to
get
like
consensus
on
we'll
even
do
this
and
then
when
it
got
more
into
like
the
internals.
D
Other
people
were
writing
the
spec
language,
but
I
could
imagine
I
believe
that,
like
we
don't
need
to
throw
on
unknown
assertions.
So
I
think
that
like,
if
I
recall
correctly,
if
there's
an
assertion
that
is
unrecognized,
it
can
be
ignored
because
we
didn't
want
to
make
like
an
infinite
list
of
all
possible
assertions.
B
D
And-
and
I
also
believe-
but
I
could
be
wrong
on
this-
that
in
general
platforms
could
support
additional
assertions
and
those
aren't
necessarily
going
to
be
consistent
between
platforms.
D
There
was
concerns
initially
when
we
talked
about
stuff
like
this,
for
things
like
resource
integrity,
so
tc39
myself
in
particular,
don't
believe
that
import
assertions
are
where
resource
integrity
should
be
should
be
checked
a
because
then
that
makes
cycles
impossible,
but
b
it's
like
very,
very
thrashy,
because
the
second
you
actually
change
like
one
import
assertions
sha
then
it
virally
goes
up
the
whole
tree
and
you
need
to
like
kind
of
stamp
that
so
maybe
it
could
be
done
by
tooling
just
before
shipping
something
out
but
like
it's
very
flip
gunny
to
put
it
lightly.
D
But
I
could
see
a
world
where,
like
yes,
we
may
say
for
our
platform
that
the
json
assertion
is
mandatory,
but
there
may
also
be
an
additional
assertion
that
could
be
put
there
that
verifies
the
type
of
json
or
something
like
that
that,
like
it,
has
certain
qualities
to
it.
That
could
be
ignored
in
most
cases,
but
a
tool
may
pick
up
on
you
and
utilize.
D
It
for
something
else,
but
if
that
other
assertion
is
arguably
optional
and
ignored,
if
it's
written
in
one
place
and
not
the
other
place,
I
don't
believe
that
it's
reasonable
to
say
that
we
have
two
instances
of
the
same
thing,
because
people
are
using
a
specifier
to
refer
to
to
an
instance
of
something
that
doesn't
mean
something
as
well
in
the
platform
as
far
as
singletons
are
concerned,
and
I'm
not
sure
that
an
optional
additional
assertion
should
then
in
turn
mean
like.
D
I
want
an
instance
of
this
thing
versus
like
at
this
import
site.
There's
additional
information,
I'd
like
to
check
about
it.
Like
I
don't
know
I
feel
like
we
could
argue
about
that.
I
also
think
that
it's
possible
that
if
we,
if
we
are
having
trouble
interpreting
the
the
spec
on
this,
if
we
feel
like
something
is
ambiguous.
If
we
feel
like
as
a
platform,
it
would
be
better
for
us
to
have
something
to
be
explicit
here.
D
D
We
could
also
ask
for
non-normative
text,
so
that
would
be
like
not
spec
text,
but
just
like
kind
of
like
an
editorialized
recommendation
that
specifies
this,
I
think,
would
be
interesting
also
to
see
like
how
does
chrome
implement
this
behavior
versus
how
does
geno
implement
this
behavior,
because
there's
also
something
to
be
said
about
like
kind
of
consistency
across
platforms
for
this
one
as
well,
which
I
guess
is
maybe
hard
to
even
test
if
they
don't
all
like
support
these
different
forms
and
the
last
bit
of
tangential
thing
they'll
say
is
like
this
is
arguably
a
good
reason
to
enforce
for
now.
B
B
C
I
was
going
to
say:
if
you
have
multiple
assertions,
is
it
possible
for
them
to
both
be
like
both
be
okay
or
wouldn't
it
be
mutually
exclusive,
like
only
one
of
them
can
be
accurate
if
you,
if
it's
present,
so
the
only
real
cases,
are
an
assertion
that
passes
and
the
absence
of
an
assertion
which
might
resolve
to
be
the
same
thing.
C
B
Know
which
one
it's
going
to
be
so
joffrey
pasted
the
test
case.
A
This
is
the
one
that's
currently
failing
on
my
branch
and
it
has
to
do
with
this
question.
So
I
I
ran
the
equivalent
of
this
in
a
browser
in
chrome.
A
I
ran
it
using
using
json,
so
the
the
whether
it's
like
as
in
the
first
one,
should
pass
and
the
second
one
should
throw
because
it
actually
is
json
versus
this
is
like
javascript.
So
it's
the
inverse,
but
the
same
is
the
same
thing
and
I
was
like
so
I
was
just
like
well.
What
do
browsers
do
for
this?
Do
they
you
know,
do
they
both
pass
both
throw?
A
A
You
know
if
the
first
one
resolved
successfully
with
the
assertion
and
the
second
one
came
later
and
it
didn't
have
the
assertion:
does
it
also
resolve
successfully,
because
that
key
is
already
in
the
module,
cache
and
basically
browsers,
basically
behave
as
if
there's
no
cash?
I
mean
I'm
sure
they
must
have
a
cash,
but
from
all
the
tests
that
I've
run
like
the
one
without
the
assertion
for
jason
always
throws
no
matter
what
order
it's
in.
A
B
How,
how
would
you
do
it
if
assertion
type
is
not
part
of
the
cash
key.
B
C
B
Yeah
yeah,
but
the
the
thing
is
if,
if
the
first
import
that
fixture
juror
slash
mt.js
results,
so
it's
now
part
of
the
the
cache
this
url
is
linking
to
the
module
job.
But
it's
not
going
to
check
its
assertion
until
the
the
load
hooks
results.
B
C
Think
we
should
not
I'll
really
like
support
that
that's
kind
of
like
a
if
you
get
lucky
and
I
think
programming
should
not
be
if
you
get
lucky
crazy.
A
Yeah
that
so
this
is
what
I
was
getting
at,
regardless
of
how
we
handle
this.
That's
the
problem,
I'm
trying
to
figure
out.
I
think
I
have
an
idea,
but
I
don't
want
to
get
into
that
here,
because
I
don't
think
that
my
idea
may
very
well
not
work.
I
don't
need
your
feedback
on
it
if
it
doesn't
work
and
then
I
find
another
solution,
but
what
what
this
is
making
me.
A
Think,
though,
is
that
I
think
we
just
don't
want
race
conditions
like
we
don't
want
the
possibility
of
race
conditions
like
period,
because
then
we
start
to
get
all
sorts
of
complexity
and
and
code
just
doesn't
run
reliably
like
as
you're
developing
one
app.
If
you
move
files
around
then
or
move
the
order
of
the
import
statements
around
it
behaves
differently,
there's
definitely
no
guarantee
that
it
behaves
the
same
way
on
a
different
platform
like
browsers
or
denim.
A
So
the
thing
is,
I'm
thinking
is
like
if
we
agree
that
we
want
to
avoid
race
conditions
where
the
order
in
which
they're
resolved
influences
whether
or
not
successive
ones
get
resolved,
then
I
think
we
then
they
can't,
then
the
assertions
can
never
be
optional
like
it.
It
has
to
always
be
present
for
jason
and
it
can
never
be
present
for
javascript
and
that
just
can't
change
and
that
might
as
well
be
part
of
the
spec.
A
Otherwise,
if
it
becomes
optional
like
if
we
allow,
you
know,
import
a
cert
type
module
as
an
optional
assertion
for
javascript
in
the
future,
then
then,
all
of
a
sudden,
this
race
condition
thing
applies
for
regular
javascript
and
like
and
there's
no
easy
way
to
solve
that
you
know
like
we
could
have
them
be
separate
entries
in
the
cache,
but
then
that
violates
the
other
spec,
where
specifier
needs
to
return.
The
thing.
D
Actually,
I
think,
I
think
jeff
that's
a
great
thing
to
build
off
of
there
and
have
to
drop
in
a
moment.
Apologies,
but
let's
say
we
as
a
platform
wanted
to
support
type
module
as
an
input
assertion
which,
in
theory,
is
something
that
we
could
do.
That
could
allow
us
to
have
more
flexibility
around
the
js
and
js
stuff
if
we
should
there's
a
whole
other
thing,
I'm
plenty.
D
But
if
we
did
that,
I
would
argue
that
that
type
module
would
be
not
an
enforced
assertion.
It
would
be
an
optional
assertion
and
I
would
not
if
I
import
lodash,
and
I
assert
that
it's
whatever
it
is.
I
would
not
want
two
instances
of
it.
I
would
either
want
like
one
instance
between
all
those
import
sites
or
if
it's
not
actually
returning
the
type
that
I've
asked
for
it
throats.
D
But
my
expectation
would
not
be
that
when
I
import
low
dash
and
then
again
import
low
dash
type
module
that
I
get
two
completely
different
instances
of
it,
which
that
in
turn
seems
to
push
back
against
the
cash
viewpoint,
because
if
the
type
modules
was
part
of
the
cash
key,
then
we
would
be
getting
like
two
different,
two
different
entries.
It's
literally
the
dual
package
hazard
again.
A
D
E
B
D
What
exactly
I've
got?
I've
got
a
drop,
but
I
just
wanted
to
drop
one
more
thing
in
here
just
for
y'all
to
think
about
in
the
term
of
loaders.
I
did
not
realize
that
we
actually
specified
a
function
called
host,
get
support,
supported
import
assertions
which,
in
turn
anything
that's
not
part
of
that
host
supported
list
is
ignored
when
going
through
the
assertions.
D
So
if
we
did
want
to
allow
people
to
do
like
custom
assertions
at
a
loader
level,
we're
going
to
need
to
figure
out
a
way
to
allow
people
to
extend
this
list
that
gets
returned
and
that
may
have
to
be
like
a
runtime
option
or
something
more
complex.
A
B
B
Assertions
so
type
is
the
only
entry
currently
yeah.
If
you
wanted
another
assertion
which
is
not
typed.
D
A
A
That
could
be
a
future
edition.
I
would
think
yeah
all
right.
I
really
got
to
go,
see
y'all.
Thank
you
see
ya,
but
anyway.
The
reason
I
wanted
to
bring
this
up
antoine
was
like
it
feels
I
mean
I
want
to
get
to
the
end
of
this
pr
and
see
and
see
what
I
was
planning
to
do
as
a
way
to
handle.
This
was
like
the
code.
Right
now
is,
like
you
know,
in
get
module
job.
A
It's
like
get
the
url
for
this
specifier
parent
url
assertions
with
that
url
see
if
it's
in
the
module
cache,
if
so
return
it
and
it
might
be
returning
it
and
then
and
then,
and
what
it's
returning
is
an
object
with
like
six
properties
and
one
of
those
is
like
module
promise
which
may
not,
which
may
still
be
pending,
and
until
that
promise
resolves.
A
We
don't
know
if
the
assertion
has
been
valid
is
valid
or
not
like
it
might
it
may
not.
It
may
yet
throw
when
that
promise
resolves,
but
yet
we've
already
returned
it,
which
is
the
problem.
So
what
I
was
thinking
was
there's
already
like
six
properties
in
that
model.
Job
objects
like
whether
you
know
inspect
break
was
set
and
other
things,
so
I
think
one
of
those
properties
could
just
be
the
assertions
object
for
could
be
when
that
module
job
was
created,
and
then
it's
exactly.
A
C
A
So
here's
here's!
What
I'm
thinking
is
that
if
you,
if
you
set
it
to
undefined
again
as
if
you
hadn't
found
it
then
what's
going
to
happen,
is
this
this
newer
one
is
going
to
eventually
replace
the
one
that
was
already
there
yeah.
B
A
Mean
basically,
you
have
to
you.
What
you
have
to
do
in
the
end
is
make
sure
this
is
what
I'm.
This
is
how
I'm
not
sure
how
to
implement
this.
It's
like
what
I
was
thinking
was
like
somehow
make
sure
that
what
eventually
gets
added
to
the
module
cache
is
the
is
the
module
job
for
this
specific,
the
model
job
of
the
url.
A
A
B
I
feel
like,
though,
the
lord
hook
could,
you
know,
be
a
bit
tricky
and
returns
different
format
for
the
same
url.
So
if
the.
A
First
chase
reloaders
could,
with
this
like,
they
could
do
whatever
they
want
and
like.
I
think
that
this
is
this
is
a
real
possibility
of
user
loaders,
creating
all
sorts
of
race
conditions
if
they
return
a
different
format
for
the
same
url,
multiple
times
or
a
different.
You
know
different
source
text.
You
know
like
user,
it's
on
kind
of
loader
authors
to
follow
the
spec.
If
they
want
to
you
know,
and
they
can
get
unexpected
results
if
they
don't.
But
oh
brad
this
year,.
A
B
The
the
issue
I
think
is
when
I
will
implement
a
loader
to
add
a
support
for
a
sessionless
json.
It's
it's
gonna
behave
badly
like
there's
gonna,
be
too
much
record
for
the
same
json
specifier,
which
is
not
great,
but
if
we
decide
we
don't
care
about
it.
I
guess
that's
fine.
A
A
B
B
E
To
be
clear,
it's
not
specifically
assertionless
loaders,
it's
blocking
anything
where
they
use
the
same
url
and
have
two
different
routes
through
the
module
cache,
whether
you
do
it
by
a
property
on
the
module
job
or
in
the
cache
key,
so
it'll
always
race,
and
you
always
need
to
create
a
resolution
kind
for
those
two.
The
resolution
that
we
did
in
your
pr
antoine
was
to
coalesce
eagerly
before
we
do
anything
and
that
works
fine,
but
it's
something
you
have
to
expose.
E
If
we
want
for
user
loaders
to
be
able
to
replicate
the
basic
mechanics
of
web
loaders,
node
loader
et
cetera,
we
have
to
figure
out
what
those
cache
operations
are
and
then
define
them
out
and
how
to
get
a
user
landlord
to
do
it.
B
A
I
mean
the
other
alternatives
I
was
thinking
about
were,
like
you
know,
before
you
put
it,
don't
put
it
into
the
module
cache
until
it's
resolved.
That
way,
you
know
whether
it
got
validated
or
not.
So
that
way
it's
like,
then
you
can
trust
that
if
something's
in
the
model
cache
it
can
be
used,
it's
not
potentially
going
to
blow
up
on
you
so.
B
The
module
cache
you
have
to
put
it
in
the
module
cache
and
I
think
that's
what
the
brothers
are
doing.
They
they
have
a
different
question
tree
depending
if
there's
an
assertion
or
not,
which
would
be
exactly
like.
I
think
it
would
be
the
same
as
what
you
just
suggested.
A
To
like,
if,
if
they're
never
like,
I
think
the
thing
is
like
if
they're
never
optional
like
right
now,
assertions
are
never
optional
in
gravity's
right
say
we
say
we
behave
that
way
the
same
then
it
doesn't
matter
if
there
are
two
entries
for
file.json
one
with
the
assertion
one
without
because
the
the
one
without
could
never
be
used.
You
know
what
I
mean
it
would
be
put
in
the
in
the
cache
and
then
it
would
just
never
get
pulled
out
of
the
cache,
because
you
know
the
browser
would
have
thrown
before
ever.
E
D
E
B
E
B
E
Request
is
cached
at
that
point
and
it
is
actually
saved
in
the
module
map
in
the
browser.
Spec,
yes
and
then,
after
all,
the
loading
occurs
at
the
call
site
at
the
consumer
of
the
module
job.
The
consumer
checks
the
assertion,
so
the
module
map
is
untouched,
the
consumer
checks
and
fails
there.
That's
the
only
thing
that
happens:
it
doesn't
delete,
it
doesn't
do
any
of
that
and
so
the
next
time
it
goes
with
the
form.
With
the
assertion
the
http
cache
is
already
in
place.
They
don't
hit
it.
E
E
C
Talking
about
earlier,
where,
if
you
include
it
like
it,
just
goes
and
fetches
whatever
the
result
the
specifier
settles
to
it
goes
and
gets
that
and
then,
when
you
go
to
pull
it
out,
if
there
is
an
assertion
and
it
matches
good
go,
and
it
sounds
like
that.
This
is
what
it's
doing.
If
there's
an
assertion,
it's
good
to
go,
if
there's
not
an
assertion
fail,
but
the
the
thing
that's
in
the
cache
is
still
the
same.
It
just
either
refused
to
give
it
to
you
or
give
gave
it
to
you.
C
E
E
C
Yeah
but
the
the
resolve
chain
will
have
settled,
so
we,
I
think,
would
know
ahead
of
time
that
we
have
this
say
for
specifier
a.
There
are
n
number
of
assertions,
so
we
would
know
all
of
those
assertions
ahead
of
time
right.
E
E
E
F
C
Before
I
forget
so,
let's
say:
we've
done
all
the
static
stuff
and
then
we
have
something
dynamic.
That
comes
later.
We
will
still
have
the
original
cache
and
all
the
various
information
that
we
have
collected.
So
the
specifier
will
have
settled
to
something
and
we
will
have
some
kind
of
assertion
list
of
stuff
and
then
the
dynamic
one
comes
later
and
it
let's
say,
resolves
to
the
same
specifier
url.
If
there
is
a
new.
C
Well
sure,
then
we
have,
but
I
think
it's
effectively
the
same,
we'll
have
some
less
thing
or
we
won't
and
then,
as
it
gets
in,
like
the
dynamic
imports
are
themselves
like
that's
the
nature
of
the
beast's
race.
So
you
stick
your
stuff
in
it
goes
and
fetches
something
and
if
they
settle
to
the
same
url,
you
just
get
the
same
fetch
and
I
think
that
is
they
would
have
resolved
to
the
same
thing
anyway,
like
what
they
have
gone
out
and
grabbed.
C
And
then,
as
the
dynamic,
the
two
dynamic
things
add
their
assertions.
They
just
get
added
to
the
list
and
then
they
continue
to
when
it
goes
to
pull
it
out,
pass
or
fail,
and
then
you
either
get
it
or
you
don't.
C
E
C
When
you're
yeah,
when
you're
retrieving
it
so
yeah,
I
guess
after
the
load
hook,
so
it's
gone.
It
goes
to
the
cache
cache
says.
I
have
something
give
me
the
password
and
the
assertion
is
effectively
this
password
by
android
and
if
your
assertion
matches
it
agrees
to
give
you
the
thing
and
if
it
fails,
then
it
says
sorry.
A
E
E
A
E
I
mean:
what's:
what's
the
data
point
you're
trying
to
put
on
the
module
job?
If
it's
the
assertions,
I
don't
think
the
assertions
would
work
if
it's
like
the
type,
the
format
that
it
should
be
treated
as
because,
as
loaders
you
can,
you
know,
implement
your
own
way
to
generate
such
as
a
json
module
yeah
that
that's
probably
fine,
and
then
it
would
just
be
checked
when
you
try
to
retrieve
it.
E
A
To
be
clear,
I'm
not
I'm
hoping
to
avoid
adding
another
hook
like
we
just
went
through
all
this
effort
to
simplify
the
hooks.
So
if
I
can
keep
this
within
load,
that
would
be
my
preference.
I
I
feel
like
if
it's
within
load,
it
inherently
diverges
from
browsers
in
that,
like
we
could
have
within
a
single
load
hook
or
function
like
you
know,
fs.read
file
to
get
the
contents
from
disk,
then
or
or
before
either
way
then
validate
the
assertions.
Oh,
the
assertions
failed,
throw
an
exception.
A
C
E
I
mean
that
it's
not
going
to
work
once
you
have
multiple
kinds
of
assertions.
You
can't
have
a
flag,
that's
just
boolean.
So
if
somebody
has
type
and
then
version
and
then
you
know
language.
C
E
Feelings
from
firefox
about
it
must
be
banned
from
being
interpreted
any
other
way,
and
it
is
a
json
module
which
they
went
and
they
made
they
are
making
their
own
data
type.
Just
specifically,
so
it
can't
be
worked
around.
E
E
So
the
cash
keys
are
the
url,
the
absolute
full
url
and
then
key
pairs
of
assertion
key
and
assertion
value
tuples.
So
you
have
an
arbitrarily
large
cache
key.
E
And
then
you
have
to
use
your
loaders
or
whatever
means
you
do,
and
for
any
given
one
of
those
pairs
of
the
assertion
key
and
assertion
value
you
have
to
determine
if
it
collides
with
another
part
of
the
cache
or
not
so
the
cache
isn't
a
tree,
it's
a
graph
which
might
confuse
people
because
we're
storing
it
in
maps.
But
the
map
can
actually
point.
E
The
functional
problem
is
easily
explained
with
the
assert
and
non-assert
form
for
type
json,
so
we
have
a
cache
key.
If
we
have
a
load
operation,
we
basically
have
tied
it
to
url
being
the
cache
key
in
it
that
is
assigned
prior
to
load
effectively,
but
assertions
and
stuff
aren't
always
available
prior
to
load.
They
have
to
be
generated
from
load
because
some
are
coming
in
from
network
or
wherever
I
don't
care,
and
then
so.
These
refine,
the
previous
cache,
which
is
okay,
but
there's
no
way
to
coalesce,
is
what
antoine
gus
want.
A
E
C
A
E
Out
I
mean
you're
out
of
slack
it.
Doesn't
it
doesn't
matter
how
we
do
it?
I
I
will
be
my
new
job
next
week
and
then
I'll
have
more
time
after
that
cools
off,
but
basically
you
can
store
the
refinements
on
the
module
job
itself
or
in
the
cache
key.
It
doesn't
really
matter
you're
just
moving
where
the
data
pointer
is,
but
you
have
to
take
all
those
key
value
pairs
and
put
them
somewhere.
A
A
A
E
A
C
A
So
the
second
one
proceeds
through
the
full
life
cycle
like
it
doesn't
get
short-circuited
by
saying:
oh
there's
one
in
the
cache
return
it
and
stop
it
pretends
like
it,
never
found
something
in
the
cache.
And
so
then
it's
going
to
go
through
the
whole
life
cycle.
It
could
finish
its
whole
life
cycle,
but
still
while
the
wall,
the
first
one
is
not
yet
thrown
so
then
what
does
it
like?
Overwrite
in
the
cash.
E
E
E
E
E
A
C
A
For
a
second,
like
just
figure
out
how
to
get
this
to
work
within
node
and
then
and
then
we
can,
you
know
I
feel
like
once
we
get
something
working
that
handles
all
the
edge
cases
in
node.
Then
hopefully,
it'll
become
clear:
how
how
to
handle
this
within
user
loaders,
like
what
input
and
outputs
the
load
hook
should
have,
and
all
that
you
know.
E
Don't
yeah,
but
it
could
be
an
opportunity
for
us
to
fix
up
the
built-in
format
to
be
something
more
generic
and
universal.
That
makes
more
sense
because
that's
basically
an
advanced
cache
operation
too.
E
A
E
A
Okay,
yeah,
I
mean
it's
also.
This
feels
like
we
don't
have
to
unflag.
Well
we're
not
gonna
unflag
jason
models
for
at
least
a
month,
I
think
even
after
this
vr
lands.
So
there
could
be
plenty
of
time
to
refine
this
like
what
to
do
with
con
on
conflict.
Behavior,
like
I
don't
feel
like
that
needs
to
be
resolved
in
order
to
land
this
pr,
as
long
as
as
long
as
there's
something
as
long
as
it
does
something
in
the
pr
what
it
does,
I
feel
like
we
could
revise
and
follow
up.
A
Okay,
so
I
just
need
to
figure
out
what
that
something
is
so
that
I
can
land
the
vr.
So
if
you
have
an
idea
on
that,
I
feel
like
I'm
gonna
come
up
with
something
that
may
not
be
the
best
I
feel
like
whatever
I
feel
like.
I'm
gonna
come
up
with
something
that's
like
has
an
obvious
design
flaw
like
oh,
whatever
the
newer
one
is,
replaces
the
older
one
in
the
cache
and
sure
there's,
probably
something
terrible
that
happens
as
a
result
of
that,
but
deal
with
that
later
or
something.
E
F
A
E
Don't
think
we're
going
to
solve
it
for
user
land
loaders
in
time
we're
not
going
to
solve
it
for
user
land
loaders
in
time
it
doesn't
have
to
be
like
oh
yeah,
just
don't
worry.
A
Later
but
yeah.
A
By
the
way,
one
last
thing
before
we
go
derek
pointed
out
recently
that
apparently
there's
an
alias
in
the
node
cli
flags,
where
dash
dash
loader
is
an
alias
for
experimental
loader
were
either
of
you
aware
of
this
or.
E
E
E
If
you
want
to
throw
them
under
the
bus,
do
it
with
a
big
change?
Don't
don't
just
do
it
randomly
patch.
E
A
A
E
E
A
Boat,
I
mean
if
it's
been
this
way
for
two
years,
then
I
feel
like
yeah
we're
breaking
people
for
no
good
reason.
If
it's
eventually
going
to
become
loader
again
so
then
you
know
but
okay
good.
I
was
just
curious.
The
back
story,
all
right,
I'm
I'm
over!
Is
there
anything
else
either.
If
you
wanted
to.
A
C
Oh
no,
I
was
going
to
ask.
I
saw
a
whole
bunch
of
people
asking
me
to
like
backcourt
things
and
like
do
some
other
stuff.
Is
this
something
I
need
to
do?
They
were
asking
me
while
I
was
on
vacation
and
I
was
like
bradley.
A
A
The
other
thing
is
that,
like
the
the
window
will
close
for
landing
back
ports
on
12,
I
don't
know
when
you
can
look
up
like
the
node
release
calendar.
I
think
when
we
ship
node
18,
which
is
in
like
march
or
something
then
they
close
the
door
on
17
and
they
also
closed
the
door
on
12..
I
think
12
at
that
point
is
like
end
of
life
or
maintenance
release
or
something
so
so
it's
it's
like.
If
you
want
it
do
it
sooner
than
later,.
C
A
I
think
it's
it's
more
like
like.
There
are
a
lot
of
people
out
in
the
wild
still
on
14
visits
the
lts
branch
right
now
you
know,
and
then
16
becomes
the
lts
branch
in
like
march
or
something
so
if
you
want
more
people
to
be
using
this
feature
sooner
then
back
port,
it
at
least
to
14,
so
that
the
people
who
aren't
going
any
newer
than
lts
will
start
being
able
to
use
it.
You
know,
okay
or
even
something
I
mean.
A
Think
it's
a
question
of
like
how
many
other
pr's
yours
depends
on
that
haven't
been
backported,
so
like
backboarding,
this
there
haven't
been
that
many
pr's
on
loaders,
like
I
think
yours
was
the
first
one
in
over
a
year,
so
it
might
very
well
be
that
you
could
just
follow
those
instructions
that
targos
put
and
your
pr
should
land
pretty
cleanly
like.
Maybe
you
have
to
resolve
some
conflicts
in
some
docs?
A
You
know
markdown
files
or
something
but
like
hopefully,
there's
not
a
huge
conflicts
which
which
implies
that
there
is
some
other
dependency.
You
know
some
other
big
pr
that
should
have
been
backwarded
before
this
one.
You
could
just
try
trying
to.
You
could
just
start
following
the
instructions
and
see
how
many
conflicts
you
get
and
if
there
aren't
that
many
then
just
go
for
it.
A
A
C
Oh
yeah
sure
like
if
it's
just
like
cherry
pick,
some
stuff
sure
yeah,
okay,
cool
I'll,
take
a
look
bradley.
A
Like
she,
they
tried
to
do
the
steps
that
targos
did,
but
they
were
merged
conflicts
and
they
don't
know
how
to
you
know,
someone
who
didn't
work
on
this
code
doesn't
know
how
to
resolve
the
conflicts.
That's
like
really,
you
maybe
me,
but
most
likely
just
you
will
know
what
to
do
about
the
conflicts
they
find.
So
that's
why
she
was
like
you
know.
C
Okay,
cool,
I
think,
targos
resolve
that,
though,
because
it
was
missing
something
and
it's
okay.
Now.
A
But
you
should
be
able
to
handle
it.
It's
just
that
whoever
was
on
the
release
team
like
didn't
know
how
to
handle
it
because
they
weren't
familiar
with
the
code.
Okay,
cool!
Thank
you,
okay,
all
right
and
bradley.
Is
it
like
one
pr
per
backport,
so
he
would
open
a
separate
pr
for
14
and
then
another
pr
for
12.