►
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,
this
is
the
june
19th
2022
meeting
of
the
node.js
loaders
team.
We
had
on
the
agenda
the
discussion
about
renaming
our
team
from
loaders
to
hooks
or
something
else,
and
likewise
potentially
renaming
the
api
or
the
command
line
flag.
B
We
just
before
this
meeting
decided
to
punt
the
other
item
on
the
agenda,
the
supporting
type
stripped
up
and
during
it
discussion,
because
in
that
thread,
mateo
the
author
of
the
thread
just
to
ask
the
next
10
team
to
handle
it
so
we're
going
to
skip
that
for
now,
but
kind
of
branching
off
of
it
was
the
question
of
node
configuration,
which
was
discussed
as
like
a
comment
in
that
thread
and
was
discussed
in
an
issue
on
the
loaders
team.
C
About
that,
so
I
think
there
are
several
ways
to
do
it.
Maybe
not
all
of
them
are
possible,
but
just
to
brainstorm
so
so
we
could
either
have
it
like
the
the
command
line
flag,
which
is
global.
So
when
you
start
a
not
process,
you
define
the
letters
or
it
could
be.
Maybe
package
scope
so
like
when
you
put
type
module
in
your
packages
and
all
the
gs
files
under
it
used
no
type
module.
C
B
A
few
years
ago,
when
we
were
working
on
esm
stuff,
there
was
a
lot
of
discussion
of
what
we
were
calling
per
package
loaders.
So
that
was
like.
B
Imagine
you
write
whatever
lowdash,
you
know
as
a
library,
and
you
want
to
say
you
for
say
you
wrote
it
in
typescript,
and
so
you
don't
want
to,
for
whatever
reason
you
want
to
just
like
ship,
the
typescript
to
node
and
have
node
run
those.
So
you
want
to
like
somehow
tell
node
hey,
look
register.
This
register
the
typescript
loader
before
you
run
the
files
in
my
folder,
you
know
or
in
my
package,
and
so
that
was
the
idea
behind
a
per
package
loader.
B
B
You
know
we
wanted
npm
authors
to
like
ship
runnable
code.
We
don't
want,
like
everyone
to
be
shipping,
all
sorts
of
things,
jsx.
Who
knows
what
and
then,
like
you
know
in
your
typical,
you
know:
node
app,
that's
got
a
thousand
pack.
Dependencies
could
have
you
know:
2
000,
loaders,
running
and
that'll,
just
like
ground
the
process
to
a
halt.
So
we
decided
that
that
was
just
not
not
a
good
feature
to
support
of
like
a
per
package
loader
and
then
I
think,
by
by
extension,
you
know
we
wouldn't
want
per
package
configuration
either.
B
You
know
many
of
these
things
are
like
controlling
the
node
process
itself,
which
doesn't
make
much
sense
like
there's
no
way
to
apply
that
just
to
a
a
package,
so
I
think
at
least
at
least
at
first.
We
could
always
extend
in
that
direction.
If
we
just
discover
the
need
to,
I
think,
but
at
least
at
first
knowing
that
history,
I
would
say,
like
you
know
there,
there
is
always
there
is
always
exactly
one
entry
point,
there's
always
exactly
one
package
that
jason
file
if
any
one
or
zero.
B
I
guess
controlling
that
entry
point
in
terms
of,
like
you
know
the
nearest
parent,
package.json
you're,
looking
for
like
say
the
type
field.
B
B
So
I
mean,
I
think,
like
this
idea,
there's
some
merit
into
putting,
especially
if
it's
more
than
just
loaders,
to
group
all
the
config
under
a
namespace
for
sure.
There's,
that's
probably
a
good
idea,
the
so
there
there
is
the
precedent
of
the
like
policies,
file,
which
is
a
separate
file.
The
other.
A
No
well,
it
depends
what
you're
you're
using
so
like.
If
you're
using
own
files,
then
it
uses
the
closest
one
to
the
own
file.
But
then,
if
you're
importing
some
dependency,
then
it
will
try
to
find
that
ones
and
then,
if
it
can't
find
that
ones,
then
it
will
use
own.
B
Little
little
stop
once
it
finds
one
yeah
anyway.
All
I
was
trying
to
say,
though,
was
that
if
we
put
this
inside
package
with
jason,
then
that
might
be
a
good,
a
good
way
to
do
it,
because
that's
not
a
performance
hit,
it's
not
like
searching
for
and
potentially
loading
yet
another
file,
and
I
think.
B
A
B
I
think,
like
the,
if
you
think
about
like
how
are
people
doing
this
today,
I
mean
that's
what
I
wrote
down
here
somewhere
like
the
scripts
field
and
package.json
today
is
the
de
facto
here
are
the
flags
to
run
my
app
with
because
you're
defining
the
commands
to
run
your
app.
So
it's
crazy.
For
me,
this
would
feel
like
the
most
logical
place,
based
on
current
practice
today
and
like
historical
precedent
of
like
a
battlefield
and
a
package
of
jason
and
so
on
and
so
forth,
but
we
could
also
have
a
separate
file.
B
I
I
noticed
like
when
the
whole
bun,
like
thing
came
out
like
one
of
its
like
top-line
features,
so
that
it
has
built-in
support
for
end,
and
I
was
thinking
to
myself.
Why
doesn't
node
just
add
that
to
core
like
I,
I
didn't
bother
searching
for
it
to
see
if
someone
had
proposed
it
over
the
years,
because
I
feel
like.
Certainly
someone
must
have
mentioned
it,
but.
C
I'm
not
sure,
but
because
if
we
put
node
options
in
dot
end
voila,
you
have
your,
then
you
have.
C
It
needs
to
be
deactivated
for
sure,
but
it
needs
to
be
what.
B
A
I,
like
both
options
because,
like
I
tend
to
just
put
all
of
my
my
stuff
into
package.json,
so
if
that
was
an
option,
I
would
choose
that
one
as
a
consumer.
The
like
command
line
options
for
me
is
like,
if
I
have
to.
B
A
Yeah
like
something
I
want
to
change
so
like
it's
going
to
do
this
in
production,
it's
going
to
do
this
in
dev
or
like
there's
some
kind
of
secret
that
is
specific
to
the
development
environment
or
specific
to
the
so
like
it
doesn't,
doesn't
really
seem
the
place
to
add
this
sort
of
stuff.
You
could
and
also.
I
really
would
like
for
node
to
support
like
dot
m
things
natively,
but
yeah.
I
I
would
rather
have
it
in
a
package
json,
because
it's
like
gold,
it's
right
there
we're
already
looking
at
it.
C
C
A
Good
text
take
your
kebab
case
and
snake
case
it
that's
like
what
everybody
does.
If
we
did
something
different,
then
I
think
we
would
need
a
very
good
reason
to
not.
C
Yeah,
but
we
don't-
we
don't
know
yet
what
the
name
of
the
flag
will
be.
We
we're
talking
about
changing
that.
B
A
For
just
and
just
config,
you
have
dash
dash
watch
in
when
you
add
that
to
package
json,
it's
just
watch
true,
so
like
we,
the
these
conventions
are
very
well
established.
We
should
just
follow
them
and
like
there's,
no,
I
don't
see
any
particular
reason
to
not
do
that.
B
A
B
B
C
A
Like
how
do
we
convert
the
can
man
light
options
to
command
line
flags
to
package
json?
I
mean.
C
Well,
probably
only
the
ones
allowed
in
not
not
options.
I
I
will
assume
oh.
B
Yeah,
okay,
yeah
and
they
would
just
be
camel,
cased
and
like
like
antoine,
was
saying:
if
it's
just
a
flag,
that's
on
or
off,
then
it's
like
you
know
it's
just
that
true
I
mean.
Maybe
dash
help
doesn't
make
sense,
but,
like
you
know,
yeah
the
thing
with
true
and
if
it's
true
or
false
and
then
if
it's
something
that
accepts
arguments
like
like
loader,
does
where's
loader,
experimental
loader.
B
Yeah
so
then
it's
just
like
colon
and
then
it's
an
array
of
strings
and
that's
it
and
then
you
would
be
in
a
in
a
a
node
name,
space
or
node.js.
I
don't
know
namespace
sidepackage.json,
and
so
we
like,
when
we
find
on
startup
nodes,
given
the
entry
point
once
it
has
that
entry
point,
it
starts
the
process
of
finding
the
package
that
jason
that's
the
nearest
parent
for
that
entry
point,
and
then
this
is
where
we
inject
this
little
bit
of
extra
logic
of
like
oh
once,
you
find
that
package
of
json.
B
A
Exactly
the
afternoon
check
because
it's
using
it
to
read
the
the
type
property
from
package.json
and
it
to
happen,
yeah.
C
A
Injection,
we
don't
need
to
worry
about
that
yet
because
it
hasn't
read
any
of
these
things
yet
so
when
it's
doing
like
should
use
esm,
loader
or
whatever
it
is,
it
hasn't
instantiated
the
esm
loader
instance
and
hasn't
populated,
hasn't
populated
the
various
loader
collections.
A
So
if
we
add
this
little
bit
here,
we
could
read
them
and
append
them
to
nodes
existing
collection
of
loaders.
So
if
you
specify
some
by
a
command
line,
those
are
already
there
and
then
we
say:
okay
cool
now,
we've
read
package.json
here
are
these
things
smush.
A
I
think
this
should
use
esm.
Loader
happens
very
very
early
in
node.
I'd
have
to
check
for
certain,
but
I
think
this
happens
before
most
things
happen.
C
Well,
okay,
but
javascript
is
already
running
at
this
point,
so.
B
Like
to
treat
it
as
esm
or
comma.js
yet
because
it's
looking
for
the
type
field
so
we're
still
like
very
early
in
the
startup
process,
but
the
process
is
running
it
just
hasn't
it's
somewhere
between
this.
The
process
started
up
and
started
running
user
entry
code,
but
I'm
assuming
the
current
the
current
logic
in
there
for
like
parsing
command
line,
arguments
and
stuff.
That's
all
like
c
plus
plus
logic
that
happens
extremely
early,
so
yeah.
C
B
C
B
C
But
I
don't
think
I
can
do
both
at
once.
We
have
to
start
more.
A
B
B
I'm
just
saying
like
you
should
investigate
that
a
little
bit,
even
if
the
first
version
of
it
only
supports
loaders
like
maybe
these
are
all
things
that
can
be
changed
at
runtime
or
at
least
changed
after
initial
bootstrap,
but
before
user
code
evaluation
you
know
and
then
that's
how
you
do
it
one
of
the
things
that
came
up
the
v
test
team
when
I
asked
them
what
their
like
wish
list
was.
They
wanted
to
be
able
to
change
dash
dash
conditions
at
runtime,
which
I
was
like.
B
C
That's
in
the
right
back
right:
you
can.
B
B
I'm
just
saying
that's
another
option
for
for
how
to
handle
this
is
make
me
make
more
of
these
mutable
at
runtime
all
right
before
we
run
out
of
time.
Why
don't
we
so
antoine?
If
you
want
to
tackle
that,
I
would
love
for
you
to
do
it.
I
I
was
thinking
of.
If
I
have
time
trying
to
look
into
the
I
still
I'm
working
on
those
helper
functions.
B
I
was
gonna,
take
your
advice
and
start
with
just
these,
and
I
don't
know
how
soon
I'm
going
to
do
that.
I
assume
jacob.
This
is
your
next
item.
A
I'm
currently
adding
well
I'm
currently
both
adding
and
tidying
up
esm
tests,
converting
them
from
synchronous.
A
A
Other
I'm
just
thinking
it
might
be,
I
might
need
to
consume
them.
B
A
Yes,
so
I
can
invoke
the
resolver
from
that
bit,
but
I
don't
know
if
I
need
to
call
out
to
those
things
again
and
if
it's
because
I
I
don't
really
know
how
this
is
going
to
work
yet
for
the
offloading
stuff,
and
I'm
thinking
that,
if
I
need
to
like
selectively,
look
up
something
from
package.json,
I
don't
know
why.
But
I
might
that
it
would
be
better
if
they
were
abstracted
or
extracted
rather
than
having
to
like
run
through
resolve
to
get
some
stuff.
B
A
We
can
figure
it
out
inside
of
resolve.
There
is
a
private
function
that
gets
a
whole
bunch
of
information
from
package.json
and
then
resolve
only
consumes
like
two
properties
from
what
it
returns,
and
I
don't
know
if
I
potentially
need
to
access
more
of
the
other
properties
that
it
also
provides.
A
I
just
don't
have
access
to
them
when
it's
a
private
function
inside
of
resolve.
Okay,.
B
All
right,
anyway,
yeah
so
by
the
way,
guy
bedford
knows
a
lot
about
this
and
is
happy
to
help
when
you
get
started
working
on
that
reach
out
to
him.
A
I
think
it
makes
sense
and
like
I
was
thinking
about
async,
hooks
and
performance
hooks
and
stuff.
I
think
we
just
say
like
sure,
fine
they're
already
called
that
whatever
we
all
internally
know,
it
doesn't
really
matter
what
other
people
outside
of
node,
think
of
it
and
then
the
node
flag.
A
B
B
B
C
Yeah,
I
think
if
we
end
up
with
a
confusing
name,
we
might
as
well
keep
loader
and
name
it
loaders
hooks
internally.
B
C
Will
the
flag
be
useful
for
the
attack
on
the
completion
in
the
report.
B
Yeah
because,
like
think
about
what
we
have
now
is
like
this
is
a
loader.
Well,
the
first
two
lines.
At
least
this
is
an
existing
like
loader
file,
so
that
you
know
say
we
add
support
for
customizing
rebel
tab
completion
so
that
it
would
be
like
export
async
function,
replica
complete
and
someone
could
define
a
function
called
that
and
if
that's
you
know,
then
you
load
this
with
like
dash.
B
B
Wherever
we
want
to
give
users
the
ability
to
customize
node,
all
they
have
to
do
is
define
a
function
with
a
specific
name
and
then
node
takes
it
from
there.
It's
like,
okay,
I'm
going
to
run
this
function
at
this
point
like
when
this
happens
internally,
you
know
tab
is
pressed
in
the
repl.
I
will
run
your
custom
reple
tab
completion
function.
A
C
A
C
What
are
we
gonna?
What
I
mean
if,
if
we,
if
we
want
to
read
the
hook
file
or
the
loader
file
whatever,
I
don't
think
we
want
to
read
it
more
than
once
so
we
have
to.
I
think,
if
it's
an
if
it's
of
thread,
we
have
to
keep
it
off
thread
or
we
we.
We
need
to
understand
it
completely.
A
B
I
guess
that's
true,
I
mean
whatever
that's
a
implementation
concern
I
feel
like
well,
not.
A
A
Yeah,
I
think
so,
but
when
we
start
up
the
the
worker
thread
we
can
pass.
So
if
we've
already
read
it,
we
can
pass
the
relevant
like
hooks
or
whatever.
I
forgot
what
it's
called,
but
you
can
hand
things
off
to
the
thread
and
say
like
this
is
now
yours,
so
we've
parsed
it
we
say:
here's
the
load
hook.
Here's
the
resolve
hook,
you
own
these
now.
C
I
don't
think
function
works
because
how
would
you
like,
if
you
have
a
variable
in
the
in
the
module,
you
know
that
you
want
to
access
it.
What.
A
Sorry
he's
saying:
if
it's
all
in
the
same
file,
we
don't
want
to
read
the
file
the
first
time
to
get
the
resolve
and
load
hooks
and
which
are
going
to
be
off.
A
A
C
What
we
named,
maybe
we
need
two
flags
is
what
I
mean
too,
if,
if
we
have
two
different
things,
one
which
is
the
loader
another
thing
that
or
other
hooks,
why
put
it
on
the
same
flag?
If
it
means
we
have
to
parse,
it
twice
now
doesn't
seem
very
efficient.
A
A
B
Functions,
no,
it
doesn't
work
like
maybe
the
maybe
it's
not
functions
at
the
top
level,
but
it's
like
at
the
top
level
is
you
know
something
to
specify
here,
look
over
here
for
the
off
thread
ones
and
look
over
here
for
the
on
thread
ones
and
then
it's
two
other
files
or
two
sets
of
functions
or
something
like
that
transfer
last
year.
B
More
stuff
for
the
user
to
screw
up
because
like
because
typescript
is
going
to
want
both
like
typescript,
is
going
to
want
these
off
thread.
Module
loading
hooks
and
it's
going
to
want.
The
on
thread
ripple
hooks
so
you're
telling
the
user.
Now
that
you
have
to
remember
to
type
both
flags
et
cetera,
et
cetera,.
B
B
B
B
No
because
that's
part
of
user
code,
like
the
other,
that's
where.
C
We
want
the
stack
trace
to
happen
anyway,.
B
B
Well,
but
require
is
part
of
user
code.
I
mean,
like
dash
just
require
importance,
like
that's
like
saying
that,
like
pretend,
my
entry
point
is
my
actual
entry
point
and
then,
in
addition,
put
these
extra
lines
of
code
above
it,
you
know
it's
like
providing
a
way
to
prepend
a
little
bit
of
extra
javascript
source.
C
But
in
terms
of
what
typescript
is
trying
to
achieve
it,
that's
exactly
what
they
want
right.
Well,.
B
B
So
if
it's,
if
your
entry
point
is
the
one
that's
registering
the
pretty
stacktrace
logic,
it
won't
be
registered
before
the
crash
that
happened
in
shuffle.js.
That's
the
that's!
The
big
difference
between
esm
and
common.js
that
people
were
complaining
about
the
summit
yeah,
and
so
that's
that's
the
reason
to
like
you
know.
B
Before
wire
runs
like
in
order
like
say,
because
it's
synchronized.
C
Yeah,
even
before
we
we
start
the
esm
parsing.
C
B
B
I
don't
know
that's
a
good
question
like
is
dash
import
like
does
it
get
awaited
in
the
sense
that,
like
if
say,
I
have
dash
import
and
then
it
like
file.js
and
within
file.js
it
like
registers,
some
custom
logic
for
making
a
pretty
stack
trace.
B
B
I
think
the
thing
is
like
we're
trying
to
provide,
like
intentional
apis
for
the
customizations
that
people
want
to
do
like
yeah.
They
can
do
all
sorts
of
monkey
patching
at
run
time.
They
can
monkey
patch
through
the
resolve
hook,
but
people
don't
like
those
solutions
like
they've,
been
dealing
with
that
for
the
last
10
years,
with
common
js
and
monkey
matching
just
kind
of
sucks.
A
B
A
I
I
feel,
that's
probably
everyone
except
bradley
and
me
to
a
tiny
extent
from
watching
what
bradley
was
doing,
but
I've
seen
him
do
things
in
it:
crazy
wizardry.
That
sounds
exactly
like
or
looks
exactly
like
what
we're
talking
about
here.
B
It
was
yawn
that
made
it.
I
I
it's
in
the
docks
like
what
its
purposes
are.
I
want
to
say
it
was
like
more
for
spoiler.