►
From YouTube: Node.js Foundation Modules Team Meeting 2018-07-11
Description
A
Hello
and
welcome
to
the
2018
July
11th
meeting
of
the
noches
modules
came.
We
had
12
participants
and
a
feedback
loop
going
on.
Today
we
have
an
agenda
of
different
items.
We
are
running
a
little
bit
behind
time,
so
we
may
need
to
shave
some
time
off
of
some
of
those
items,
but
in
the
meantime,
let's
kick
it
off.
Is
there
anyone
from
the
group
that
we
have
right
now
who
can
volunteer
to
take
notes?
A
A
Thank
you,
I'm
dropping
the
dock
link
into
the
chat,
everyone
who's
on
the
call
right
now,
if
you
could,
please
add
your
name
to
the
attendance
list
inside
of
that
dock.
This
is
the
only
way
that
we
know
that
you
actually
showed
up
aside
from
cross-referencing
against
the
video.
So
this
week
we
do
not
have
any
outstanding
pull
requests
to
review
as
a
team.
All
the
flow
requests
right
now
or
either.
You
know
don't
have
consensus
within
the
pull
request
itself
or,
alternatively,
we're
looking
at
things
that
are
just
editorial
changes.
A
There's
a
couple
things
to
just
update
on
progress.
We
have
these
set
for
three
minutes
each,
but
maybe
we
can
shorten
this
down
to
even
shorter.
First
issue
is
number
135
to
have
a
presentation
about
loaders,
Brad
I.
Believe
that's
yours.
Can
you
quickly
just
give
people
an
update
on?
What's
going
on
with
that.
C
I'm
not
entirely
sure
I
kind
of
thought.
We
would
be
doing
it
during
one
of
these
meetings,
but
these
meetings
have
been
kind
of
jumbled
around
with
summer
vacation.
So
maybe
we
should
schedule
it
for
a
different
time.
The
main
concern
here
is
we
are
using
a
lot
of
terms
and
things
and
we
are
not
really
clearly
defining
what
we're
talking
about.
C
So
things
have
miscommunications
or
unknown
meanings
and
I
wanted
to
fix
that
for
loaders,
because
people
seem
to
be
leaning
heavily
on
them,
but
not
talking
about
what
they
are
so
maybe
next
week
or
the
week
after,
we
can
have
a
presentation
but
I
I,
don't
really
want
to
discuss
a
lot
of
what
we're
discussing
about
using
loaders
without
at
least
coming
to
an
understanding
across
the
working
group
on
what
they
are.
So,
okay.
A
A
D
D
I
honestly
tried
to
do
it
and
I
think
people
thought
I
was
overkill
and
to
balance
things
off,
I
think
the
initiative
itself.
The
initiative
itself
is
something
I
can
keep
track
with
and
and
keep
on
working
on,
but
the
actual
definitions
and
the
structure.
This
has
to
come
from
people
who
actually
know
the
terms
well
and
people
who
maybe
need
certain
terms
defined,
and
then
it
becomes
the
best
person
to
address
a
term
is
able
to
answer
that
either
in
a
doc
or
through
the
issue.
D
A
We
don't
have
volunteers
right
now
and
we
need
to
move
forward
so
I'm
really
busy
for
the
next
week
or
two,
but
after
I
kind
of
two
weeks
from
now
I'm
more
than
happy
to
spend
some
time.
Otherwise,
if
anyone
else
from
the
group
and
help
review
that
dock
and
fill
things
in,
that
would
be
hopeful
I'm
who.
A
The
next
one
that
we
have
up
is
the
developer
survey.
This
is
something
that
I
brought
up.
We
haven't
really
dug
into
it.
I
think
would
be
really
good
for
us
to
put
together
a
survey
and
put
it
out
to
developers.
One
thing
I've
been
thinking
about
regarding
it
is
like
whether
or
not
we
should
be
doing
an
open
survey
to
the
entire
community
or
whether
we
should
be
trying
to
pull
specific
stakeholders
such
as
maintainer,
zip,
Babel
or
web
hacker.
A
Like
the
big
thing
for
me,
is
we
make
broad
statements
sometimes
making
assumptions
about
what
people
or
groups
or
stakeholders
want
and
I
would
like
to
essentially
go
and
like?
If
we
have
assumptions
about
what
stakeholders
want,
I
would
love
to
see
some
data
to
prove
out
that
it
isn't.
You
know,
just
an
assumption
or
an
anecdote,
but
we
have
some
stuff
there.
I
guess
you
have
your
handout.
A
Gus
going
once
going
twice,
they
gonna
lower
your
hand.
There
I'm
gonna,
assume
that
you
don't
have
something
to
add
right
now.
Let
me
know
if
I'm
wrong,
but
so,
if
anyone
wants
to
pick
up
running
with
that,
just
let
me
know.
Alternatively,
you
know
on
a
similar
timeline
to
the
other
stuff
when
I
have
a
little
more
free
time,
I'll
be
digging
into
that.
But
maybe
this
is
the
kind
of
thing
we
could
be
thinking
about.
When
we're
framing
some
of
our
bigger
conversations.
A
A
Let's
try
to
stick
to
the
10-minute
time
boxes
that
we
have
set
up
and
we
may
just
have
only
10
minutes
or
transparent
intro,
but
if
we
can
gain
extra
time,
let's
use
it
so
kicking
off
the
first
one
is
thinking
about
deadlines,
and
maybe
this
is
where
we
can
get
back
some
of
that
time.
I'm,
just
gonna
leave
it
to
the
floor.
Have
people
been
thinking
about
these
deadlines
at
all?
Do
you
think
that
some
of
the
deadlines
that
we're
talking
about
are
reasonable?
A
C
I,
don't
think
the
deadlines,
at
least
the
dates
we
have
them
at
issue
are
reasonable.
Given
our
current
pace
and
I,
don't
think
we
are
going
to
achieve
that
pace.
Even
if
we
do
a
much
more
streamlined
approaches
to
things
we're
talking
about
expanding
our
scope,
constantly
expanding
the
communication
channels
and
every
time
we
do
that
it
takes
time
and
I,
don't
think
we
can
get
close
to
those
states
and
I
think
we're
getting
further
away
from
them.
Instead
of
closer.
E
I,
don't
like
the
idea
of
deadlines
here
at
all
I
think
the
point
of
this
group
is
not
to
ship
modules
quickly.
The
point
of
this
group
is
to
gain
consensus
and
shift
them
properly.
If
with
the
goal,
is
to
ship
them
quickly,
then,
instead
of
getting
40
people
together
to
talk
about
things,
we
would
have
shipped
the
decisions
that
had
been
made
prior
to
the
group
and
the
there's
a
number
of
reasons
why
the
modules
working
group
process
is
a
good
thing
and
I'm
glad
we're
doing
it.
E
But
speed
is
not
the
benefit
I
see
from
this,
so
it's
fine
I
think
it's
fine.
If
we
want
to
like
I,
think
we
should
be
prioritizing
aggressively
the
order
in
which
we
do
things
I,
don't
think
we
should
be
thinking
about
implementations
in
any
way
whatsoever
until
we've
agreed
on
what
an
implementation
should
be,
for
example,
but
and
I
think
we
should
be
aggressively
pushing
to
the
side
like
we
all
need
to
decide
as
quickly
as
we
can.
E
What
the
first
implementation
should
be
that
we
made
like,
like
I,
think
that
it's
important
that
we
that
we
do
that,
so
that
if
we
decide
that
we
want
to
sacrifice
constraints
or
use
cases
because
of
UX
reasons
or
implementable,
'ti
reasons,
then
that's
a
discussion.
We
need
to
be
able
to
have.
But
first
we
need
to
have
decided
what
in
an
ideal
world,
we
would
want
those
constraints
to
be
in
the
implementation
look
like
and
like
so
I
think.
B
B
B
D
Think
what
I'm
realizing
the
more
I
dig
into
using
loaders
Linc
experimental
modules
with
node
I
realized
that
the
standard
is
very
web
bias
and
there
are,
and-
and
this
is
actually
the
thing
I
think
that
we
need
to
be
talking
about
the
fact
that
we're
trying
to
make
loaders
work
and
follow
the
standard
saying.
Oh
sorry,
the
experimental
module
loading
worked
out
of
the
box
and
follows
the
standard
and
meet
the
you
know,
expectations
of
everyone
about
how
javascript
has
to
you
know,
follow
the
standards.
D
I
think
the
bigger
problem
right
now
comes
from
the
fact
that
we
are
trying
to
fit
something
in
the
wrong
hole.
I
think
the
standard
on
which,
which
gets
revised
every
year
should
recognize
the
very
common
trends
that
distinguish
a
browser
from
something
like
note,
and
if
it
is
part
of
a
standard,
then
you
know
we
can
we
can
conform
and
we
can
problem
solve
to
meet.
You
know
things
that
are
part
of
the
standard,
something
like
specifiers.
D
You
know
this
is.
These
are
all
problems
that
we
can
try
to
solve
and
we
can
put
deadlines
to
solve.
But
at
the
end
of
the
day,
the
solution
will
have
to
be
biased
against
someone
out
there
in
the
community
and
we're
gonna
end
up
creating
more
problems,
and
you
know
some
people
just
not
end
against.
F
A
G
Okay,
yeah
I
just
wanted
to
say,
I
agree
with
the
saying:
that's
you
know
we
do
have
to
be
goal-oriented
here
and
thinking
in
terms
of
what
the
deliverables
are,
and
it
would
help
I
think
that
we
have
some
public
information
about
what
our
status
is
at
any
given
time.
So
what
we
see
the
deliverables
are
how
we
break
that
down
and
then
just
noting
what
they're
the
statuses
are
of
the
so,
for
example,
the
base
level
implementation
unflagged.
What's
the
status
of
that?
G
Is
it
stable
because
there's
people
already
asking
you
know,
can
we
use
MJS?
Let's
all
get
behind
that
and
without
more
information
available
publicly
from
this
group
saying
what
the
status
of
that
base
level
implementation
is.
People
are
just
assuming.
Oh
the
base
level.
Implementation
is
just
gonna,
be
MJS
and
no
other
features
like
what
we
have.
G
So
we
need
to
make
it
clear
what
the
status
of
experimental
modules
is
and
then
splits
out
and
say
there
will
be
a
separate
deliverable
phase
for
loaders,
so
it
could
possibly
initially
land
without
loaders
and
then
loiters
could
be
added.
You
know
split
it
out
into
the
individual
deliverables
with
their
associated
status.
F
Was
just
gonna
add
just
building
off
of
that
before
I
joined
the
group,
the
fact
that
experimental
modules
was
shipping
in
core-
and
it's
like
in
the
docs
on
the
webpage,
led
me
to
assume
that
it
was
just
like
imminent
that
this
was
like
a
beta,
a
period
that
this
was
what
modules
was
going
to
be.
You
know,
I
know,
there's
not
much
appetite
in
the
group
for
like
removing
it
from
core,
but
if
there's
some
way
to
better
communicate
to
the
public
that
this
isn't
quite
imminent,
this
is
not
set
in
stone.
F
You
know,
I
think
that's
something
we
should
aim
for.
Is
the
flag
being
called
experimental,
not
achieved
that
I
didn't
assume
that
I
mean
there
are
lots
of
things
that
are
under
harmony
like
every
every
experience
I've
ever
had
with
things
that
were
flagged
anode
has
always
been.
They
ended
up
working
exactly
as
I.
E
Single
thing
under
harmony,
you
should
never
have
been
used
in
production
like
async/await,
had
a
massive
memory
leak
when,
while
it
was
under
the
Harmony
flag,
so
like
I,
don't
know,
we
should
educate
to
fix
that.
But,
like
anything,
that's
under
a
flag
is
like
absolutely
a
terrible
idea
to
use
in
production.
It
is
unstable,
it
is
likely
to
change.
It
could
be
go
away
completely
and
anyone
who,
if
someone
doesn't
have
that
impression
and
like
we,
should
think
we
should
figure
out
I.
F
C
I
just
want
to
like
compound
something
that
I'm
starting
to
feel
here,
we're
talking
about
going
and
creating
these
minimal
implementations
and
stuff
we're
starting
to
see
more
PRS
and
things,
and
every
time
we
create
these
PRS.
Before
we
discuss
like
the
feature
set
of
a
minimal
implementation,
we
have
to
go
back
and
kind
of
dig
out
all
the
reasoning
why
a
PR
designers,
Pacific
way
and
I
think
that's
going
to
expand
our
time.
So,
although
we
are,
we
should
notify
people
of
statuses,
the
more
PRS
we
create
the
more
different
proposals
that
we
create.
C
Full
implementations
of
the
more
we're
gonna
have
to
like
dig
back
to
our
use
cases
from
them
and
the
more
we're
gonna
have
to
investigate
the
implications
of
shipping,
those
and
the
more
statuses
we're
gonna
have
to
ship
on
whatever
information
web
page,
whatever
to
say,
hey
this
proposal.
Has
these
problems
this
proposal?
Doesn't
this
proposal
certs
these
use
cases
this
proposal?
Doesn't
this
proposal
is
in
favor?
This
proposal
isn't
and
it
just.
A
Okay,
cool,
so
we're
gonna
wrap
up
that
topic
for
now.
Just
I
guess
one
thing
to
add
just
myself
as
the
person
who
had
created
the
issue,
the
purpose
of
bringing
up
those
deadlines
and
timelines
was
not
so
that
we
could
set
explicit
timelines
that
we
need
to
meet.
It
was
not
about
trying
to
rush
things.
It
was
more
about
trying
to
show
how
like
October
as
a
deadline,
would
still
not
having
have
a
shipping
unflagged
in
all
nodes
until
2020,
so
just
kind
of
understanding
the
amount
of
time
that
it
takes
to
roll
out.
A
So
we
have
a
mental
model
of
that.
The
next
thing
that
we
have
up
and
we
could
choose
how
much
time
we
want
to
spend
on
these
on
these
next
two,
the
first
one,
is
the
pull
request.
That's
open
for
import
meta
require
that
we've
been
going
kind
of
back
and
forth
on
this
import
meta
require
is
a
pull
request.
That
I
opened
is
an
alternate
mechanism
for
doing
interoperability.
A
A
A
C
I
think
it
is
premature
to
land
the
PR
I
have
like
an
entire
other
thread
about
why
we
shouldn't
ship
in
Port
meadow
dock
required.
We
should
do
something
that
early
errors,
I
also
have
like
web
compatibility,
concerns,
loader
ambiguity,
concerns
and
all
these
things
and
I
really
haven't
seen
those
addressed
anywhere.
So
maybe
once
we
get
there,
we
can
talk
about
it,
but
we
also
have
a
moratorium
on
new
features
so
like
we
aren't
really
modifying
core
and
we've
even
had
people
in
this
meeting
suggest.
Maybe
they
want
to
remove
cores
implementation.
A
C
We
can
bring
them
up
first,
let's
talk
about
load
or
ambiguity,
load
or
ambiguity
is
basically
can
a
loader
determine
the
format
of
a
given
file.
If
the
consumer
determines
the
format
that
means
using
require
I
get
a
different
format
from
using
import
for
the
same
given
resource.
That
means
the
loader
can't
actually
know
this
information
ahead
of
time.
It
has
to
do
it
a
at
runtime
and
B
it
may.
It
is
unsafe
to
make
assumptions
that
about
the
resource
always
being
loaded
in
the
same
fashion.
C
A
A
C
C
C
C
It
is
by
the
nature
of
actually
a
trans,
transparent,
interrupt
kind
of
relieves
that
a
bit
the
the
problem
is
that
you
don't
actually
synchronize
your
to
module
systems,
and
so
they
go
out
of
sync
and
you
get
these
ambiguities,
you
get
these
double
instantiations
and
things.
So
the
claim
of
import
meta
required
is
that
it
makes
things
simpler,
but
it
makes
things
weirder
and
more
ambiguous.
Actually,
it's
a
nicer
API,
it's
a
more
familiar
API
if
you
really
like
require,
but
it's
also
going
to
lead
to
these
weird
things
happening.
A
D
D
B
I
had
a
clarifying
question
to
what
to
return
namespace
to
an
export
object.
Sorry,
alright
I
had
a
clever
and
crispa
to
what
Bradley
was
saying
about
the
duplicate
things.
So
can
you
describe
using
import
minute?
Is
it
because
a
file
might
be
passed
as
either
and
if
you
import
it,
and
you
require
it,
you
loaded
once
as
yes,
M
and
once
as.
C
The
other
possibilities
we
should
these
dual
built.
So,
if
you've
been
watching
the
Interop
patterns
issue
the
the
idea
that
you
ship
a
package
that
is
able
to
be
loaded
both
as
common
J's
and
as
either
some
that's
one
way.
You
get
this
double
kind
of
scenario
where
you
have
babel
take
yes
in
compile
it
to
CJ
s,
and
ideally
in
whatever
node
version,
you
only
ever
load
one
of
those
two
you
either
load
the
ESM,
because
the
SMS
support-
or
you
only
load,
the
common.
C
C
B
C
Important
matter
required
does
change
the
equation,
because
if
you
declare
hey,
this
is
Winston,
you
should
only
load
Winston
MPM
install
Winston
you're
only
going
to
get
one
of
those
versions
do
a
package
things
it
does.
How
would
you
be
the
hope
of
the
common
gas
versions
versus
the
ESM
version?
I.
B
C
That
is
not
actually
part
of
this
conversation
is
not
necessarily
true.
There
are
multiple
designs
we
can
take
here.
The
best
migration
path
is
where
they
both
get
MJS.
If,
yes,
modules
are
supported,
like
you
get
a
promise
back
from
requirement,
there's
like
forwards
compatibility
and
like
this
whole
thread
about
migration
and
in
all
patterns
they
don't
get.
A
Time
check
on
here
we
do
need
to
move
on
to
the
next
topic.
Thank
you.
Everyone
for
bringing
that
up
and
Brad
I'm
gonna
take
a
hard
thing.
One
of
these
education
that
you
brought
up
they're,
really
valid
I,
have
to
you
know
I
think
I'll.
Think
about
it
quite
a
bit.
The
next
thing
that
we
have
coming
up
is
issue
number
one
of
a
package,
name
Maps
with
Hosni
browser
proposal
for
supporting
their
imports.
A
C
Red
I
have
opinions
on
everything
pretty
much
but
package
name
maps.
They
think
they
no
matter
what
we
do,
we're
never
going
to
achieve.
100%
web
compatibility
and
the
way
we're
evolving
right
now
and
I
think
forcing
us
into
package
name.
Maps
gives
us
a
master/slave
relationship
to
what
WG
that
I
am
very
uncomfortable
with
what
WG
is
very
biased
towards
browsers.
It's
been
a
little
bit
uncomfortable
even
discussing
things
with
him,
because
I'm
not
a
browser
vendor-
and
that
has
been
brought
up
to
me
and
note-
is
not
a
browser
vendor.
C
So
it
most
likely
is
in
the
same
book.
I,
don't
think
hoggish
name
maps
are
something
we
should
be
beholden
to
and
I
am
not
even
sure,
they're
a
good
idea
for
the
web
and
that's
a
longer
discussion.
But
the
overall
thing
is
matching
the
web.
It's
good,
but
we
don't
have
to
do
it
through
package,
name,
maps,
excellent,.
E
So
I
have
not
dodo
as
deeply
as
Bradley,
so
I
don't
have
technical
responses
to
package
name
maps
specifically,
but
I
I
like
the
idea
of
a
way
to
make
bear
imports
work
in
a
browser
without
an
additional
build
step.
I
like
the
idea
of
NPM
automatically
creating
this
resource
for
some
sort
of
default
path
for
almost
every
web
server
set
up
you're
not
going
to
want
to
use
that
anyway,
because
you
don't
want
all
of
your
node
modules
to
be
exposed
to
the
public.
E
So
you
you
know
that,
but
like
in
general
I
like
that
as
a
clean
path
for
not
having
to
mutate,
not
having
to
change
import
paths
in
order
to
ship
stuff
in
the
browser.
I,
don't
think
that
it
would
work
well
for
node
to
rely
by
default
on
a
static
package
name
map
I
think
it
should
always
be
possible
to
create
a
package
name
map
for
any
snapshot
of
a
file
system
that
works,
but
I.
E
Don't
think
like
I
think
that
the
the
the
directory
searching-
and
you
know,
extension,
resolution
and
stuff
like
that
is
incredibly
critical
and
so
that
that
kind
of
blocks
out
being
able
to
use
any
sort
of
static
format
as
the
default
implementation.
That's
the
only
place.
I
have
a
personal
concern
about.
Oh
okay,.
A
G
I,
just
I
just
wanted
to
clarify
you
know
when
we're
thinking
about
package,
name
apps
at
the
aiming
for
compatibility.
You
know
not
necessarily
as
Bradley's
worried
about
you
know,
making
them
first-class
necessarily
but
ensuring
those
compatibility.
So
if
I've
got
a
module
working,
a
node
I've
got
a
file.
G
As
we
can
check
filesystem
and
extension
mm,
just
let
me
know
if
I'm
breaking
out,
but
it's
the
relative
imports
that
we
need
to
then
ensure
have
the
file
extensions
present.
We
do
get
compatibility
of
people
just
do
that
as
a
patent
but
mandating
the
removal
of
automatically
adding
extensions
is
certainly
interesting.
Things
to
consider
there
so
I
think
that's
a
very
interesting
concept.
H
H
Yeah
so,
like
the
others
have
mentioned,
the
resolution
notes
resolution
mechanism,
its
integration
with
NPM
to
install
dependencies
in
all
the
right
places
and,
and
that
kind
of
thing
you
know
it
works,
there's
no
in
my
mind,
there's
no
need
to
go
and
to
rewrite
that,
because
there
happens
to
be
a
proposal
for
package
name
Maps.
You
know
that
seems
to
do
some
of
the
same
things.
Does
that
make
sense.
A
F
Jeffrey,
hey
I
was
just
gonna
say,
like
the
I
feel,
like
the
whole
reason
we're
doing.
This
is
to
try
to
standardize
with
the
web
that
like
if
we
wanted
to
have
a
separate
or
incompatible
module
system.
You
know
we
already
have
coming
to
us
and
I
understand
the
frustration
with
working
with
what
WG
and
so
on
that
we're
beholdin
for
them
and
all
the
rest,
but
still
like
I
think
you
know.
Certainly
one
of
our
top
goals
is
be
like
we
should
be
able
to.
F
C
So
I
just
want
to
make
a
counterpoint
to
people
stating
we
can't
have
our
cake
and
eat
it
too
kind
of
the
node
resolution
algorithm
has
advantages.
We
even
saw
some
stuff
about
having
to
manually
patch
an
angular
app
in
the
minimum
es
NPR
I
really
think
we
shouldn't
be
forced
into
the
idea
that
we
have
to
match
the
web
when
we
are
already
using
tools
when
tools
are
required
for
these
package
name
Maps
anyway,
that
we
can't
use
these
tools
to
assist
us
with
package
name.
C
Maps
packaging
Maps
can
support
complex
directory
file
extension
resolving
for
bear
imports
already,
because
you
can
put
a
URL
in
your
package
and
a
map
that
is
a
directory
and
it
can
point
to
index
JSON
or
index
CAS.
You
can
put
a
URL
in
these
package
name
maps
that
is
to
an
index
file
and
it
can
point
to
index
JSON.
A
A
Okay,
let's
just
keep
going
on
this
topic
and
push
transparent
interrupt
until
the
next.
The
next
meeting.
One
thing
I
do
want
to
say
to
you:
Brad,
though,
is
there's
a
difference
between
install
time
tooling,
build
tooling
and
production
tooling,
and
the
only
tool
and
that's
required
for
package
name
maps
is
installed
swilling
and
my
person.
A
E
I
was
I.
Think
Bradley
largely
covers
my
my
feelings
here,
but
I
mean
to
Jeffrey's
point
like
web
compatibility
is
a
huge
goal,
but
that's
not.
Why
we're
adding
modules
to
know
the
routing
modules,
no
they're
part
of
the
language,
and
if
we
want
to
be
no
das,
we
have
to
support
Jas
like
the
language,
so
even
if
there
was
no
way
to
become
compatible
with
the
web,
node
should
still
ship
ESM
like
.
E
web
compatibility
is
super
important
and
I
really
hope
we
maximize
what
that
means,
but
also
web
compatibility
doesn't
mean
we
do
what
browsers
decide
or
nor
does
it
mean
we
do.
What
browsers
tell
us
to
do.
It
means
we,
you
know,
try
and
men
like
maximize
how
you
can
write
code
that
works
in
both
places,
and
that
might
mean
no
build
process,
but
that
might
require
a
build
process
and
that
might
not
be
ideal,
but
that
would
still
be
a
place
where
we
would
ship
something
in
node
jeffrey.
E
F
Was
just
gonna
say
that
you
know
when
I
read
the
package
name,
a
proposal?
You
know.
If
you
look
at
the
example
there,
it's
only
like
a
short
json
file
like
a
lot
of
packages.
Are
you
know,
gonna
want
to
only
have
one
entry
point
you
know
like
like
jquery
is
just
one
file.
You
could
throw
that
into
a
folder,
throw
this
package
name
map
json
file
around
it
and
have
it
point
to
jquery
jas
and
you're
done.
F
You
didn't
need
a
build
tool
to
create
that
you
know,
like
there's,
gonna,
be
a
lot
of
front-end
tools
that
are
along
those
lines
that
don't
require
tooling.
So
I
think
that,
like
the
idea
that,
like
oh
people
are
gonna
need
to,
like
I,
mean
sure
jQuery,
it
uses
a
build
tool.
Of
course,
but
I
mean
there
are
simple
libraries
that
aren't
going
to
that.
F
Don't
necessarily
require
or
use
build
tools,
but
like
the
idea
that
we
that,
since
this
is
going
to
force
to
use
a
build
tool,
then
the
build
tool
can
solve
any
and
all
compatibility
problems.
I
think
is
over
overstating
things
like,
just
as
you
can
hand
create
a
package
at
Jason.
You
know
you
can
hand
create
this
package
name
that
file.
D
I
think
package
Dean
Maps,
like
I,
haven't
really
looked
at
the
details
of
it,
but
the
thing
I've
been
using
or
I
used
to
use
very
frequently
was
path.
Mapping
in
typescript
I
know
the
typescript
has
to
build
anyways,
but
it
was
from
my
experience.
It
was
simply
relating
a
name
to
a
particular
path
and
then
anything
you
slash
out
of
there.
It's
it's
basically
resolved
relative
to
that
I.
Don't
know
if
I'm
missing
the
point.
D
You
know
a
package
name
Maps
if
they're
not
as
simple
as
this
an
implementation,
but
that
kind
of
implementation
I
mean
it
definitely
helps
result
in
compatible
fees
with
their
specifiers
in
a
module
intended
for
note.
If
you
want
to
load
it
in
a
browser,
so
I
think
we
should
look.
You
know
we
should
all
try
to
get
more
familiar
with
what
package
main
Maps
bring,
or
you
know
the
challenges
that
it
could
bring.
I
think
it
shouldn't
be
just
that
we
think
it's
good
or
bad.
D
A
Okay,
thank
you
got
four
minutes
left
I
mean
like
some
of
the
things
that
I
bring
up
from
my
thought.
Process
is
I.
Think
when
were
thinking
about
the
resolution
algorithm
for
common
jet
for
coming
Jess
versus
ESM
I.
Think
it's
important
for
us
to
think
about
like
what
kind
of
user
experience
we
want
to
have
an
ESN
and
not
assume
that
we
need
to
match
the
behavior
of
common
jeaious
and
things
that
we've
done.
A
We
should
be
trying
to
design
something
that
is
forward-thinking
and
you
know
that
can
be
the
common
Janice
patterns
or
it
may
be
new
patterns.
And
when
we're
talking
about
package
name
apps,
we
don't
need
to
necessarily
support
name
Maps
directly,
but
I
do
feel
strongly
that
we
should
be
supporting
the
resolution
algorithm
capabilities
of
name
Maps,
because
that
will
be
the
only
way
that
we
can
share
source
text
in
between
platforms.
When
we're
talking
about
the
browsers.
A
There's
a
lot
of
rhetoric
that
I'm
hearing
and
I'm
not
saying
that
this
is
without
reason,
that's
framing
the
braze,
the
browser
as
a
leader
who
is
not
listening
and
as
us
as
followers
and
I,
think
that
we
need
to
shift
that
narrative
to
try
to
work
with
browser.
Vendors
which
I
know
has
not
always
been
the
easiest
in
the
past,
but
I
genuinely
believe
that
there's
an
opportunity
for
us
to
to
collaborate
here,
package,
name
apps
in
the
first
place,
introducing
their
imports.
The
browser
is
the
browser
aligning
more
towards
node.
A
B
B
The
thing
is
that
having
a
simpler
resolution,
algorithm
is
is
a
feature
in
itself
like
we
have
an
opportunity
to
simplify
the
resolution.
Algorithm
and
I
think
that
is
something
that
we
shouldn't
just
throw
away,
because
so,
for
example,
we
we
have
an
open
discussion
somewhere
about
adding
import
metadata
resolve.
The
reason
why
we
need
input
at
metal
resolve,
at
least
to
some
degree,
is
because
we
made
the
choice
of
having
all
kinds
of
mad
magic
in
the
resolution
algorithm.
B
We
cannot
just
use
new
URL,
which
you
can
do
in
the
browser
for
resolving
the
path
to
a
neighboring
file,
because
it's
not
as
easy
anymore
and
so
I
I
think
treating
it
as
a
giving
app
and
see
our
algorithms.
Is
it's
not
necessarily
the
whole
story
and
towards
the
tooling
point.
We
are
also
breaking
a
bunch
of
tooling,
at
least
in
the
browser
case.
B
Beyond
just
hey,
you
need
a
tool
to
generate
a
package
name
map.
So,
for
example,
I
think.
One
of
the
reasons
why
my
else's
point
towards
installed,
tooling
and
runtime,
tooling,
and
bundle
tooling
and
production
tooling,
is
different-
is
that,
for
example,
install
tuning
will
not
modify
the
files
on
disk.
B
If
you
have
a
chrome
workspace
and
you
mount
in
your
node
modules
directory
in
theory,
it
can
work
and
you
can
actually
use
life
at
it,
features
in
chrome,
dev
tools
or
actually
get
coverage
for
the
files
on
disk
using
chrome,
dev
tools
if
the
files
aren't
modified
if
the
files
as
soon
as
the
files
go
to
any
sort
of
compilation
where
path
gets
changed
and
define
on
this
doesn't
match
anymore.
What
is
it
actually
running
in
the
browser?
A
C
Okay,
cool
Brad
go
for
it.
I
just
want
to
say
us
having
a
simpler
resolution.
Algorithm
is
not
actually
what
package
name.
Maps
are
aiming
for
with
their
resolution.
They
do
have
a
mapping
system
here,
so
we
can
even
include
all
these
like
directory
searching.
We
can
include
like
all
this
ahead
of
time,
with
our
build
tools
and
we
already
are
having
those
problems
like
you're
speaking
of
beyond
even
without
package
name
Maps.
C
If
you
use
a
redirect
in
a
browser,
import
meta
URL
sometimes
is
really
wrong
and
we
have
an
issue
in
the
modules
repo
about
it
and
the
what
WG
has
said
they
will
not
change
it.
So
I
recommend
you
don't
use
important
at
a
URL
in
the
browser.
If
there's
any
possibility
of
any
redirects
and
I
I
would
like
import
meta
resolve,
but
even
if
we
include
it,
it
may
be
simpler
innocence,
but
it
may
have
the
exact
same
capabilities
as
what
we
have
right
now,
so
be
careful
Thank.
G
I
just
wanted
to
the
the
pool
request
you
have
there
at
to
117,
then
pilot
extension
resort
is
there
a
summer
we
can
get
a
pole
on
that
and
what
people
think
in
terms
of
how
that
enables
package
compatibility?
Is
it
worse?
I
mean
how.
How
can
we
gets
is.
Is
that
something
that
we
should
be
looking
to
get
a
vote
on
yet
from
the
modules
group
or
added
to
the
agenda?
Don't
do
you
think
they
make.
A
Yeah-
and
you
know
what
I
can
I
can
guess-
I
guess
sorry,
guy
I
can
use
this
as
kind
of
a
tipping
point
for
something
to
think
about
as
we
log
off
today.
We
really
as
a
group
need,
like
we've,
been
talking
through
a
lot
of
things,
and
we
continue
to
have
a
lot
of
conversations
and
I
appreciate
how
thorough
everyone
is
and
thinking
about
things,
but
but
guide
to
your
question
about
like
how
do
we
move
forward
on
something?
A
The
reality
is
the
way
that
we
haven't
set
up
right
now
is
we
need
to
reach
consensus
as
a
group
if
we
can't
reach
consensus
as
a
group,
we
can,
in
theory,
go
to
a
vote,
but
there
is.
There
is
a
challenge
here
as
a
group
as
a
modules
team,
we
are
eventually
going
to
want
to
become
chartered
if
we
want
to
become
charted,
which
means
that
we
actually
own
these
things
within
the
project.
A
I
personally
am
NOT,
confident
that
we
will
be
chartered
by
the
TSC
if
we
as
a
group,
cannot
reach
consensus
on
items
and
so
I
think
that
it
would
be
possible
if
people
wanted
to
approach
things
that
way
to
essentially,
you
know,
float
things
to
the
working
group
that
are
that
have
blocks.
Try
to
you
know,
force
a
vote
and
then
go
to
the
TSC.
If
we
can't
reach
consensus
here,
but
I,
don't
think
that's
the
way
that
anyone
wants
to
do
things.
A
If
it
doesn't
seem
like
this
group
and
all
the
work
that
we're
doing
is
able
to
reach
consensus
or
actually
has
a
future
where
consensus
as
possible,
you
know
what
what
do
we
do
with
that
and
I
don't
have
an
answer
for
that.
I
am
hopeful
that
we
are
able
to
talk
through
things
and
find
consensus,
but
I
do
think.
A
That
is
something
for
everyone
in
the
group
to
think
about,
because
if,
as
a
group,
we
are
never
able
to
reach
consensus,
we
will
be
unlikely
to
be
chart
and
we
will
just
kind
of
go
back
to
what
the
status
quo
was
before
we
spun
this
group
up.
I
guess
you
know
that
was
a
pretty
heavy
thing
to
add
right
before
we
log
off.
Is
there
anything
anyone
wants
to
add
to
that
really
quickly
before
we
call
it.