►
From YouTube: Node.js Loaders Team 2021-11-23
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
so,
hey
everybody.
Welcome
to
the
november
23rd
2021
meeting
of
the
node.js
loaders
working
group.
This
is
being
recorded,
not
on
youtube
live.
Unfortunately,
there
seems
to
be
some
credential
problems
and
we'll
try
to
fix
it
in
a
little
bit
later
so
yeah
we
have
an
agenda
with
three
items.
Today
those
items
are
gonna,
be
the
manifest
loading
hook,
a
design
dock
for
reusing
default
resolve
and
a
request
for
utility
functions
for
loading
and
resolution
yeah.
A
So
the
first
one
on
the
agenda
is
a
hook
for
manifest
loading
mile.
This
seems
to
be
yours.
Has
anything
changed
anything
you
want
to
talk
about.
B
So
I
made
the
request
explaining
some
potential
use,
explaining
the
the
use
case
and
what
the
interface
could
look
like.
I'm
not
entirely
sure.
What's
the
process,
starting
from
now,
whether
I
should
try
to
make
a
an
implementation
inside
node,
whether
we
should
it
should
wait
for
this
pr
to
be
merged
first,
and
that's
also
a
question
of
what's
the
next
action
item.
A
A
We
can
continue
to
iterate
this
and
try
to
merge
this
as
that
implementation
evolves.
That's
usually
what
we've
tried
to
do
in
the
past
in
different
working
groups,
I'm
sure
there
will
be
nits
and
things
I'm
sure
the
design
will
change
before
that
pr
lands,
but
it
gives
some
way
for
it
to
move
forward.
B
And,
generally
speaking,
the
the
endeavor
is,
everyone
agrees
is
a
good
thing.
B
C
C
So
if,
if
like
you,
you
already
know
how
this
is
going
to
go,
unlike
the
questions
are
just
by
noobs
who
like
me,
who
don't
actually
understand
like
what
you're
going
to
be
doing
with
it,
then
maybe
just
like
go
ahead
and
do
it
and
then,
when
you
you
do
it
and
then
we
look
at
it.
We're
like
oh
okay,
gotcha,
yep,.
B
So
just
it
cannot
be
done
as
a
as
a
utility
function.
This
use
case,
particularly
because
it
needs
to
be
composed
for
each
loader,
since
each
loader
will
want
to
add
their
own
logic.
B
C
I
think
we
were
like
the
the
main
lack
of
understanding
is
if
it
is
a
hook,
that
means
there
can
be,
and
hooks
are
part
of
chaining.
That
means
that
there
can
be
multiple
of
the
same
kind
of
hook.
So
if
you
have
your
fs
class
of
hooks,
how
does
one
hook
connect
to
the
other
and
how
do
they
like
interact
with
each
other
and,
let's
say
loader,
a
fs
class
of
hooks
or
groups
of
hooks
does
something,
and
then
loader
b
also
does
something.
C
B
So
I
don't
have
a
lot
of
experience
with
standards
or
this
kind
of
writing
them.
So
perhaps
I'm
missing
something,
but
from
my
perspective
I
feel
like
the
one
loader
will
simply
call
the
the
utility
function.
Let's,
let's
say
that
that
resolves
the
export
field
and
the
export
field
algorithm
itself
will
use
the
the
boots
for
which
file
and
start
file
this
kind
of
thing,
which
will
then
call
back
into
the
hooks
starting
from
the
first
loader.
B
So
yes,
the
the
loaders
would
be
re-entranced,
but
the
oops
would
likely
not
been
in
that,
for
example,
if
you're
on
the
track
to
make
the
resolved
call,
you
may
join
the
track
to
make
a
rigid
file
hook,
but
you
will
not
make
another
result,
call
while
you're
still
resolving
the
first
one.
Does
that
make
sense.
C
C
A
Go
ahead
so
what
mile's
saying
I
wouldn't
use
the
word
re-entrant,
because
that
could
mean
two
different
things.
While
you're
performing
these
hooks
like
read
file
here,
you
can't
restart
from
the
entry
loader
the
same
request.
It
has
to
continue
on,
but
you
can
make
more
requests
from
it.
A
So
if
I
get
a
read
file
request
for
slash
app.js,
the
loader
chain
can
only
go
in
one
direction,
calling
hooks
from
its
next
in
chain,
but
at
the
same
time
since
this
incoming
read,
file
request
actually
occurred
outside
of
the
loader
chain
after
this
gets
done,
or
while
it's
still
doing
stuff.
Even
another
concurrent
request
can
happen
at
the
same
time
and
you
can
have
two
of
those,
but
in
either
of
those
situations,
are
you
going
to
have
read
file
create
a
cycle.
A
This
is
fairly
important
because,
if
read
file
can
create
a
cycle,
you
can
get
deadlock
yeah
I
was
just
gonna
say
this
sounds
like
very
hazardous.
No,
no!
It's
not
hazardous
because
it's
not
re-entrant
like
miles
said.
Oh,
so,
do
the
same
thing
with
package.json,
where
package.json
in
common
js.
If
it
resolves
to
a
directory,
it
actually
doesn't
like
go
and
look
up
that
directory's
package
json,
because
doing
so
could
create
a
cycle
in
deadlock
and.
B
That
being
said,
one
question
I
have
is:
if
there
are
deadlocks,
it
means
that
there
is
a
bug
in
the
program.
Is
it
our
job
to
to
to
to
prevent
this
kind
of
thing,
knowing
that
it
will
also
make
it
more
difficult
to
write
books
that
will
compose
with
each
other?
I
understand
that
there
may
be
problems
if
a
hook
is
badly
written
and
doesn't,
and
some
loop
is
possible,
but
that's
something
that
will
be
detected
are
fully
quite
fast.
B
So
is
it
really
an
important
use
case
to
protect
against
that,
for
instance,
in
yarn
itself,
we
have
a
plug-in
system,
and
while
we
have
the
ability
to
only
continue
the
the
loader
chain
to
to
use
the
words
from
the
this
suspect
so
hawaii
we
have
the
ability
to
re
to
resume
the
hook
from
the
next
point
only
to
only
go
forward.
B
We
also
have
the
ability
to
call
the
original
pipeline
from
the
start
in
some
particular
case,
where
we
don't
want
to
assume
that
the
the
hooks
before
us
did
not
matter,
and
it's
quite
important
in
some
cases,
because
it
simplifies
the
quad
a
lot
and
I
feel
like
not
having
this
ability
might
be
a
bit
difficult
for
louder
implementers.
C
Like
the
situation,
rather
that
you
were
talking
about
for
the
iterative
approach
of
loaders,
is,
am
I
in
left
field
here
or
is
that.
A
No,
it's
very
similar,
so
I
don't
say
it's
our
responsibility
or
not
I'd
say
you
write
buggy
programs
in
both
ways.
A
I
would
be
very
interested
in
situations
where
you
need
to
call
the
topmost
plug-in
in
this
case,
because
I
am
very
hesitant
to
have
a
re-entrancee
in
these
hooks.
We
have
avoided
reentrancy
and
node
for
years
partially
because
of
performance
partially,
because
it's
hard
to
figure
out
what
you're
going
to
break
at
that
point,
because
anything
in
any
chain
can
break
any
part
of
the
plug
and
change,
because
it's
no
longer
a
tree,
it's
no
longer
a
direct
acyclic
graph.
A
B
One
potential
perhaps
exaggerated
example,
is:
let's
say
that
we
have
a
loader
that
lets
you
read:
files
from
zip
archives
and
another
that
lets
you
write
files
from
rar
archives
or
tower
archives.
B
D
B
A
A
I
need
to
know
all
possible
things
that
could
be
loaded,
because
you
can't
know
that
ahead
of
time
you
don't
necessarily
have
to
restart
the
chain
from
inside
the
loader
hooks.
You
can
actually
do
it
outside
with
composition
models.
That
seems
fine.
A
I'd
prefer
that,
where
you
as
a
zip
thing
could
be
like,
I
have
discovered
new
files,
please,
there
is
effectively
that
going
on
with
the
common
js
hook
in
the
load
hook,
yeah
when
you
return
format
comma.js
it
actually
like,
goes
out
and
does
something
to
a
different
system.
That
seems
fine
if
it
re-enters
that
way,
it
seems
fine,
because
all
the
time
that
means
it's
still
a
unidirectional
graph
to
me,
the
data
flows
only
one
way,
not
in
cycles.
A
C
How
would
that
work,
though?
So,
let's
say
you've
got
your
ziploader
and
it
happens
to
be
the
first
one
in
the
chain,
and
it
says
I've
discovered
a
rar
and
it
chalks
it
back
to
whoever
and
the
ziploader
was
the
first
and
rar.
Let's
say
is
the
second.
How
would
it
avoid
just
constantly
churning
and
saying
like
hey,
I
found
this
thing.
I
can't
deal
with
this
and
bringing
it
to
the
front
in
that
scenario,.
A
For
read
file
I
mean
you're
going
to
be,
let's
say
you
have
a
dot,
zip
and
inside
a
dot.
Zip
is
b
raw
and
inside
b,
dot,
rawr
c
dot
j
s,
so
you
have
zip
raw
js
is
nesting
levels.
Let's
say
the
zip
file
hook
is
first
the
broader
file
hook.
Second
and
then
the
default
node
one
is
third,
so
basically
you
get
an
absolute
path
or
relative
path.
It
resolves
inside
to
a
b
c
from
there
you
go
in
and
you
can
do
it
either
at
start
or
end.
A
So
you
try
to
resolve
using
the
default.
It
fails
and
then
the
rar
file
tries
to
resolve
it.
Can't
because
the
router
isn't
real,
it's
inside
a
zip
file.
It
fails,
then
the
zip
file
catches
the
error
and
was
like.
Oh
it
couldn't
resolve
it.
So
therefore
I
need
to
go
and
do
something
with
it.
I
don't
have
a
good
solution
on
what
that
something
is,
but
I've
written
it
before
a
long
time
ago.
I
can
look
up
what
I
did
for
noda.
A
It's
an
archive
loader
in
2014.
It
does
nested
stuff,
but
basically
all
it
did
was
catch.
An
error
and
restart
the
chain
at
that
point
with
some
more
data.
B
In
in
our
case,
what
happens
is
that
we
have
a
heuristic
that
shows
a
this
file
as
a
dot,
zip
extension.
So
it
means
that
we
need
to
locate
a
file
inside
the
archives.
So
what
would
probably
happen
is
that
the
ziploader
would
kick
the
tag
that
there
is.
The
last
component
is
a
dot
zip,
something
called
read
file
again
with
only
the
dot
zip
part,
so
that
it
would
get
the
file
the
path,
the
content
of
the
zip
itself
before
parsing
it.
B
This
call
to
refile
would
then
restart
from
the
beginning.
It
would
go
into
this
time
the
round
loader,
because
there's
a
dot
rar
somewhere
in
the
path
which
would
do
the
same
thing,
which
would
again
start
from
the
beginning,
and
this
time
it
would
go
into
the
final
and
reach
five
with
a
zip
which
would
finally
do
the
the
same
thing.
Once
again,
that's.
C
A
A
Okay,
so
it
needs
to
basically
be
able
to
preemptively
fill
the
cash.
That's
that's
it
before
it
passes
on
to
the
next
hook.
B
D
Well,
I
think
I
thought
that
we
were
thinking
or
I
was
thinking
we
would
maybe
try
to
implement
chaining
for
the
hooks
that
we
already
have
the
resolve
and
load.
Well.
I
guess-
and
I
don't
know
about
global
well
anyway,
the
three
hooks
that
we
already
have.
We
should
ship
chaining
for
those
and
then,
like
you
know,
any
new
hooks
or
any
you
know
variations
of
chaining
to
the
existing
hooks
then
would
we'd
already
have
that
in
there
that,
like
okay,
you
can't
break
this.
D
D
D
Yeah,
well
I
mean
the
only
thing
I'm
thinking
is
like
the
you
would
want
to
implement
a
hook
for
read
file.
Is
that
the
one
you
were
thinking
of.
D
C
Yeah,
that's
why
I
was
thinking
they
would
fit
in
as
utilities,
because
then
under
the
hood,
the
load
hooks
would
maybe
unwittingly
be
using
them,
but
if
they
are
in
fact
an
like
a
legit
hook,
then
I
don't.
I
don't
know
how
that
would
actually
happen.
B
C
B
Call
the
books
themselves,
for
instance,
when
you
call
the
utility
that
results,
the
exports
field
and
its
implementation
would
call
to
the
loader
hooks
in
order
to
know
where
are
the
manifests
and
read
them
so
the
the
consumer?
Would
the
yeah
the.
D
D
A
D
A
C
A
bad
bad
idea,
but
I'm
just
like
because.
D
Say
you're
writing
because
say:
you're
writing
a
loader
like
say
you
have
loaders
a
b
and
c
and
so
inside
load
for
a
it
calls
b's
resolve
hook.
D
C
A
A
I
mean
you're
not
like
calling
a
function
inside
of
a
function
like
getting
the
entire
load.
Hooks
is
like
if
I
wrap
a
function
so
that
it
errors,
if
you
give
it
a
bad
file
like
I
can't
be
like
oh
skip
the
thing
that
causes
errors.
I
just
want
to
get
to
that
lovely
passwords
file
in
your
s
folder,
so
that
would
be
breaking
composition
so,
like
the
ability
to
jump
around
in
your
graph
is
what
breaks
composition.
A
D
A
Can't
unwrap
yeah
to
get
to
more
privileged
or
non-transforming
well,.
D
That
was
why
I
was
so
confused
by
the
whole
idea
of
like
having
a
read
file
hook
because
in
my
mind,
that's
like
you
know
the
load
hook
in
a
calls,
a
b
and
c
and
read
file,
and
then
the
b
loaders
load
hook
calls
a
b
and
c.
If
you
read
file,
and
so
on
I
mean
maybe
there's
no
problem
there,
but
that
feels
risky.
Somehow,
like
you're
violating
some
rule
about
composition,.
D
Just
saying
like
having
going
through
the
whole
chain,
the
whole
list
of
loaders,
in
whatever
you
call
that
a
child
function
of
the
first
load
or
one
of
the
first
loader's
hooks
means
you
could
do
that.
What
you're
saying
is
bad
of
breaking
the
composition.
I'm.
B
I
don't
think
that
calling
into
the
other
book
is
breaking
composition.
From
my
perspective,
composition
is
just
being
able
to
reason
about
the
follow-up
of
the
api
as
a
as
if
there
was
a
single
one
and
then
it's
the
core.
That
is
a
task
from
scheduling
which
one
you're
going
to
call
when
you
call
it
so
it's
completely
generic.
You
just
call
a
function.
B
You
have
no
idea
where
it's
going
to
end
up,
but
you
know
that
it
will
be
there
and
it
will
be
supported,
and
in
this
case,
if
you
call
the
read
file
function,
then
you
you
have
no
idea
why
it
will
end
up.
You
just
know
that
the
result
will
be
the
one
that
you
expect
and
that's
what
that's
what
will
happen.
It
will
go
into
the
core
which
will
call
the
hooks
in
the
right
order
without
you
having
to
be
aware
of
what
is
this
order,
what
it
contains.
A
C
D
But
if
well,
it
also
feels
like
it
feels
like
it's.
I
mean
at
least
to
me.
It
feels
like
two
steps
ahead
like
in
my
mind.
If
we
like
first,
we
should
implement
chaining
with
the
hooks
we
have.
D
Second,
we
should
like
take
all
these
functions
that
are
within
the
node,
like
esm,
loader,
that
resolve
and
load
use
for,
like
doing
the
exports
resolution
and
and
other
things
like
that,
finding
the
package
route
like
like
expose
all
of
those
somehow
that
they
could
be
used
within
loaders
or
even
used
within
regular
user
code,
probably
rewrite
several
of
them
to
take
as
input
certain
things
that
they're
currently
just
like
like
pass
in
the
function,
read
file
rather
than
it
just
like
always
calling
the
fs.read
file,
because
so
then
that
way
you
could
swap
out
read
file
with
something
else
by
just
changing
the
argument.
B
Is
that's
very
fine
for
foreign
particular?
We
already
have
this
workflow
working
for
command
gs,
so
if
we
don't
implement
that
which
will
have
no
way
to
provide
to
esm
users,
what
current
gs
users
already
have.
So
I
understand
that
we
could
take
the
slow
path
and
not
care
about
that
until
later
on.
The
problem
is
that
it
means
that
we
will
not
be
able
to
recommend
to
our
users
to
use
esm,
because
for
us
it
will
be
impossible
to
guarantee.
D
A
good
service,
I'm
not
saying
that
you
wouldn't
get
you
wouldn't
get
there
in
the
end.
I
just
mean
like
in
terms
of
development
that,
like
we
should
like
land
a
series
of
prs
where
we
kind
of
build
up
to
this
functionality
because,
like
we
know
we
need
this
anyway,
we
know
we
need
to
chain
the
current
loaders.
D
We
know
we
need
to
supply
all
these
like
utility
functions
so
like
we
should
get
those
out
the
door
and
then
it's
still
not
going
to
be
enough
to
you
know
re-implement
plug-and-play
in
esm,
but
like
the
pr
that
provides,
the
ability
to
implement
plug-and-play
would
be
starting
from
that
basis.
Point
of,
oh
all,
these
utility
functions
exist,
oh
chaining
already
exists,
and
so
what
you
build
to
you
know
your
pr
to
chain
read
file
or
something
would
perhaps
be
a
lot
different,
probably
a
lot
smaller,
because
we've
already
done.
A
I
agree
with
making
small
prs
there's
a
good
transition
point.
We
do
have
two
other
agenda
items
on
the
topic
of
agenda
items.
We
do
have
a
utility
functions
for
the
steps
of
resolution
and
loading
jeffrey
you're
talking
about
this
right
now.
Maybe
you
could
go
in
to
greater
depth
on
how
these
will
prevent
things
like
the
desire
to
you
know
start
loading.
A
D
This,
I
think,
came
up
from
someone
who
wrote
ts,
node
the
typescript
loader
that
they
basically
like
re-implement
the
entire
resolve
algorithm
within
ts
load
and
for
them
it's
been
pretty
annoying
because,
like
as
like
the
package,
exports
feature
has
had
a
lot
of
evolution
in
the
last
couple
years,
and
so
it's
been
quite
a
challenge
for
them
to
keep
that
up
to
date
and
then
to
have
all
these
branching
forks
so
that
their
like
fork
of
resolve
knows
what
version
of
node
you're
running
and
then
it
behaves
as
appropriate
for
that
version
of
node,
et
cetera,
et
cetera.
D
So
some
of
these
we
discussed
some
of
these
pieces.
We've
discussed
splitting
out
as
utility
functions
from
the
beginning,
like
I
asked
for
get
package
root
way
back
when
I
was
working
on
the
first
version
of
loaders,
because
I
was
like
I
was
doing
that
example,
that's
in
the
docs
of
the
coffee
script
loader
and
I
was
like
well,
I
want
to
know
like-
does
the
controlling
package.json.
D
You
know
the
nearest
parent
package
of
json
for
a
particular
file
have
typed
that
module
so
that
then,
if
it's
like
a
coffee
file
in
there
I'll
I'll
have
it
behave
like
a
dot
js
file,
where
I
look
at
type
module
to
know
how
to
treat
it.
So
I
wanted
a
utility
function
called
get
package
route
where
I
could
pass
in
either
a
path
to
a
file
or
path
to
a
folder.
It
would
return
me
the
package.json
that
referenced
it.
D
There
are
lots
of
cases
like
that
where,
like,
if
we
just
you
know,
we
already
have
that
function
within
the
loader.
It's
not
quite
that
clean
where
it's
a
pure
function
that
takes
input,
returns
output,
it's
like
tied
into
the
loader
and
stuff
like
that,
but
it's
already
in
there.
So
we
just
need
to
do
the
work
of
making
it
more
pure
than
it
is
which
basically
mean
like
passing.
D
You
know
rewriting
it
so
that
it
accepts
more
arguments
and
then
taking
the
current
call
site
and
calling
into
this
new
kind
of
more
pure
version
and
then
exposing
it
somehow
like
it
could
be
on
the
module
api
or
we
could
make
some
kind
of
class
on
the
module
api
or
something
I
don't
know,
but
that's
just
one
example:
there'll
be
a
whole
bunch
of
other
ones.
Like
get
format
is
another
thing,
that's
buried
in
there.
D
We
should
just
expose
all
these
in
some
way
and
then
that'll
make
writing
loaders
a
lot.
A
lot
easier,
like
less
boilerplate
and
also
much
easier
to
like
have
the
abilities
vary
per
node
version
because
you're
kind
of
pushing
the
knee
you
know
like
it's
already
packaged
within
the
utility
function.
How
you
know
package
exports
resolution
behaves
in
the
in
the
current
version
of
node,
etc.
A
So
exposing
something
seems
good,
exposing
the
default
seems
fine.
I
don't
think
it
works
with
chaining
at
all.
Like
the
idea
of
composition
like
the
raw
and
zip
thing,
I
don't
know
how
you
could
use
a
utility
function
that
accepts
a
parameter
and
have
it
reasonably
work.
If
loaders
come
from
two
different
kind
of
feature
sets
one
is,
I
can
read
raw
archives.
One
is,
I
can
read
zip
archives.
B
B
C
But
I
don't
think
you're
saying
jeffrey
is
going
with
this.
Is
that
it's
possible
so
like
the
thing
that
I
did
is
just
one
of
we
could
say:
that's
that's
the
default
and
you
could
use
it
or
not,
and
then,
if
you
didn't
want
to
use
it
for
say,
zip
then
supply
your
own.
A
C
World,
I
think
what
we're
trying
to
do
is
lower
the
bar
for
writing
your
own.
So
currently,
if
you
need
to
write
your
own,
you
have
to
rewrite
the
whole
thing,
whereas
we're
saying
okay,
well,
there's
actually
27
pieces
off
the
top
of
just
pulling
a
number
out.
You
don't
have
to
rewrite
all
27
pieces.
You
only
actually
have
to
write
25
or
like
you,
only
have
to
write
two
and
then
you
can
use
the
other
25
or
something.
D
Like
I
think,
there's
intrinsic
value
in
say,
like
you
know,
parse
exports
function
where
you
can
pass
in
the
exports
object
as
if
it
had
come
from
package.json,
and
maybe
you
also
have
to
pass
in
a
file
system,
stat
function
and
or
a
file
system
read
file.
You
know
whatever
other
dependencies.
It
may
need
in
case
like
determining
what
to
use,
might
involve
file
system
calls,
and
then
it
just
returns
to
you
yeah
for
this
specifier,
for
this
exports
object
with
these
utility
functions
for
reading
the
file
system.
D
B
A
C
What
I'm
saying
like
if
we
produce,
if
we
expose
the
smaller
bits,
then
okay
yeah,
maybe
they
can't
use
all
of
our
things,
because
they're
doing
some
arguably
naughty
things
so
sure
they
suffer.
Those.
D
Well,
but
like,
for
example,
I
think
they
wanted
to
do
exactly.
I
don't
remember
the
details
of
the
new
esm
stuff
in
the
newest
version
of
typescript,
but
I
think
they
wanted
to
do
almost
exactly
what
I
wanted
you
know
years
ago
with
with
the
coffee
file
where
they
want
to
know,
was
there
a
type
module
in
the
nearest
parent
package
that
jason?
So
if
we
created
a
get
package
root
function,
presumably
they
would
use
it.
You
know,
especially
if
it's
flexible,
where
it's
like.
D
You
know
it's
not
it's
not
just
returning
a
boolean
of
true
faults
if
there
was
type
module
in
there,
but
it
could
return
like
the
entire
contents
of
the
package.json
file
say
or
the
path
the
package.json
file
or
you
know
whatever.
Then
we
give
them
the
flexibility
of
what
to
do
with
the
information
you
know.
If
they
don't
want
to
use
the
utility
function,
they
don't
have
to
use
it,
but
the
idea
would
be
that
we
would.
We
would
implement
things
that
are
general
enough,
that
they
would
save
many
loaders.
A
A
D
Most
most
loaders
aren't
trying
to
do
what
typescript
is
trying
to
do
like
most
loaders
have
much
like
lower
ambitions
and
giving
them
functions
that
just
let
them
do
something.
The
way
that
node
was
doing
it
so
that
they
don't
have
to
you
know,
copy
paste
from
the
node
source
code
would
be
a
benefit
to
most,
and
it.
A
A
D
C
I
think
what
they
want
is
like,
in
many
cases,
they're
doing
almost
the
same
thing
so
like
if
they
can
get
the
information
that
it
that
node
is
already
doing,
then
they
can
maybe
piggyback
off
of
that.
So,
even
though,
if
the
thing
that
we
expose
to
them
doesn't
do
exactly
what
they
need,
it
will
get
them
closer
than
where
they
are
now.
B
I
think
one
thing
that
should
be
taken
into
account
is
that
the
user
loan
implementation
of
the
node
algorithm
also
have
their
differences
compared
to
the
node
algorithm,
but
by
accident,
for
instance,
we
have
needed
to
re-implement
the
exports
field
resolution
because
node
doesn't
declare
it,
so
we
had
to
use
a
third-party
dependency,
except
that
this
third-party
dependency
doesn't
doesn't
implement
some
of
the
behaviors
in
and
it
becomes
even
more
difficult
when
you
consider
that
node
is
adding
new
behaviors
every
few
releases,
meaning
that
it's
well.
That's
that's.
D
What
I
was
getting
at
yeah,
that's
the
there's,
the
the
npm
over
on
the
common
js
side.
There's
an
npm
package
called
resolve,
which
aims
to
be
that
of.
Like
you
know
the
re-implementation
of
the
node
result,
you
know
require.resolve
and
they
it's
a
lot
of
the
node
code,
just
copy
pasted,
you
know,
but
yeah
I
think
we
want
to.
It
would
be
preferable
to
avoid
that,
because
then,
if,
if
node
provides
these
as
utilities,
then
loaders
could
just
pull
from
it
and
it
would
just.
A
Yeah,
but
I
think
just
the
api
design
is
precarious,
like
having
having
the
like
find
package.
Package.Json
is
an
easy
thing
that
I
don't
think
anybody's
gonna
really
argue
with,
unlike
the
like
resolve
package
json,
which
is
flame,
wait.
D
A
A
resolve
package
json
and
package,
given
a
specifier,
see
which
package
json
is
relevant
and
there
are
two
and
people
just
argue
forever,
which
is
the
most
relevant
one,
because
they're
useful
for
different
cases.
C
One
of
them
like
there
must
be
an
absolute
answer,
because
something
current
no
no,
but.
C
A
D
So
say
you
read,
say
you
read
import,
you
know
foo
from
package,
okay
and
no
dot,
slash
node
modules,
slash
pkg,
slash
package.json
then
includes
an
exports
field
and
inside
there
it
says.
Like
you
know,
exports
import
goes
to
dot,
slash,
dist
slash,
you
know,
index.js,
there's
also
a
dot,
slash
disk
package.json
that
just
includes
type
module.
D
So
for
the
purposes
of
knowing
whether
disk
slash
index.js
should
be
esm
or
comma.js.
It's
looking
at
the
package.json,
that's
right!
Next
to
it
for
the
purposes
of
how
it
mapped
to
the
import,
the
specifier
or
pkg.
It's
looking
at
the
package.json.
That's
one
level
up,
so
those
are
the
two
packages
of
jsons
that
are
involved
in
resolution.
For
that
one
import
statement
right,
but
yeah.
I
think
this
is
not
the
end
of.
D
D
C
A
D
Why
that's
why
it's
valuable
for
us
to
just
do
to
just
write
a
function
document
in
the
api
and
be
like
this
is
when
you
use
get
package
root
with
with
the
option
of
you
know,
for
exports
resolution
true
or
for
type
resolution
true,
and
what
the
difference
means
between
those
two
options
or
or
whatever
we
end
up
being
the
api
design,
for
how
do
you
return
this
package,
jason
versus
that
one?
D
C
I
thought
we
were
talking
about
this
like
two
three
meetings
ago
and
you
were
saying:
if
we
do
do
this,
then
that's
the
only
stuff-
and
I
think
jeffrey
and
I
had
a
little
bit
of
a
mind,
boggle
trying
to
figure
out
why
that
was
necessary.
And
then
you
explained
it
and
we're
like
oh
okay,
yeah.
That
does
make
sense,
because
you're
talking
about
like
security,
something
something
something.
D
D
I
think
it
can
be
done.
I
think
it
just
needs
some
careful
thought
and,
like
probably
the
probably
the
first
pr
maybe
get
package
root,
would
be
a
good
one.
To
start
with
and
to
bradley's
point,
you
should
probably
return
both
package
of
jsons
or
we
should
have
a
pair
of
functions
for
each
package
or
json,
and
then
that
could
establish
the
model
of
how
to
do
these
in
general.
D
Like
is
it
just
like
import
get
pack
import
bracket,
get
package
root
from
module
or
is
it
you
know,
import
resolution
utility
functions
from
module
and
then
resolution
utility
functions.
Dot
get
package
root
is
like
a
static
method
off
that
class.
You
know
like
we
need
to
figure
out
the
overall
like
structure
of
how
these
are
going
to
be.
If
we're
going
to
have
a
dozen
of
these,
but
doing
the
first.
D
A
D
A
C
I
think
one
of
the
things
that
people
were
raising
were
that
the
mail
and
the
utilities
type
things
would
potentially
affect
the
chaining
implementation
and
if
we
do
chaining
before
these
things,
we
might
put
the
cart
before
the
horse.
D
B
We
can
also
take
into
account
the
work
from
the
other
pr
and
just
make
our
best
to
avoid
to
avoid
blocking
the
other
through
the
api,
for
example,
bradley
mentioned
that
perhaps
it
would
make
sense
to
pass
all
the
books
into
the
in
in
parameter
when
calling
a
subsequent
books,
perhaps
one
way
to
not
block
this
would
be
to
change
the
prototype
so
that,
instead
of
passing
a
function,
you
pass
an
object
with
just
the
hook,
you're
interested
in,
so
that,
if
later
we
decided
to
expand
this
to
cover
all
the
oaks,
it
wouldn't
be
blocked,
because
we
decided
to
pass
a
function.
D
A
D
C
D
This
is
a
much
messier
section
of
kpi
than
like.
I
I
just
can't
like.
I
understand
people
want
to
start
using
this,
but
like
they
really
shouldn't
be
using
it
for
anything
other
than
trivial
or
testing
right
now,
like
it's,
just
not
ready,
like
there's
huge
fundamental
things
that
aren't
in
there
yet
like
chaining,
like
utility
functions
like
the
ability
to
to
all
the
dependencies
for
something
like
plug
and
play.
So
it's
just
gonna
change
as
we
implement.
B
That
I
agree
with
that,
but
I
don't
know
if
not
as
perks
not
should
have
waited
that
this
is
ready
before
unflagging
models.
But
that's
right
now.
D
I
mean
we
could
no
way
we
could
have.
This
is
not
gonna,
be
ready,
you
know
for
a
year
probably,
and
if
we
hadn't
shipped
yes,
I
mean
we
shipped
dsm
like
three
years
ago.
If
you
imagine,
if,
like
esm,
was
still
flagged
all
this
time
until
right
now
and
for
another
year
or
two
from
now,
I
mean
I
mean.
D
B
The
main
question
I
will
have
is
where
to
inject
it,
because
it
would
require
to
inject
it
inside
the
the
node
resolution
algorithm.
I'm
not
sure
if
they
are
already
a
sync,
so
resolution.
B
D
B
It
has
to
be
stats
because,
for
example,
if
you
make
a
require
and
it's
a
folder,
then
you
need
to
read
the
index.js
file.
D
C
B
Even
with
isn't
there
legacy
flag
or
something
I
I
think.
D
D
C
D
Loader,
sorry,
but
I
think,
but
like
that's
kind
of
your
that's
more
of
a
question
than
for
you
is
like,
if
does
plug
and
play
want
to
potentially
support
some
other
loader
that
may
be
loaded
before
or
after
plug
and
play
that
does
x,
y
or
z,
because
in
a
sense
that's
that
means
that
your
loader
needs
to
potentially
be
able
to
predict
what
anyone
else
could
be
doing,
which
is,
I
think,
too
much
of
a
burden
for
plug
and
play
to
bear.
It.
A
D
D
D
A
C
Particular
people
in
node
who
are
more
or
less
married
to
it
and
we
have
to
provide
the
ability
for
an
alternative.
There's.
D
Okay,
yeah,
the
other
thing
is
like,
I
think,
the
only
reason
it
cur
like
yeah
there's,
maybe
only
one
or
two
people
who
still
are
you
know,
really
want
it
to
exist,
and
the
great
majority
who
don't.
However,
I
think,
like
it's
still
chugging
along
for
two
reasons.
One
is
that
it's
not
necessarily
blocking
anything
right
now
to
remove
it
like
like.
In
order
to
remove
it,
I
need
I
would
in
order
to
propose
if
I
wanted
to
propose
getting
rid
of
it.
D
B
D
Then
there
would
then
everyone
would
be
like
yeah
sure
go
for
it,
but
until
there's
a
reason
to
potentially
get
rid
of
something
that
some
people
are
using,
then
it's
like
yeah.
Well,
why
would
we
get
rid
of
that?
It's
not
blocking
you
on
anything.
So
that's
part.
One
part,
two
is
what
I've.
What
I
said
years
ago,
which
is
still
kind
of
true,
is
that
before
we
get
rid
of
it,
we
should
give
people
an
off
ramp,
which
is
here's
a
loader
that
you
could
run
that
re-implements
that
behavior.
D
D
You
know,
legacy
node.js
resolution,
dot,
mjs
and
then
like
they
could.
They
could
just
use
that
instead.
So
then
it's
an
easy
transition
for
people
who
were
using
it.
They
have
a
way
to
continue
getting
that
behavior,
but
that's
dependent
on
like
the
loader's
implementation
maturing
enough,
so
that
we
to
the
point
where
we
could
provide
a
loader
to
replace
that.
D
Incidentally,
I
started
trying
to
write
such
a
loader
like
two
years
ago
and
I
quickly
got
got
stuck
needing
a
bunch
of
utility
functions
because
like
in
order
to
implement
this,
I
need
to
find
the
nearest
package
json
and
find
and
do
see
how
exports
resolution
would
resolve
et
cetera,
et
cetera,
and
it
was
too
much
of
a
burden
to
like
reimplement
all
that
within
my
loader.
So.
D
If
you
want
to
do
both,
I
guess
you
can,
but
I
think
it
would
be
easier
to
discuss
what
you're
proposing
if
there
was
only
one
rather
than
two,
if
that
makes
sense
to
you.
So
if
you,
if
you
don't
mind
at
least
starting
with
that,
and
then
just
assume
that
this,
you
know
pretend
that
this
flag
doesn't
exist,
we
can
kind
of
see
what
that
looks
like
jacob.
Do
you
have
time
to
work
on
chaining
anytime
soon,
or
does
anyone
have
time
to
work
on
chaining?
D
C
Do
is
there
anything
for
me
to
do
yet.
D
A
C
C
D
Mean
you
could
add
that
right
now
as
its
own
pr,
because
technically
we
already
have
chaining
just
it's
always
between
one
custom,
loader
and
the
node
loader.
So
you
could
add
short
circuit
right
now
and
it
wouldn't
really
do
much,
but
it
would
be
there
and
then
you
could
add
the
ability
to
have
multiple
user
loaders.
If
you
wanted
to
split
it
up
or
you
could
do
it
in
one
pr,
but
is
there
anything
that
you
feel
you're,
that's
blocking
you
from
starting
either
or
both
of
those
pr's.
C
No,
I
don't
think
so.
I
only
thought
we
were
waiting
on
some
of
the
utilities
things
to
settle,
because
that
would
help
various
people
like
with
their
like
mental
model
of
how
things
would
work.
C
But
if
we're
pretty
confident
that
we
can
just
like
sort
those
things
out
independently
and
then
I
don't
know
like
we
adjust
the
arguments
or
something
or,
however
it
happens,
and
they
they
don't.
One
doesn't
need
to
wait
on
the
other
than
sure.
D
I
don't
think
one
needs
to
wait
on
the
other
like
if
you
look
at
the
whole
design
like
either
of
the
design
docs
that
we
made
for
chaining.
Neither
of
them
really
relies
on
any
utility
functions,
so
I
think
we
could
implement
chaining
right
now
and
then
deal
with
utility
functions
as
a
kind
of
a
separate
concern.
D
Like
I,
I
would
think
that,
like
the
goal
for
chaining
would
be
like
take
the
examples
in
the
in
the
design
dock
of
like
what
you
know
that
unpackaged
loader
and
the
http
hps,
loader,
etc,
and
be
able
to
achieve
those
examples
I
think
would
be
like
you
know
those
would
be
the
tests
essentially
of
it
once
those
are
possible,
then
we've
implemented
chaining,
I
think,
and
then
the
and
then
the
question
I
mean
those
examples
were
also
kind
of
chosen
with
the
mind
toward
these
are
the
simplest
examples
I
could
think
of
so
they
don't
really
have
any
need
for
utility
functions.
D
So
then,
you
know
later
we
would
be
like
okay.
Here's
an
example
of
a
loader
like
the
coffee
script
example
is
the
is
the
probably
the
best
example.
We
have
right
now,
that's
already
in
the
docs,
where
yeah
that
has
a
need
for
utility
function
in
that
we
already
have
that
get
get
package
root
or
whatever
we
called
it
function.
D
A
D
We
like
make
the
breaking
change,
because
that,
by
that
point
we
could
we
might
decide
to
like
it
would
almost
be
better
to
push
that
off,
because
we
might
decide
to
make
up
like
more
than
one
breaking
change
at
the
same
time
like
maybe
we
want
to
add
multiple
properties
to
the
last
object
and
not
just
have
it
be
an
object
of
functions
or
something
like
that.
You
know
who
knows
or
we
want
to
add
another
parameter
to
the
function
signature
now
it
is
for
you
know.
D
Well,
well,
all
I'm
saying
is
like
there
we
could
easily
decide.
We
want
to
make
more
than
one
change
the
function
signature
of
a
hook,
so
we
might
as
well
wait
until
we
can't
avoid
making
that
change
anymore
and
then
do
all
the
changes
together
as
like
one
breaking
change
to
this
to
the
signature
rather
than
you
know,
little
by
little
and
maximizing
the
pain
of
breaking
changes.
A
Okay
cool,
then,
whenever
mocking
lands
like
I
said,
I
want
to
move
the
loaders
off
thread,
which
would
make
things
like
us
technically
calling
things
synchronously
non-issue,
because
we
can
fake
being
synchronous
if
we're
all
fit.
Oh
yeah,
p.s
bradley
you
wizard.
D
D
C
Yeah
I
started
to
read
through
right
before
this
I'll
try
to
get
to
it
very
soon,
like
maybe
tomorrow,
maybe
not
tomorrow.
Twice
my
birthday.
D
D
Okay,
I
guess
my
al,
the
only
thing
one
other
thing
I
feel
like
it's
like,
I
don't
if
you
haven't,
read
the
design
doc
for
chaining.
B
Since
I
updated
them
in,
like.
D
Oh,
you
did
read
it
yeah,
okay
yeah,
I
was
just
gonna
say
like
the
those
examples
that
I
had
in
there
like
unpackaged
and
http,
hps,
etc
like
when
you
do
the
the
pr
for
like
a
read
file
hook.
I
guess
just
like
my
question,
for
you
would
be
these
examples
in
the
in
the
chaining
design
doc.
I
assume
they're
all
still
possible
with
the
existence
of
a
read
file
hook,
but
if
they're
not
that
would
be
something
that
we
would
have
to.
D
You
know
that
would
be
concerning
we'd
have
to
deal
with
that,
but
just
as
you're
working
on
that
or
designing
it
like
just
keep
in
mind
like
every
all.
The
examples
in
that
doc
should
remain
achievable
with
with
whatever
changes,
you're
gonna
make.
Does
that
make
sense,
yeah.
B
Okay,
so
which
training
pr
or
which.
D
C
D
That
one
so
yeah,
I
don't
know
if
we
want
to
sit,
we
could
say
something
like
that
in
the
readme
or
take
the
old
one
off
or
put
the
old
one
in
like
an
archive
folder
or
something
but
yeah,
or
maybe
do
that
once
it's
once.
We
actually
have
a
pr
that
implements
it
and
we
see
how
it
looks,
but
but
yeah
that
that
was
what
I
was
thinking.
We
were
going
to
try
to
implement
as
the
next
pr
yeah
sounds.
Good.
D
D
I
was
hoping
you
had
some
clarity
about
which
direction
wasm
was
going
to
go
in
the
future
from
anywhere
from
tc39
from
html.
You
know,
but
no
one
seems
to
to
have
a
stand
on
it
other
than
that.
Guy
really
wants
it
to
not
require
a
type
assertion,
but
it's
not
clear
to
me
that
you
know
I
assume
that
he
probably
the
rest
of
the
wildland
folks
probably
agree,
but
I
don't
know
if
html
is
going
to
go
for
that
the
anyway.
D
The
only
reason
I
say
this
is
that,
like
I
wanted
to
implement
import
of
node
dative
files,
which
currently
you
have
to
use
create,
require
for,
and
I
feel
like,
node
native-
should
follow.
Whatever
the
same
pattern
is
of
volume
so
like
if
was
under,
were
to
require
the
type
assertion
then
native.node
files
should
as
well
so
now.
It
just
feels
like
it's
blocked
on
that,
but
maybe
it's
not
such
an
urgent
use
case
like
people
could
just
use,
create,
require
more
or
less
indefinitely
and
who
cares.
A
D
Yeah,
so
maybe
it's
not
worth
thinking
about
anytime
soon
I
mean
the
other
thing
is
like
it
almost
makes
more.
I
still
want
to
get
that
https
support
into
node
landed
first,
because
it's
sort
of
like
well.
Are
we
going
to
support
native
modules
over
https
and,
if
so
well,
then
we
need
to
figure
out
what
their
mime
type
is
supposed
to
be
etcetera
like.
C
A
Realistically,
you
want
the
mocking
pr
done
because
it
does
something
funky
with
import
meta:
okay,
not
repairable.
When
you
say
funky,
I
say
like
ingenious:
no,
the
https
pr
does
something:
funky,
oh
okay!
Okay,
so
you
in
order
for
loaders
to
handle
it
you'd
have
to
land
that
mocking
pr
because
it
as
a
side
effect
of
it.
It
lets
you
deal
with
it
and
then
the
other
thing
was.
I
forget
what
it
was
something
about:
caching,
which
we're
not
doing
caching
in
the
initial
implementation
anyway,
so
you're,
probably
okay.
C
Do
this
quietly?
Are
you
up
for
completing
that
pr
jacob?
I
think
maybe,
but
also
it
sounds
like
I
need
to
wait
on
the
mocking
thing.
So
maybe
I
should
well.
A
C
C
D
C
Oh,
my
god,
they're
so
painful
in
node,
like
you
buying.
D
Yeah,
you
know
I
just
posted
the
issue
about
those,
because
I
was
struggling
with
those
as
well.
It's
you
might
find
it
interesting
the
conversation
there.
I
certainly
learned
a
few
things.
D
I
was
also
noticing
that,
like
the
error
message,
tests
like
we
also
have
a
bunch
of
I
mean
bradley.
You
can
maybe
explain
this
to
me,
but
we
have
a
bunch
of
tests
for
for
other
things
in
esm,
where
it
just
like
loads.
B
C
Esm
suite
on
board
with
that,
because
when
I
was
first
starting
to
like
join
the
implementation
team
here
that
like
broke
my
brain,
I
had
no
idea
what
the
hell
was
wrong.
I
had
a
thousand
tests
screaming
at
me
and
it
just
seemed
like
the
problem
that
was
happening
was
supposed
to
be
happening.
Well,.