►
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.
This
is
the
july
23rd
2021
meeting
of
the
node
loaders
team.
I
am
just
looking
for
the
document
again
to
put
the
youtube
link
in.
A
Didn't
seem
to
manage
to
copy
it.
Oh
well,
we'll
find
it
later
all
right.
So
I
think
the
only
one
thing
on
the
agenda
so
far.
I
took
off
that
like
discussion
thread,
because
we
haven't
been
discussing
that
and
I
don't
think
we
need
to
discuss
that
any
further,
so
there's
jacob's
pr,
which
we
should
talk
about,
there's
anything
else
that
should
run
on
the
internet
before
we
get
started
diving
into.
B
That,
just
in
some
corollary,
pr's
we're
having
some
problems
with
error
messages
and
we'll
get
to
that.
When
we
talk
about
consolidating
error
message
specific
to
like
loader
hooks
or
specific
to
loader
hooks,
we
have
some
data
loss
through
the
git
format
hook
because
we
normalize
data
to
that
enumeration,
rather
than
just
preserve
it.
A
It
okay
cool
anything
else.
Any
other
topics
to
put
on
in
general.
A
All
right
so
jacob
the
I
saw
a
pr
review
request,
but
it's
a
draft
pr
for
the
like
up
for
that
other
repo.
Then
oh,
so
I
forgot
to
do
this.
I
need
to
let.
A
Regardless
of
where
what
github
org
it's
in,
though
you
obviously
have
access
to
it,
so
I
can
move
it
whenever,
but
so
yeah
so
jacob's
been
working
on
the
that
jeffrey
booth,
slash
node,
voters,
repo
to
try
to
update
the
the
two
like
working
loaders
that
are
in
there
that
are
the
same
two
that
are
in
a
docks
for
esm,
like
the
the
node
esm
docs
for
the
coffee,
script,
loader
and
https
loader.
So
the
idea
was
like
with
on
under
his
new
branch,
which
is
almost
done
or
might
be
done.
A
If
we
once
we
finish,
testing
it
to
update
the
loaders
in
this
repo,
which
are
which
are
working
examples
for
current
node
update
them
to
work
under
his
new
branch.
That
way,
we
confirm
that
his
new
branch,
like
still
works,
and
then
this
gives
us-
we
just
copy
paste
the
code
from
here
into
the
docs
to
update
the
update
those
examples
in
the
docs.
A
So
I
saw
that
you
started
working
on
it,
but
it
seems
in
progress.
Do
you
want
to
fill
us
in
on?
What's
going.
C
On
yeah
sure,
so
I
pushed
another
commit
somewhat
recently
a
few
days
ago,
I
think,
with
the
like
packaged
json
crawler
that
we
had
talked
about
in
the
last
meeting
and
that
is
working.
It
is
now
correctly
identifying
the
different
kinds
of
coffeescript
modules
as
common.js
or
esm
and
all,
but
one
of
the
tests
that
existed
in
the
repository
before
are
passing
the
one
that
is
not
is
where
this
it's
one
of
the
coffeescript
common
js
modules.
C
C
Oh,
I'm
not
sure
I
I
could
go.
A
We
might
want
to
test
that
because
I
I
think
that
the
whole
like
get
format
returning
type
common
js,
I
think,
has
never
worked.
So
I
think
that
that
might
have
been
a
test
in
there
that
you
know
was
kind
of
like
this
test
should
pass,
and
the
fact
that
it
doesn't
is
like
more
a
bug
in
node
than
something
wrong
with
the
loader.
A
But
if
it
doesn't
pass
in
current,
you
know
like
the
current
node
main
branch,
then
you
know
maybe
kick
that
to
a
follow-up
of
like
we
need
to
fix
that
in
both
you
know,
both
in
current
node
and
once
we
merge
your
pr
and
because
I
think
that's
a
separate
thing
that,
like
I
think,
riley
was
talking
about
this
about
like
if,
if
the
loader
returns
comma.js
as
the
format,
all
sorts
of
other
complexity
needs
to
happen
to
like
kick
it
into
the
command.js
loader
and
all
that
stuff
right.
Something
along
those
lines.
B
They're
related,
we
could
probably
split
that
fix
out.
I
think,
because
that
would
probably
be
a
fix
that
gets
backported
and
they're
not
gonna,
be
thrilled
to
backport
it.
If
it's
in
this
big
pr.
A
Okay,
yeah
opal,
if
that's
all,
that's
blocking
you
yeah,
just
maybe
you
know,
you
know,
check
out
the
main
branch
on
the
loader's
repo
and
then
run
it
against
current
node
and
see
if
that
test
pass
is
there?
I
bet
it
doesn't
because
I
remember
something
about
that
being
an
issue
so.
C
I
can
run
that
right
now
in
the
background.
While
we
discuss.
A
C
If
we
say
it's
acceptable,
if
it
fails
in
the
current
node,
then
it
is,
I
think,
good
to
go.
I
was
checking
the
the
tests
in
the
node.js
repository
itself
to
see
this,
because
it
has
many
for
common
js
stuff
in
esm
and
for
many
of
the
cases
those
tests
are
all
passing
and
I
noticed
in
one
in
particular,
it
said
that
some
named
exports
of
common
js
modules
don't
work
and
like
they're
not
supposed
to
work.
So
I
was.
A
A
I
don't
think
there
are
any
tests
and
node
regarding
loaders
where,
like
format
commonjs
is
returned,
because
I
think
that
just
always
fails
right
now,
like
that's
just
like
unimplemented
an
unimplemented
feature,
you
think
it
it
should
be
allowed
it
well,
it's
something
we
should
support
yeah,
but
it's
just
like
no
one's
gotten
it
to
work.
Yet
I
don't
think
I
mean
I.
B
A
B
B
A
So
I
would
say
jacob
if,
if
it,
if
that
test,
doesn't
work
in
current
node,
then
maybe
just
if
you
don't
mind
adding
a
comment
to
that
test
in
the
repo
saying
that
like
we
need,
you
know
this
doesn't
work,
we
need
to
come
back
and-
and
this
is
like
few
you
know-
maybe
we
should.
A
A
Upstream,
do
you
mean
moved
into
the
node
repo?
Yes,
so
we
can't
move
this
stuff
into
the
node
repo,
because,
like
it,
this
example
is
like
the
coffee
script,
loader
it.
It
depends
on
copy
script
itself.
So
I
didn't
want
to
like
have
to
add
the
whole
coffee
project
into
like
the
node
repo.
So
that's
why?
It's
just
in
a.
B
A
A
And
yeah
I
mean
if
it
it
could
also
go
and
canary
in
the
gold
mine,
but
there
are
four
example
loaders
in
here,
but
only
two
of
them
work.
I
think,
like
the
other
two
were
kind
of
in
progress
things
that
derek
and
somebody
else
started
so
yeah.
I
don't
know
I
mean
we
don't
have
to
do
this
in
the
short
term.
It's
just
eventually
yeah
we
we
could.
Maybe
we
could
talk
about
this.
A
I
don't
want
to
like
just
distract
from
jacob's
work,
so
we
can
talk
about
moving
repos
around
and
cleaning
them
up
later,
but
I
think
in
terms
of
getting
this
work
done
for
to
land
your
pr
jacob.
I
think
if
it,
if
that,
assuming
that
that
assuming
we
could
just
ignore
that
test,
if
you
wanted
to
add
a
comment,
so
we
don't
stumble
on
it
again
or
mark
it
as
flaky
or
whatever.
A
So
we
don't
stumble
on
it
again,
then
I
would
just
say
you
know,
get
rid
of
the
debugging
stuff
like
the
console
log
statements
and
because
we
need
to
copy
paste
this
loader
into
the
docs.
A
It
should
all
be
one
file
so
like
that
separate
file
that
you
made
for
the
package.json
tree
search
thing:
let's
just
move
that
function
into
this
file,
so
that
we
can
then
copy
paste
this
file
into
the
into
the
docs.
If
you
don't
mind.
C
Okay
sure-
and
I
just
ran
it
in
the
background
of
this
checking
out
the
master
of
that
loaders
repo
and
the
same
test-
does
fail.
A
C
I
think
I
just
need
to
change
the
names
of
like
consolidate
these
two
things.
It
doesn't
look
like
anything.
I.
A
C
A
A
Have
these
examples
and
someone
else
has
reviewed
the
code,
so
it's
probably
already
fine
I'll
do
my
own
path,
but
I
doubt
I'm
gonna
find
anything
that
that
they
didn't
find
and
I'll
just
try
running
it
just
to
double
double
check
and
then
yeah.
If
stephen
and
bradley,
if
you
guys
have
any
time
to
code
review
the
pr
itself,
I
would
appreciate
it
because
I
feel,
like
you
guys,
know
this
stuff
better
than
I
do.
A
Thank
you
yeah,
so
I
guess
other
than
updating
the
the
examples
and
the
docs
and
the
re
in
the
pr
is
the
rest
of
the
pr.
I
guess
final,
like
you're,
not
planning
on
making
any
more
changes.
Jacob.
A
Oh
something
revealed
by
running
these
two
examples.
You
mean
yeah,
okay,
cool,
then
we're
very,
very
close.
So
I'm
excited
yes
and
let's
yeah,
I'm
sorry.
This
has
been
hanging
forever.
It
looks
like
it's
trying
to
figure
out
how
to
do.
I
mean
you've
gotten
less,
like
three
fifths
of
the
way
through
our
roadmap,
so
you
know
hooray
for
that,
but
let's
maybe
try
to
do
the
other.
Two
bullet
points
says
two
at
least
two
vrs
yeah.
C
C
Oh
actually,
I
did
have
related
to
that.
I
did
have
a
question
for
bradley.
I
was
we
had
a
chat
in
slack
that
you
probably
have
well
forgotten,
because
I
think
it
was
like
a
week
ago
and
I
figured
it
would
be
easier
to
talk
about
it
in
person
you're
asking
about
global
pre-load
code
and
that
running
before
other
hooks
and
stuff,
and
I
wasn't
entirely
sure
what
you
meant
to
you
mentioned
that
the
parents
preload
code
would
need
to
run
before
any.
Like
child's
other
hooks.
C
I
think
that's
how
it
just
works,
but
you
seem
to
be
thinking
something
else
and,
like
you,
obvi,
like
you,
you're
quite
well
versed
in
this,
so
it
was
making
me
think
like.
I
was
not
understanding
what
you
were.
You
were
telling
me.
B
So
I
think
that
was
a
different
topic,
but
you
were
mentioning
earlier
that
what
if
we
expose
not
just
the
current
hook,
but
also
other
hooks
from
the
parent
that
you
can
call
into?
Oh.
C
Yes,
that
in
the
load
hook,
instead
of
having
one
of
the
arguments,
be
node's
default
load
hook
that
it
would
instead
expose.
I
don't
know,
like
an
array
or
something
that
would
contain,
get
format
and
get
source
instead
of
the
the
consolidated
one,
because
that
was
causing
a
problem
for
coffeescript,
which
was
trying
to
leverage
node's
get
format
but
was
running
a
foul
of
get
format
and
get
source
being
tightly.
Coupled
now,.
A
C
But
like
I,
I
think
I
think
it's
kind
of
like
a
legitimate
thing
to
try
to
leverage
and
like
if
we
can
do
it
and
it's
not
like
bad
and
then
and
it's
just
like
a
choice
of
doing
it
or
not
doing
it.
Then
I
think.
A
What's
in
its
cache
versus,
like
kind
of
by
definition,
anything
that's
third
party
would
have
to
search
the
file
system.
It'd
be
a
lot
slower,
so
I
feel
like
that,
should
be
a
utility
function
that
we
should
be
able
to
like
get
you
know
approved
in
in
theory
and
then
land.
If
we
get
a
good
design
for
it
or
bradley.
Do
you
see
any
issues
with
that.
B
I
mean
I
there's
a
big
discussion
on
core
about
it.
There,
a
lot
of
people
who
say
get
the
right
package
json
and
they
disagree
on
which
is
the
correct
package
json
to
return
meta
data
about
because
there
are
two
package
jsons
generally
there's
one
for
the
resolution
and
then
there's
another
one
for
the
type
and
those
can
be
two
different
ones
and
everybody
wants
one
to
be
the
correct
one.
So
that's
the
main
problem:
why
are
they
different?
B
B
C
C
C
B
B
A
B
B
Metadata
package:
oh
gosh:
where
is
this
thing?
How
do
I
search
for
commenter.
B
A
Well,
anyway,
when
you
find
it,
if
you
want
to
share
it,
I'd
like
to
read
it,
but
also
like
I'd,
stop
blocking
this
pr
like
it
would.
It
would
enable
you
to
like
take
out
this
helper
function,
that
you're
writing,
and
I
think
it
would
be
useful
like
it's
something
that
belongs
in
core,
I
think
in
general,
but
we
can
do
it
whenever,
like
it's
just
a
it's
just
a
way
to
help
people
avoid
writing
some
boilerplate
and
it's
like
a
little
performance
hit.
B
Oh,
that's
because
it's
in
the
old
modules
repo,
that's
why
there
that
one
you
will
see
throughout
this!
I
consistently
ask
which
package
meditate
is
the
correct
one
there.
This
is
the
final
thing
that
happened.
There
were
a
variety
of
things
that
led
up
to
this
issue
thread.
If
you
really
want
to
try
to
spider
backwards.
B
It
looks
like
in
the
end
I
just
kind
of
conceded
something
and
then
never
got
back
to
it,
but
there
are
two
different
package.
Jsons
is
the
problem.
B
That's
a
different
thing:
that's
where,
if
you
try
to
import
package.json
within
a
bear
specifier,
it's
always
approved,
you
cannot
prevent
people
from
importing
your
package
json.
Oh.
B
A
A
A
Well
right
I
mean,
but
you
can
I
mean,
but
that
was
always
the
case
even
with
exports
like
from
the
beginning,
it
was
like.
Well,
you
can
always
use
the
fs
you
know,
rather
than
using
require
you
can
use
fs
to
just
like
load
any
file
on
the
file
system,
and
so
it's
just
on
you
to
figure
out
where
that
file
is
like.
You
somehow
need
to
find
the
package.json,
and
then
you
can
use
fs
to
find
it,
and
so
we
were
talking
about
making
like
helper
functions.
A
That's
like
get
package
root,
or
something
like
that
to
that
would
tell
you
like
the
folder
that
contains
the
relevant
package
json
but
yeah
to
bradley's
point.
If
there's
two
relevant
packages,
then
that
gets
a
lot
more
complicated,
so
yeah.
Maybe
we
just
make
two
apis
that
return
the
actual
contents
of
the
packaging
itself,
and
then
we
can
return
each
one
and
then
that's
also
better
than
returning
like
the
path
to
the
folder,
because
then
it
like
loads
already
noted
that
loaded
the
contents
in
memory.
B
Currently,
we
strip
down
the
data
to
only
things
node
interprets
we
could
just
give
them.
I
think
that's.
Okay,.
A
No,
I
mean
I
could
easily
see
someone
being
like.
Oh
well,
there's
a
vowel
configuration
eslim
configuration
or
whatever
other
configuration
in
the
packaging,
and
so
they
want
the
package
jason
to
be
able
to
find
that
we
could.
Just
I
mean
if
that's
all
we
have
cached,
we
probably
at
least
are
caching
the
absolute
path
to
the
package.json.
So
maybe
we
do
yes.
A
B
You
know
yeah,
that
seems
fine,
eventually,
they'll
probably
want
other
methods
returned
like
how
to
resolve
against
another
package
and
stuff,
and
we
can
just
work
from
there.
A
B
Prs
so
we
I
opened
another
pr,
oh,
what
was
it
which
one
was
this
this
one
was
the
https
pr:
the
ability
to
import
https,
our
current
loader
hooks
normalize,
git
format
into
an
enumeration
of
well-known
things
or
no.
A
B
Yeah,
okay,
but
we
we
use
of
random
strings
effectively,
to
name
them
and
so
in
https
and
when
you're
trying
to
propagate
stuff,
you
can't
really
propagate
errors
about
the
format,
because
the
git
format
hook
has
to
return
one
of
those
strings,
and
so
when
it
returns
null
as
the
error,
condition
and
stuff
like
that
or
if
it
sees
javascript,
you
lose
it.
You
lose
the
actual
original
type
because
it's
been
normalized
before
it's
passed
to
the
checks
because
it
has
to
be
normalized
because
that's
the
api
contract
we
had.
B
A
A
Because,
like
it's
been
proposed
that
he
get
one,
but
you
know
people
including
me,
have
blocked
it
because
because
of
this
he
can
see
he
continues
to
veto
things.
He
doesn't
like
and
never
compromises,
and
so
we
were
like
look.
We
need
some
way
to
like
overrule
him
he's
going
to
be
difficult,
so
I
guess
maybe.
B
It
just
happened
without
when,
when
the
hooks
are
consolidated,
this
isn't
too
much
of
a
problem.
I
think,
but
if
you
split
them
out
again
like
what
we're
talking
about
with
slack,
this
problem
exists.
B
So
I
don't
know
what
we
want
to
do
once
we
have
multiple
loaders.
If
we're
going
to
go
down
that
route,
it'll
have
the
same
problem.
Well,.
B
Merging
together,
but
like
jacob
was
saying
like
when
you
have
in
slack
the
desire
to
separate
out
the
pieces
of
metadata,
you
want
to
call
the
individual
bits.
A
B
A
A
B
B
If
dynamics
not
involved,
that
would
just
leave
like
worker,
threads
and
stuff
like
that,
where
it's
acting
like
a
whole
environment,
so
yeah
just
throw
an
error
and
it
works.
Fine,
you
can
catch
it
in
some
situations.
Is
the
point
right,
I'm
like
right.
I
mean
if.
A
Someone
wants
to
catch
it
then
fine,
not
like
trying
to
prevent
them
from
doing
so,
but,
like
I
guess,
the
question
is
like
what
are
you
trying
to
achieve
in
terms
of
like
you're
trying
to
make
a
good
like
a
useful
error
message
for
when
this
exception
is
thrown?
In
other
words
or
what's
the
what's
the
goal.
B
So
the
problem
is
the
decoupling
of
interpretation
from
formats,
so
you
can
have
http
suddenly
allow
coffeescript,
for
example,
because
you
return
content
type
coffeescript,
that's
not
in
our
special
enumeration
in
any
way,
and
so
it
has
to
be
detected
somehow
when
you
get
to
picking
the
translator
used.
B
B
So
we
don't
know
that
that
mime
is
invalid
at
the
end
of
git
get
format,
so
we've
lost
the
data
for
what
the
original
mime
is,
because
we've
translated
it
to
something
else.
But
we
do
know
that
it.
We
can't
get
an
actual
source
translation
of
it
because
it
doesn't
map
to
anything
it
doesn't
map
to
one
of
those
five
well-known
types
after
running
the
loader
hooks.
So
I
know.
A
B
This
this
would
solve
our
problem
to
some
extent,
but
the
problem
is
going
to
be
once
you
get
to
multiple
loaders,
then
you
have
the
data
loss
again,
where,
if
you
have
a
single
https
loader
and
it
maps
dot
vnd,
slash
coffee,
I
don't
know
what
the
general
mime
for
coffee
used
is
yeah
if
it
matters
to
like
the
string,
coffee
script.
C
B
C
Planned
what
are
the
things
we
have
planned
for
or
to
add,
when
a
hook
chaining
becomes
a
thing
is
to
surface,
which
hook
contributed
to
this
particular
thing.
So,
like
add
it
to
the
error
message
or
the
stack
trace
or
something.
B
C
B
You've
taken
a
mime,
something
that,
like
a
user,
can
see
on
the
network
like
this
is
a
thing
they
can
debug
it.
They
can
find
it
in
particular.
They
can
find
it
is
the
important
part,
but
with
our
api
we've
said,
you
can't
really
use
that
string.
You
have
to
map
it
to
this
this
other
stuff,
and
so
we're
going
to
lose
that
information
of.
What's
on
the
network,
we're
going
to
map
it
to
something
else,.
B
B
A
B
B
B
A
A
B
A
B
A
So
all
four
of
those
have
standard
mime
types
that
we
could
choose.
You
know
if
jordan
becomes
a
blocker
on
this,
we
could
bring
it.
We
could
just
bring
it
up
to
the
tsc,
I
guess
and
overrule
them.
I
suppose.
C
I
just
checked
the
list
he's
not
in
the
list
of
contributors
or
on
tsc.
B
A
He
had
vote
in
the
modules
team,
but
when
we
kind
of
dissolved
the
models
team,
there
was
discussion
of
whether
whether
he
should
be
made
a
core
collaborator
or
not,
and
basically
it
was
like
hey.
He
was
a
problem
on
the
models
team.
He
forced
us
to
take
votes
on
things
when
we
were
trying
to
operate
on
consensus
like
and
he
doesn't
seem
to
have
really
changed
in
terms
of
like
his
way
of
operating.
A
He
could
add
a
lot
of
friction
to
you
know.
Making
things
happen
that
people
want
to
make
happen
on
pr's
in
in
core.
That
was
part
one.
The
other
part
was
like
well
he's
not
contributing
any
code,
so
does
he
need
the
bit
like
all
it
would
enable
him
to
do.
Is
block
other
people,
so
it's
sort
of
like
you
know
he
can.
He
can
certainly
give
he.
He
gives
voluminous
feedback
already.
There's
nothing
stopping
him
from
continuing
to
do
so.
So
it
was
like
it
just
doesn't
need
it
for
anything.
A
So
I
think
that's
where
we
landed
and
then
it
just
got
tabled.
You
know
I'm
sure
it'll
get
revisited
at
some
point
in
the
future,
but
at
least
as
of
whatever
a
year
or
two
ago.
That
was
like
the
discussion.
A
So
anyway,
I
mean
look
he'll
still,
voice
strong
objection
on
to
the
pr
on
when
it's
opened
on
core.
He
might
even
put
like
a
request,
changes
review
on
it,
and
someone
will
have
to
point
out
that
since
he's
not
the
core
collaborator,
it
doesn't
matter
that
he's
blocking
it.
I
don't
know
we
can
deal
with
that.
When
it
happens,
I
mean,
I
guess
the
bigger
question
is
like.
Are
there
any
other
people
who
also
agree
with
him
on
this?
A
B
I
know
jan
krimz
was
not
thrilled
at
the
idea.
I
think
those
were
the
two
big
ones.
I
don't
remember,
but
I
feel
like
there
was
something
with
jdd
in
it.
That
was
a
long
time
ago.
I
don't
think
he's
gonna
care,
that's
all.
I
can
remember.
A
I
mean
I
would
say
that
could
be
a
standalone
pr
to
just
rename
these
five
strings
to
mime
types.
Well,
I
don't
know
what
you
would
do
for
built-in.
The
mime
type
for
common
js
is
application.
Node,
which
sounds
like
it
should
be
the
mime
type
for
built-in.
So
you
might
get
some
people
complaining
that,
like
you,
have
four
mime
types
and
then
the
string
built
in
like
this
might
not
be
any
less
confusing
than
what
we
have
now
wait.
You
said.
A
A
Just
on
pure
dx
confusion,
so
I
don't
know
but
yeah
I
would
say
like
that,
could
be
a
standalone
pr
and
then
that
pr
could
be
the
lightning
rod
for
every
anyone
to
argue
about
this
and
I'd
say
before
we
even
worry
about
jordan.
There
might
very
well
be
other
people
who
complain
and
it
might
be
something
where,
like
we
have
to
make
an
argument
for
why
this
is
better
than
the
current
like
yeah.
Maybe
this
isn't
perfect
in
terms
of
like
it's,
not
you
know,
yeah.
A
We
can
think
of
reasons
why
people
could
be
confused,
but
also
the
current.
The
status
quo
has
these
other
issues,
and
so
it's
like,
which
is
the
least
bad
option.
You
know
I
feel
like
that
could
be
where
that
would
be.
I
would
imagine
that's
where
the
conversation
will
go.
So
if
you
want
to
start
that
argument
feel
free,
I
would
maybe
wait
until
jacob
lands.
This
pr
but
yeah.
C
In
favor
I
just
had
to
look
back
on
what
my
opinion
was.
I
liked
the
idea
I
was
like
this
convention
exists
and
it's
working.
So,
let's,
let's
do
it
yeah
well
note:
built-ins
are
written
in
c
right,
no.
C
A
A
Okay,
yeah,
but
not
necessarily
all
of
those
wrappers
have
native
c
underneath,
like
I
bet,
some
of
them
are
just
javascript
and
that's
it.
Yes,
okay,.
B
C
A
I
was
looking
forward
to
registering
cjs,
you
know
because,
like
I,
I
came
up
with
that
file
extension
in
the
models
group
and
then
I
was
like
oh
man,
I'm
gonna,
I'm
gonna
put
my
name
and
internet
history
by
like
adding
it
to
the
mime
registry,
and
then
I
get
there
and
I
think
bradley
already
registered
it
like
three
years
prior
damn.
It.
A
B
B
A
Oh,
I
think,
because
you
don't
register
the
thing,
is
you
don't
register
extensions?
You
read
some
mind
types,
so
I
think
bradley
had
registered
application
node
in
like
2015
or
something,
and
so
it
would
have
just
been
adding
adding.cjs
to
the
list
of
extensions
that
yeah.
A
C
Okay,
could
we
create
some
like
piggyback
off
of
that
and
say
like
application,
node
like
core
built-in
or
something
and
then
just.
B
A
C
Actually
yeah,
you
would
never
use
this
in
a
situation
where
you
would
have
ambiguity
right,
like
someone
would
be
explicitly
saying
this
is
node
colon,
something
something
or
it
would
be
in
some
scenario
where
we
would
be
able
to
determine
this.
A
B
A
I
mean
we
could
just
leave
it
as
a
special
case
where
it's
that's
the
one.
That's
not
a
mime
type
because,
like
built-ins,
are
a
special
case.
You
know.
B
B
A
C
Cool
I'll,
hopefully
have
the
updates
to
the
https
node
loader
example
thing
in
the
very
near
future
I'll
send
that
off
and
then
I'll
remove
those
like
debugger
stuff
from
the
common
js
one
and.
A
C
A
And
if
you
don't
mind,
just
painting
on
the
slack
on
the
esm,
slash
manual
or
being
directly
on
the
the
node.js
slack,
just
yeah,.
B
A
Sure
I
don't
miss
the
github
notification.
Maybe
grab
me
two
if
he's
gonna
look
at
it
next
week,
just
let
us
know
when
it's
ready
to
review
yeah.
C
Sure
I've
been
having
a
bit
of
trouble
with
slack
over
the
past
few
days.
I
don't
know
because
I
tried
to
send
bradley
a
message
and
it
just
failed.
A
Okay,
anyway,
I
don't
wanna,
I
don't
wanna
miss
your.
I
don't
wanna
like
miss
a
github
notification
and
receive
notifications
on
your
waiting
week
for
me
so
yeah,
please
please
reach
out.
I
might
not
be
able
to
do
the
review
like
that
day.
Necessarily
but
at
least
then
you'll
know.
I
know
it's
on
my
plate.
So
right.