►
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
A
A
year
old,
so
yeah,
oh
okay,
all
right!
So
I
think
now
we're
recording
hello.
This
is
the
node.js
loaders
team
meeting
for
2021
0709
july
9th.
I
am
jeffrey.
We
have
jacob
and
michael.
I
think
our
agenda
is
pretty
much
the
same.
Every
week
it's
like
what's
going
on
with
jacob's
pr,
as
he's
working
on
well,
basically
like
the
first
three
steps
of
our
roadmap,
consolidating
the
loader
methods
and
and
associated
other
improvements
that
cover
a
lot
of
ground,
so
you
should
take
it.
Take
it
from
there.
B
So
I
have
good
news
and
I
have
bad
news:
let's
start
with
the
bad
news,
so
with
the
loaders
repository
that
you
guys
had
from
before.
B
The
bad
news
is
that
the
coffee
script
loader
that
was
previously
taking
advantage
of
the
difference
between
get
format
and
get
source
that
no
longer
works.
I
think
because
you
because
the
url
that
is
supplied
is
supplied
to
both,
and
previously
it
was
relying
on
them
being
different
and
it
was
kind
of
faking
a
file
that
was
not
real,
and
it
was
then
using
that
to
very
cleverly
trick,
node
js
into
evaluating
the
coffeescript
file
as
a
javascript
file.
B
A
Yes,
so
all
right,
let's
back
up
for
a
second,
I
think
what
would
like
if
the
in
the
exists-
and
I
might
be
completely
wrong-
so
stop
me
if
I'm
talking
about
something,
that's
not
the
issue
you're
describing
so
I
wrote
that
code,
but
it
was
like
two
years
ago,
so
you
know
yeah,
forgive
me
if
I'm,
if
I
screw
any
part
of
it
up,
so
I
think
what
was
happening
was
I
was
I
had
the
case
of
like
it
was
like
import
foo
from
dot,
slash
file.
A
That
coffee
is
like,
say
the
import
statement
and
so
for
the
resolve
part
like
if,
if
there
was
no
loader
at
all,
even
if
say,
file.coffee
was
like
a
zero
byte
file.
Okay,
so
it
actually
would
have
been.
A
You
know,
executable
javascript,
despite
the
file
extension
first
off
node,
would
have
thrown
an
error
because
it
doesn't
recognize
the
file
extension.
But
like
say
we
say
we
disabled,
that
like
say
you
had
a
loader
that
all
it
did
was.
You
know
allow
any
file
extension
and
then
it
doesn't
do
anything
else
or
say
we
actually
took
that
error
check
out
of
node
core,
which
is
something
we
have
discussed
doing
like.
I
think
we've
discussed
maybe
at
least
maybe
when
a
lo
when
a
custom
loader
is
registered.
A
A
A
So
yeah,
so
let's
leave
that
out.
First
leave
that
aside
for
a
second,
I
think
what
it
was
doing
with
calling
default
node
resolve
on
existing
specifier.js,
as
if
it
was
like
dot
file.coffee.js
was
asking
node
like
using
the
default,
require.
You
know,
module
resolution
algorithm.
What
would
this
specifier
have
resolved
to
if
it
were
a
javascript
file
and
node
returns?
Something
and
then
that's
like
what
we
run
with
and
I
think.
A
B
B
Sorry
in
in
get
format,
it
was
specifying
the
sorry
the
it
was
specifying
the
specifier,
as
as
it
normally
is,
and
then
arbitrarily
appending
dot,
js
and
that
caused
nodes
default,
get
format
to
treat
it
as
a
javascript
file,
and
that
then
very
much
down
the
like
in
the
internals
in
the
guts
and
caused
it
to
then
search
for
a
package.json
and
then
was
evaluated.
B
A
B
But
if
you
are
using
package.json
to
specify
this
in
an
esm,
so
if
you're,
using
package.json
to
specify
a
different
type
than
a
parent
or
a
ancestor,
package.json
specifies
so.
Let's
say
in
this
particular
example:
the
project
itself
specifies
esm
and
then
some
descendant
specifies
common
js.
A
A
B
A
Yes,
there
there's
an
open,
it's
either
an
issue
or
a
pr.
I
think
it
might
be
a
pr.
I
can
I'll
find
it
in
a
second.
So
there's
a
there's
a
lot,
there's
a
thread
with
a
lot
of
comments
about
when
we
added
package
exports,
like
the
exports
field,
makes
everything
encapsulated
by
default
so
like,
if
you
wanted
to
so.
A
If
you,
if
you
wanted
to
do,
you
know,
require
foo,
slash
package.json,
you
couldn't
do
that
unless
package.json
was
included
explicitly
in
the
exports
map
and
there
are
build
tools
that
do
that,
like
you
know,
like
oh
for
every
dependency
in
the
package.json
go
do
require
dependency
names.
Flash
packages
are
json
until
I
get
every
dependencies
package.json
file,
and
so
the
authors
of
those
build
tools
contacted
us
and
we're
like
hey.
Can
you
just
create
this
some
exception
in
your
exports
algorithm?
A
Like
yes,
we
understand
that
this,
like
breaks
this
behavior,
that
you
are
relying
on,
but
people
should
be
able
to
keep
that
private
if
they
want
to
like
all
you
have
to
do
instead
is
like
you
know,
do
an
fs
read
fi
like
you
could
still
get
it
through.
Traditional
file
system
calls
rather
than
using
require.
Anyway,
there
was
a
law.
It
was
a
lot
of
back
and
forth
on
that
thread,
so
the
the
short
version
was
the
modules
team
was
like.
A
Why
don't
you
see
what
you
can
do
without
us
making
an
exception
before
we
make
an
exception?
How
bad
would
it
be,
and
then
we'll
think
about
it?
It
was
kind
of
like
the
response,
and
then
they
basically
found
a
solution
and
then
like
it
died
away.
But
there's
like
a
thread
with
like
100
comments.
However,
the
the
the
one
thing
that
did
spin
out
of
that
thread
was
that
people
do
find
it
really
useful
to
have
a
a
node
utility
method
called.
A
I
think
it's
like
get
package
metadata
or
something
like
that
where
given
a
given
a
url
or
or
a
file
path,
at
least
a
url
get
the
controlling
package.json
file
for
that
path.
So,
in
other
words,
just
you
know,
is
there
a
package
json
in
the
same
folder
as
that
file?
If
so,
that's
it
else
keep
going
up
until
you
reach
the
root
of
the
file
system,
and
if
you
you
know
and
return
the
first
package.json
that
you
find
or
if
there
aren't
any,
then
you,
you
know
return
undefined.
I'm
sorry!
A
This
exists.
No,
I
think,
there's
a
pr
to
add
it,
because
there
was
consensus
that
yeah.
This
is.
This
would
be
a
pretty
damn
useful
utility
method
to
have
it's
pretty
small,
it's
very,
very
clearly
scoped,
like
yeah.
We
should
just
add
this
to
core,
because
it's
something
that
node
is
doing
anyway.
You
know
so
like.
A
Let's
just
expose
the
logic
for
finding
the
package.json
file
to
to
third
party
code
to
be
able
to
run
so
there's
a
pr
for
this,
I'm
pretty
sure,
and
we
could
we
could
find
it,
but
it
sounds
like
that
would
be
the
elegant
way
to
rewrite
this.
Where,
instead
of
me
like,
I
was
essentially
using
default,
get
format
as
a
way
of
first
finding
the
controlling
package.json
file
and
then
asking
does
it
have
type
module
or
not.
A
A
I
guess
you
could
collapse
that
into
a
one-liner,
but
like
it's
it's
much
more
explicit
and
less
of
a
hack
than
what's
in
the
example.
Now,
so
that's
probably
the
way
we
should
do
it,
and
then
we
have
the
freedom
to
you
know:
rearrange
these
hooks
and
what's
happening
in
each
hook
without
breaking
these
like
hacks
that
people
might
have
written.
You
know.
A
B
B
A
I
don't
think
it
ever
landed,
I
think
it
it.
It
never
got
finished
or
something
like
they
didn't
write
the
tests
or
something
like
that,
but
I
can
look
it
up
and
and
find
it
and
and
send
it
and
send
it
to
you.
I
can
even
do
it
now.
I
guess.
A
It
wrapped
because
I
don't
there
were
no,
there
were
no
objections
to
like
no
one
was
like.
Oh
this
shouldn't
be
in
core
or
something
like
that.
A
It's
like
there's
just
so
many
damn
tr's
that
it's
like
how
the
hell
am.
I
gonna
find
this.
B
A
Okay,
so
here's
the
here's,
the
at
least
the
thread
where
people
can
are
complaining
about
the
exports
part
of
it
and
if
there's
a
pr,
I'm
sure
would
be
linked
to
from
this.
A
Link
to
from
here
yeah
someone,
someone
created
a
third-party
module
to
solve
this,
and
I
think
and
looks
like
that's
what
a
lot
of
build
tools
have
shifted
to
using,
which
I
think
was
probably
the
idea
that
most
people
wanted
them
to
do.
B
A
That
I
think
that's
why
it
needs
to
be
part
of
the
node
core.
Well,
there
were
two
reasons
that
this
that
this
was
a
good
candidate
for
being
in
core,
as
opposed
to
a
third-party
module.
One
was
it
it
really
needs
to
use
whatever
the
exact
same
module
resolution,
our
algorithm
import
uses,
and
you
know,
and
then
the
only
way
to
ensure
that
is.
You
know
if
there's
some
way
to
call
it
like
there's,
I
don't
think
there's
an
equivalent
in
esm
for
required
resolve.
A
If
I
remember
right
so
so
that's
that's
like
part
one,
and
then
I
think
part
two
was
node
already
has
a
cache
of
every
package.json
file
that
is
used
in
a
module
tree,
like
you
know,
say
from
a
particular
entry
point:
it
loads,
whatever
10
000
files
across
your
prod,
your
app
and
then
your
node
modules,
all
the
way
down
all
of
those
10
000
files.
A
In
the
module
cache
so
having
a
like
get
package
metadata
function
for
that
takes
as
an
argument,
a
particular
file
path.
Node
very
likely
already
has
that
package.json
file
already
cached
in
memory,
because
you're
probably
asking
it
to
look
up
the
package
metadata
of
a
file.
That's
in
your
project,
you're
not
asking
it
for
some
random
file.
Halfway
across
your
you
know
hard
disk,
so
if
it
does
have
it
in
memory,
it
just
returns
it
kind
of
by
definition.
A
No
third
party
package
could
do
that
and
be
as
performant
as
if
it
were
part
of
node
core
and
had
access
to
that
cache.
So
that
was
that
was,
I
think
why
it
was
agreed
like
yeah.
This
should
be
part
of
core,
because
it's
something
that
core
is
already
doing
and
it
can't
be
done
as
well
as
a
third
party
module.
I
think
where
we
left
off.
We
were
just
waiting
for
someone
to
write
it.
I
thought
someone
had
started
it.
A
A
Resolve
package
root:
that's
what
I
suggested
to
be
named,
because
it's
a
url,
not
a
file
path,
so
I
was
like
well
dirt,
doesn't
make
much
sense
because
you're
resolving
to
a
url.
So
here's
the
other
here's
the
another
issue
where
it
was
discussed.
A
So
let
me
look
up
the
open
prrs
for
resolve
package
route,
because
that
I
mean,
unless
they,
unless
they
called
it,
resolved
packager,
but
anyway,
that
that
should
be
able
to.
We
should
be
able
to
find
it
that
way.
A
B
Yeah
sorry,
I
just
thought
bradley's
comment
check
track.
I
think
he
is
among
us.
A
B
A
A
D
A
D
Better
at
five,
it's
fine,
the
only
contention
we
had
really
about
this
package.
There
is
there's
some
confusion
with
redirects
around
it.
There
always
is
honestly.
D
Yeah
actually
worked
out.
I.
D
Describing
the
theoretical
open
pr,
because
there's
disagreement
on
what
happens
so
what's
a
good
example,
I
think
one
was
if
you
use
something
like
you:
import
foo
and
it
redirects
you
to
a
subdirectory
which
contains
a
package
json.
D
A
We
could
well.
This
was
like
get
package
resolve
package
root,
which
was
like
the
folder
that
contains
the
whole
package,
which
is
arguably
a
bigger
scope
than
like,
say
get
package
metadata
because
get
package
metadata
like
that
has
one
answer
like
what
was
the
package.json
that
node
used
for
this.
You
know
for
file.js,
which
packages
json
did
node
use
to
determine
type
module
or
not
like.
A
D
A
A
Well,
why
don't
we
just
reduce
the
scope
and
do
one
that
just
I
mean
I
don't
know
if
we
want
to
reduce
it
all
the
way
to
like
a
function
that
literally
like
returns,
type
module
or
not,
but
like
a
function
that
just
returns
package.json
and
stop
there
and
then,
if
there's
a
you
know,
we
could
have
a
separate
function.
That's
like
return
package
root.
A
I
don't,
I
don't
think,
there's
there's
always
only
one
that
controls
like
for
for
type
module,
for
you
know
for
the
exports
field
for
the
imports
field.
It's
always
like
the
close.
No,
it's
just
it
like
for
a
particular
path.
It
finds
the
controlling
package
of
jason
and
then
that's
the
only
one
it
listens
to.
It
doesn't
merge
that
with
other
ones
farther
up
in
the
tree
or
something
like
that.
Well,.
D
What
this
collapse?
We
don't
flatten,
if
that's
what
you're
asking
so
if
you
have,
for
example,
a
subdirectory
that
has
a
different
type
say:
it's
type,
com
and
js,
but
the
parent
has
exports
and
that's
how
you
actually
get
to
that
subdirectory.
D
A
D
Should
is
not
a
good
word
because
they're
there
are
two
package
jsons
in
play
and
you're
trying
people
people
are
consistently
trying
to
conflate
them
as
a
single
entity.
There's
the
result.
D
The
resolved
form
the
one
you
used
to
resolve.
We
do
not
have
a
re-entrant
resolve
system,
so
there's
only
one
of
those
ever
and
the
type
package
json
there's
only
one
of
those
ever
but
people
are
trying
to
use
this
single
api
to
do
workflows
with
both
and
that
just
doesn't
work
so.
A
A
Otherwise
it
does
dot
dot,
slash
the
thing
and
keep
recursing
up
until
it
either
finds
one
or
hits
the
root,
and
so
I
mean
I
know
this
will
at
least
add
whatever
10
lines
of
code
to
the
coffeescript
example,
but
at
least
like
you
could
move
on
and
not
be
stumped
by
this
and
you're.
Not
you
also
won't
be
blocked
by
having
to
implement
some
other
pr
for
resolve
package
root
or
get
package
metadata
or
whatever
it
ends
up
being.
Since
apparently
I
guess
it's
not
as
easy
as
straightforward
as
I
thought
it
was.
D
A
A
A
A
I
thought
I
thought
we
had.
I
thought
that
the
like
much
more
elegant
way
of
doing
this
was
like
on
the
brink
of
landing,
like
it
was
just
a
pr
that
needed
more
review
or
something,
but
I
misremembered
apparently
so
I
don't
want
to
block
your
pr
on
something,
a
pr
that
hasn't
even
been
written
yet
and
it
hasn't
been
written
yet
because
people
can't
quite
agree
on
the
specifics
of
it,
even
if
they,
if
even
if
they
do
agree
on
the
need
for
something
in
this
general
area.
So.
B
Yeah
that
sounds
good
to
me,
okay,
and
actually,
on
that
related
note.
If
we
want
to
use
this
as
a
sort
of
like
proving
ground
for
loaders,
should
we
move
this
repository
into
or
this
code
into
the
node
loaders
repository.
A
That's
a
great
question,
michael:
what
do
you
think.
A
Initially
thinking
it
would
just
be
like
another
repo
under
node.js,
but
I
guess
we
could
just
move
the
code
itself
into
the
I
don't
know
we
tend
to
not
have
like,
like
the
like.
These
repos,
like
the
loaders
repo
and
the
models.
Repo
are
tend
to
be
just
like
markdown
files
and
that's
all
we
put
in
there
we're
not
mixing
code
as
well
as
that.
C
A
A
C
A
C
A
Yeah,
the
only
thing
I
think
is
potentially
problematic
is
like
there's,
there's
some
of
the
folders
on
that
and
that
that
some
of
the
top
level
folders
in
that
repo
are
for
loaders
that
just
don't
work
because,
like
derek
or
somebody
like
started
it,
but
never
got
it
to
work.
But
maybe
I
could
do
something
like
make
a
top
level.
Folder
called
like
works
in
progress
or
something
and
just
move
them
underneath
that
and
then
it's
clearer
like
don't
expect
these
to
work
and
I
could
add
a
readme,
that's
like
for
each
lo.
A
A
Sure
yeah,
I
don't
know
if
how
respected
that
is,
I
feel
like
that
was
a
deprecated
field
or
something
I
can't
remember
the
details.
C
A
C
A
The
node.js
banner,
like
github,
slash
com
node.js,
I
feel
like
it's
gotta,
have
a
bunch
of
readme
files
or
extensive
readme
that,
like
for
the,
if
the
general
public
finds
this.
You
know
because
like
when
it's
just
under
my
name
like
who
cares,
but.
D
C
C
You
know
and
it's
a
working
repo
same
for
things
like
quick
and
stuff
so
having
enough
documentation,
so
people
don't
get
confused
and
it's
definitely
good
okay,
and
so,
if
you
have
any-
and
I
guess
it's
like
when
you
open
the
admin
repo
and
you
have,
if
you
have
an
existing
repo,
it's
more
of
a
not
a
request
to
create
a
new
one,
but
to
move
this
existing
repo
over,
which
is
just
a
slightly
different,
still
need
to
add.
Like
the
same.
C
C
C
A
B
A
Meeting
at
11
my
time
so
bradley,
thank
you
for
joining.
You
were.
You
came
in
just
in
time
and
michael.
C
A
C
A
A
All
right
so
jacob,
I
guess
let
me
know
if
you
get
stuck
on
anything
else,
but
I
I
look
forward
to
also
by
the
way,
if
you
don't
mind,
just
pinging
me
on
slack
whenever,
because
I
have
a
lot
of
github
notifications,
so
I
feel
like
I
don't
might
not
see
it
quickly
if
it's
only
in
there,
but
please
feel
free
to
every
time.
A
There's
any
update
at
all
for
me
to
look
at
please
ping
me
and
I'm
happy
to
try
to
review
as
soon
as
as
soon
as
you
have
stuff,
but
yeah.
Let
me
know
if
you're
blocked
on
anything
else
that
I'm
happy
to
try
to
work
through
with
you
cool.
Thank.
A
A
B
Cool
the
good
news
is
if
I
change
the
file
extension
from
merely
coffee
to
coffee.js
everything's,
fine
file
extension.
If
of
the
actual
file
yeah,
which
which
of.
A
Course,
wouldn't
quite
be
a
realistic
use,
but
I
mean
that
that
does
tell
you,
though,
that
then
all
you
need
to
do
is
to
solve
to
solve
this
one
problem
of
replace
my
hack
with
a
more
robust
solution,
and
everything
else
seems
to
work.
That's
great
news,
so
yeah
yeah,
so
cool
yeah,.
A
B
I
fortunately
just
did
something
very
similar
for
getty
images,
so
fingers
crossed.
I
can
re
reuse
the
knowledge,
not
the
code,
because.
A
We're
on
a
public
we're
at
a
public.
You
know
youtube
channel
here.
B
D
A
D
Like
yes,
we
do
we
we
do
for
the
same
reason.
You
have
to
worry
about
it
for
data
urls,
there
were
strong
pushback
for
git
format,
so
get
format
doesn't
actually
return
a
valid
mind
type.
So
you
have
to
do
a
mapping
and
core
won't
do
that,
mapping
for
coffeescript,
so
you
will
still
have
to
do
it.
B
What
I
was
wondering
is:
if
bradley's
pr
just
like
natively
supports
https,
do
we
need
a
loader
for
this,
or
will
it
just
like
just
work,
but
it
sounds
like
mostly,
but
so.
D
A
And
again,
it's
just
an
example
like
there's
going
to
be
like
this
is
an
example
realistically
of
loading
from
a
cache
you
know,
or
loading
from
some
arbitrary
other
source.
That's
not
like
what
node's
algorithm
would
resolve
it
to
on
disk,
so
it
could
still
be
loading
from
a
file,
but
like
imagine,
instead
of
it
saying
resolving
https
colon,
whatever
slash
whatever
it
was
yarn
colon,
slash,
slash
whatever,
and
then
it's
like
this
very
similar
loader.
But
it's
like
now.
It's
using
different
machinery
to
like
look
and
yarn
and.
D
A
Cache
to
find
the
file
to
return
it,
like
the
the
example
is
still
pertinent,
even
if
specifically
https
like
becomes
part
of
core.
You
know
like
we
might
change
the
example
to
not
be
confusing.
If
https
is,
you
know,
done
handled
by
core
already
and
then
we'd
have
to
find
like
what
would
be
the
next
most
common
example.
That
would
be
a
good
thing
to
put
in
the
docs,
but
I
think
we'll
deal
with
that
when,
when
bradley's
pr
land,
because
I'm
assuming
it's
still
a
ways
away
right,
probably.
A
A
Yeah,
like
I
wouldn't
want
to,
I
don't
want
to
get
blocked
on
waiting
for
that
to
get
unflagged,
and
now
this
pr
could
be
blocked
for
potentially
months,
because
who
knows
how
I
mean
I
feel
like
that
pr
has
a
good
chance
of
taking
a
long
time
to
get
on
flag
because
of
all
the
implications
of
it.
So,
okay,
I'd
rather
land
yours
this
month.
If
we
can
and
not
have
it
dependent
or
blocked
on
anything
else,
if
at
all
possible.
A
B
Yes,
cool
slightly
outside
the
purview
of
this
conversation
bradley
you
mentioned
the
mime
type
mapping
you
have
to
like
handle.
That
yourself
is
that,
like
some
some
kind
of
argument
that
you
can
pass
and
just
like
pass
in
like
a
custom.
D
D
A
Yeah
I
I
need
to
get
going
though,
but
it's
been,
it's
been
a
pleasure
and
I'll
talk
to
you
guys
soon.