►
From YouTube: Node.js Project Modules Team Meeting 05-20-2020
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
B
B
You
might
end
up
say,
for
example,
if
you
load
100
common
J's
modules
from
ES
modules,
you've
now
got
one
or
two
seconds
added
to
your
startup
time,
potentially
so
trying
to
so
that's
where
I
thought.
Maybe
we
could
do
it
with
a
much
simpler
like
so
that
didn't
it
doesn't
do
full
scope
analysis
and
if
we
could
get
the
same
kind
of
level
of
results
and
so
based
on
Bradley's
work
and
the
sort
of
how
we'd
gone
throughout
the
on
the
test.
B
Typescript
do
something
similar
only
at
the
top
level
with
this
does
the
full
sauce.
So
this
there's
quite
a
bit
of
complexities
to
it.
Hopefully,
people
have
had
time
to
dig
into
it.
A
little
bit
jeffrey
ran
some
initial
results
on
it
against
the
top
thousand
modules
in
the
NPM
registry
and
the
results
that
he
got
from
that
I'm.
Just
looking
and
he's
posted
in
that
issue,
sixty-two
percent
of
packages
had
all
common
J's
named
exports
detected.
B
Five
percent
of
packages
had
some,
but
not
all
colleges
named
exports
detected
and
thirty
three
percent
didn't
get
any
named
exports
detection.
So
if,
if
the,
if
the
parser
fails
or
if
it
doesn't
detect
anything,
we
just
sort
of
fall
back
to
the
standard
import
default
case
that
we
have
currently
today
and
if
you
a
lot
of
those
cases,
come
down
to
singleton
patterns
or
where
someone
creates
a
variable
like
my
module,
which
could
be
a
function
or
a
class
or
something
like
that,
and
then
they
do
modules
module
that
exports
assignment.
B
They
assign
it
to
modules
that
exports,
and
so
we
don't
detect
those
patterns,
but
otherwise
it.
It
takes
the
existing
situation
today,
where
we
don't
have
any
named
exports,
and
it
makes
something
that
seems
like
it's
largely
useful.
I
personally
think
this
would
be
quite
nice
to
be
able
to
ship
and
would
be
interesting
to
hear
what
people
think
about
it.
I
know
Gus
had
some
concerns,
but
I'd
be
interested
to
hear.
If
there's
anyone
else,
we
haven't
heard
from
there's
any
opinions
on
this
or
had
a
chance
to
look
into
it.
C
I
suspect
so
it'd
be
interesting
to
like
in
general
I'm
on
the
side
of
like
we
should.
As
long
as
the
heuristic
we
come
up
with
is
stable.
We
should
you
know,
and
ideally
we
can
like
lint
for
it.
You
know
so
people
can
help
make
their
packages
follow
it
that
like
I'd,
rather
something
than
nothing
but
at
the
same
time,
I
do
want
to
make
sure
that
we
can
maximize
the
common
patterns.
C
We
include
so
that,
like
you,
really
have
to
like
I'd
love
to
be
I
have
a
world
where
the
only
time
named
exports
don't
just
work
is
when
you're
doing
something
weird,
you
probably
shouldn't,
have
been
doing
in
the
first
place
and
like
a
function
with
properties
for
example,
or
or
module
that
exports
equals
and
object
with
properties
is
a
totally
valid
thing
to
do
so.
I
want
to
try
and
get
an
understanding
of
how
well
we're
meeting
that.
So.
B
It's
worth
like
mentioning
just
a
couple
of
things
related
to
that.
Firstly,
for
packages
like
react:
they
have
a
module
that
exports
equals,
require
index
file
and
we
support
that
pattern
again,
as
discussed
with
Wesley
at
the
last
meeting,
we
do
support
module
data
exports,
dot
property,
but
yes,
as
you
described,
those
other
cases
probably
fall
under
the
33%
that
don't
necessarily
get
exports,
and
this
kind
of
touches
on
the
reason
why
Gus
has
currently
put
a
block
on
this?
B
Is
he
claims
that
if
you
have
an
existing
module,
that
does
exports
dot
and
you
were
to
refactor
it
to
not?
Do
export
start
anymore?
You
wouldn't
know,
as
the
author
of
the
common
J's
module,
that
you're
making
a
breaking
change
for
you,
yes,
module
consumers,
and
so
for
that
reason
he
doesn't
want
to
see
this
landing,
and
so
maybe
we
can
try
and
work
through
work
through
some
of
those
questions
in
more
detail.
B
A
I,
had
my
my
hand
up
a
couple
things.
I
would
love
to
add
here
kind
of,
like
all
things,
depending
we
did
just
land
in
twelve
right
now
in
14.4.
Is
it
was
the
latest
point
checking
with
nvm
fourteen
three?
That's
my
niece
right,
Thank,
You
Jordan
for
that
great
tool.
So
fourteen
three
just
landed
the
updated
change
to
the
errors.
So
when
you
try
to
import
a
common
J's
module
with
named
exports,
it
actually
now
prints
out
for
you,
an
explicit
error,
saying:
hey
you've
tried
to
import
a
common
J's
module
with
named
exports.
A
It's
not
supported
and
even
gives
you
the
code
sample
of
what
you
can
copy
and
paste
to
to
use.
Alternatively,
not
saying
that
this
is
a
sufficient
replacement,
but
I
think
it
is
a
good
step
forward
from
what
the
status
quo
was.
Having
worked
upstream
in
a
couple,
different
projects
that
have
worked
on,
write
it
on
writing
these
kind
of
wrapper
modules.
It
is
a
pain
in
the
butt.
It's
like
a
non-trivial
amount
of
labor
to
put
this
together,
and
then
it
becomes
actually
extra
complicated
to
test,
because
now
you
need
to
do.
A
It
also
means
that
you
kind
of
need
to
introduce
packaging
exports
field
in
order
to
do
it,
which
then
opens
up
a
whole
other
bunch
of
things.
It's
not
perfect.
I
mean
it
is
definitely
doable,
but
it
is.
It
is
a
lot
of
effort
and
I.
Think
to
the
point
of
some
of
the
module
authors.
You
have
kind
of
like
500
1000
modules
that
they
maintain
I.
Think
Jordan
is
maybe
one
of
those
folks.
A
It
is
a
lot
of
work
to
do
that
across
all
of
the
modules
that
they
support
and
then
the
option
kind
of
becomes
hey,
like
maybe
I,
just
won't
do
it
or,
alternatively,
hey
I
have
to
do
a
lot
of
labor.
This
is
obviously
like
a
non-issue
for
modules
that
just
export
functions
as
like
the
main
export,
but
that's
not
every
module.
A
So
I
guess
that's
like
in
short,
I
understand
why
supporting
this
is
very
compelling,
but
at
the
same
time,
I
think
that,
especially
with
the
clear
warnings
that
we
have
right
now,
it's
at
least
a
lot
better
than
it
was,
and
even
just
things
like
the
package.json
stuff,
which
we'll
get
up
to
later,
I
think
that
the
status
quo
of
today
can
be
significantly
improved
with
better
documentation
and
that
our
errors,
but
that
doesn't
make
less
labor
for
the
module
authors.
So
I
do
think
that
this
is
worth
continuing
to
explore.
A
A
Space
and
energy
spent
on
the
problem
space
to
have
it
not
land,
mostly
just
because
that's
like
super
demotivating
and
not
a
great
use
of
time.
So
with
that
being
said,
not
my
place
to
tell
people
where
to
put
time,
but
if
we
really
feel
like
it
doesn't
have
a
future.
It's
probably
better
to
just
kind
of
settle
that
before
doing
too
much
extra
labor.
A
C
I
will
take
an
assemblance
just
just
beating
for
gusts
this
point
a
little
bit
I
mean
adding.
Exports
is
a
breaking
change
and
I'm
working
on
a
tool
to
make
it
easier
to
avoid
doing
that
by
accident,
but
like
it's
still,
a
breaking
change,
potentially
and
similarly
adding
babble.
There's
a
breaking
change
unless
you're
very
careful
about
your
entry
points,
and
it
is
I.
C
C
It
would
be
unfortunate
if
adding
this
nice
feature
and
even
partially
increased
the
cases
where
things
were
accidental
breaking
changes
and
I.
Think
that
is
Gus's
I
think
Gus
wouldn't
use.
The
word
unfortunate.
He
would
probably
use
a
word
more
like
unacceptable,
based
on
his
comments
and
that
that's
I
think
that's
where
that's
from
that's.
C
My
sense
of
his
motivation
for
his
objection
and
I
like
I,
would
find
that
very
unfortunate
and
I
would
prefer
to
make
it
to
avoid
that
so
like
it
would
probably
also
be
useful
if
we
want
to
continue
pursuing
it
figuring
out.
How
can
we
persuasively
show
that
we're
not
making
the
accidental
breaking
change
landscape
horse.
B
B
If
you
change
your
modules,
one
by
one
and
you
you
you
don't
want
to
be
doing,
import
CJ
is
from
CJ.
Cj
is
default
when
it's
already
gotten
in
sponsor
flag.
So
that
was
his
argument.
That
cannot
be
changed
once
modules
like
once,
these
workloads
become
more
solidified,
so
that
aspects
of
the
PR,
if
we
don't
land
it
soon,
that
aspect
would
have
to
be
dropped.
If
we
did
want
to
be
able
to
come
back
to
this
in
future,.
A
Oh
I
think
but
correct
me
if
I'm
wrong,
that
we
kind
of
need
to
get
Gus
in
this
conversation.
If
we
want
to
move
it
forward
because
we
can
speak,
we
could
try
to
speak
for
him,
but
we
really
can't
separate
from
that
perhaps
like
out-of-band
and
issues
or
one-to-one
guy.
You
can
maybe
follow
up
with
him.
So
it's
not
like
stuck
on
these
calls.
It
doesn't
seem
to
me
like
and
correct
me
if
I'm
wrong
is
anyone
else,
who's
on
the
call
right
now
objecting
to
this
or
have
strong
negative
feelings
about
this
approach.
A
C
Just
want
to
make
sure
that
we
get
accurate
data
that
matches
what
the
PR
is
gonna
do
so
that
we
know
what
we're
getting
ourselves
into
and
and
I
can
really
appreciate.
Jeffrey's
work,
getting
the
data
that
we
have
and
I
wish
I
had
time
to
help
massage
it
further,
but
I
would
be.
I
would
prefer
to
see
that
data
before
the
PR
lens,
but
that's
not
an
objection
to
the
PR
mm-hmm.
E
Well,
I
am
a
little
concerned
that
the
numbers
aren't
as
high
as
I'd
like
I
mean
having
you
know
accurately,
detecting
more
than
half
of
how
manjae's
packages
is
certainly
impressive,
but
I
think
was
something
like
2/3
we're
detected
or
maybe
a
little
more
than
70%,
if
you
to
have
to
say
some,
but
not
all
exports,
but
that
still
leaves
something
like
a
little
over
a
quarter
of
packages
where
we
don't
detect
them
correctly.
So
my
concern
is
just
like
this
starts.
E
B
Think
it's
worth
remembering
that's
already
sort
of
the
status
quo,
but
I
think
it
would
help
to
know
how
many
of
those
33%
are
like
would
typically
be
used
as
require
module,
and
then
that's
the
instance
that
you
have,
because
just
because
we
don't
detect
static
properties
on
classes
doesn't
mean
it's
not
correctly
behaving
because
you
probably
miss
you
wouldn't
necessarily
want
set
a
class
properties
as
exports.
It's.
E
A
F
So
I
just
wanted
to
say
I'm
neutral
on
this
I'm,
not
strong
opinion
you
in
one
way
or
another.
One
comment
about
the
not
supporting
assigning
an
object
to
modules
export.
That's
actually
pretty
much.
All
I
write
every
t.j.s
module,
so
I'll
have
function
whatever
you
know,
a
bunch
of
functions
and
then
at
the
bottom
of
the
source,
I'll
have
modules,
dot
export
equals
with
a
list
of
properties.
F
B
The
the
object
literal
assignment
to
module
that
exports
is
a
case
that
could
be
improved
on
like
Wesley,
says
something
that
could
be
additive.
We
do
have
to
be
careful
that
we
don't
remove
that
the
grammar
has
to
be
fully
backwards,
compatible
that
that
would
be
a
case
that
could
be
improved
on
yes,
I.
E
G
Yeah
humor
me
observe
from
my
side.
G
Speaking
of
the
33
percent,
I
think
it's
a
question
that
also
asked
in
the
threat
I'm
less
concerned
about
the
two
thirds
with
us
one.
Third,
as
long
as
the
two
thirds
include
every
single
package
that
is
transpired
from
ESM,
because
I
think
that
is
the
one
with
it
actually
is
a
fundamental
difference
to
the
up
great
story.
I'm
I
am
personally
less
concerned
about
handling
random
packages
that
people
have
written
my
hand.
G
I
think
that's
a
big,
separate
question.
I
I
have
voiced
in
the
past,
and
I
would
be
in
favor
of
that,
because
it
would
clearly
scope
it
to
things
that
we
would
reasonably
expect
to
have
an
ear
this
M
equivalent,
so
that
there
is
an
actual
upgrade
path
between
the
two,
where
it
would
be
a
considerable
risk
and
I
think
that
is
something
it
also
has
not
addressed
in
his
comment.
So
there
might
be
just
a
misunderstanding:
yes
treats
this
as
an
optional
feature
that
doesn't
fundamentally
change
something
and
I
think
and
I
think
Gaius.
G
Badly
fundamentally,
changes
certain
ways.
It
apparently
not
tool
to
do
safely
with
people
cannot
enable
natively
as
M
for
the
packages,
because
they
are
in
a
package
tree
and
they
would
break
their
dependencies,
that
they
don't
do
it
in
the
exact
perfect
order
and
I
think
John
mentioned
earlier,
that
you
know
see
somewhat
data
potentially
before
you
would
be
confident
in
supporting
this
direction.
Is
there
some
comment
or
somewhere,
where
you
just
an
overview
bullet
points
of
the
kinds
of
things?
If
you
definitely
want
to
see
you,
it
already
exists.
I.
C
E
E
E
A
E
If
I
could
just
say,
one
thing:
I'd
rather
not
scope,
this
specifically
to
babble
transpiled
packages,
because
I
feel,
like
those
are
the
most
likely
to
be
updated
to
real
ESM
or
ESM
wrappers,
because
they're
already
written
in
the
SM
or
faux
ESM
or
whatever.
It's
like.
This
is
kind
of
most
useful
for
the
really
old
packages
that
are
pure
coming.
Yes,
that
are
still
coming,
yes,
may
never
get
updated
ESM.
So.
G
C
G
C
Also,
some
of
the
concerns
are
about
a
heuristic
shifting
over
time
and
then
like
and
if
we
pick
a
clear
boundary
like
it,
it
seems
reasonable
to
me
that
caught
of
packages
that
were
authored
in
CJ
s
only
are
expected
to
be
consumed.
The
way
CJ
s
works,
which
is
there's
a
single
default
export,
nothing
else.
Whereas
if
you
authored
your
package
in
the
SM,
it
makes
sense
that
you
would
assume
people
can
consume
then-named
imports
from
it.
C
E
G
It's
the
difference
between
the
end
user
being
completely
broken
because
of
the
echod.
The
package
enable
database
and
versus
the
entries
are
being
slightly
inconvenienced,
so
I'm
also
thinking
about
the
end
user,
but
I've
thinking
about
the
entries
are
having
a
broken
build
because
of
package.
Edit
exports.
A
A
B
Right
so
we
landed
import
metadata
resolved
a
little
while
ago,
and
this
is
basically
the
analog
to
require
dot
resolve
in
common
Jess.
So
it's
async,
and
one
of
the
great
things
is
now
that
we
have
top-level
awaits
using
import.
Dom
edit
or
resolved
in
top
level
code
is
absolutely
good
and
fine
to
do,
and
it
follows
all
the
resolver
semantics
exports
etc,
and
we
also
have
behavior
for
a
trailing
slash
to
resolve
paths.
B
One
of
the
reasons
that
was
added
was,
if
you
wanted,
for
example,
standard
workflow
for
import
method
or
resolve
or
required
or
resolve,
is
when
you
want
to
load
an
assets
that
isn't
a
module.
So
maybe
you've
got
a
template
file
or
something
like
that.
You
want
to
know
the
past
to
load
it
from,
and
maybe
it's
a
third
party
package
or
something
like
that.
B
So
allowing
this
trailing
slash,
allows
resolving
paths
and
then
you
can
kind
of
load
assets
from
within
those
paths,
and
it's
very
nice
useful
convenience
there
are
yeah
I
mean
apart
from
that,
there's
not
a
lot
more
to
it.
I
I
think
the
only
thing
that
was
even
like
a
vague
complexity
was
that
sort
of
farthing
thing.
C
So
yeah
I
might
hand
up
so
I
am
fine
with
the
use
case
right,
like
I
posted
another
issue.
That's
on
the
agenda
as
well
about
like
an
API
for
the
package
root
directory,
you
know
or
URL
or
whatever
you
want
to
call
it,
but
the
I.
So
the
first
thing
is
I.
Think
CJ
SNES
em
are
both
first-class
module
systems
for
the
foreseeable
future.
We
should
never
add
a
feature
that
makes
sense
for
both
to
just
one
of
them.
C
Obviously
there
are
maybe
some
features
endemic
to
the
model
module
system
that
only
makes
sense
in
one
module
system,
but
those
are
the
exception.
Not
the
rule
resolution
is
something
that
is
not
unique
to
a
module
system.
The
foreign
the
output
might
be
passed
vs.,
URL,
sync
versus
async
things
like
that,
but
you
know
the
capability
is
not
so
I
think
that
if
we're
gonna
that
whatever
we
add
here,
it
needs
to
be
for
both
module
systems
and
then
the
second
point
is
I.
C
Don't
think
we
should
conflate
resolution
with,
like
locating
with
look
locating
things
because,
like
maybe
I'm
using
the
wrong
terms
but
required,
not
resolve
always
gives
you
something
you
can
require
right
now
it
may
throw
it
may
have
like
it's
errors
in
it
or
it.
May
you
know,
I,
don't
know,
but
like
the
that
there's
a
conceptual
relationship
there
that
we
shouldn't
break
similarly
I
would
expect
something
called
resolved
in
the
sm.
To
only
give
me
things,
I
can
import,
you
know,
or
at
least
where
the
the
reason
that
I
can't
require
or
import.
C
It
is
because
of
some
way
of
some
property
of
the
code
and
not
you
know,
yeah
like
this
is
sort
of
vague
and
it
gets
a
little
sketchier.
When
you
talk
about
the
possibility
of
esm
being
over
HTTP,
but
like
the
whatever
resolution
rules,
we
want
to
have
I
think
those
same
rules
need
to
apply
to
both
a
resolve
method
and
also
the
method
that
brings
in
a
module
so
being
able
to
do
package
name
with
a
slash
on
it.
C
A
E
I
would
say
a
few
things
is
that,
like
I
understand
the
philosophically,
you
know
you
think
that
things
name
the
same
should
function
the
same
but
like
there
are
so
many
differences
between
these
module
systems
that
I'm
not
sure
that
that
should
really
apply.
So
you
like
uniformly
because
like
require,
can
require
any
any
file
like
any
any
unknown
file.
E
Extension,
for
example,
just
can
be
required
as
an,
but
it's
gets
treated
as
JavaScript,
whether
it
is
or
not,
and
obviously
that's
not
the
case
with
the
SM
so
like
right
off
the
bat
you
have
resolve.
That's
resolving
file
like
resolve
is
really
telling
you
what
would
this
be
mapped
to
to
a
file
on
disk
and
that
the
file
exists
on
disk
by
definition,
if
the
files
on
disk
you
can
require
it,
no,
it
might
throw
an
error
once
you
do,
but
that's
already
a
difference
between
yes,
I.
C
E
Could
because
what
you're
saying
what
you're
saying,
though,
is
that?
Because
we're
because
resolve
in
common
is
both
fine?
It
figures
out
what
the
path
should
be
on
disk
and
verifies
that
exists
on
disk
that,
therefore,
this
API
should
do
the
same.
But
this
is
a
different
model
system
that
uses
URLs
and
by
by
it
is
inherently,
is
meant
to
potentially
include
HTTP
URLs
in
the
future.
B
B
E
My
point
is
like
I,
think
the
the
systems
are
quite
fundamentally
different,
that
this
doesn't
need
to
be
a
direct
one-to-one
match
and
I'm
not
sure
what
users
would
care
that
this
differs.
You
know,
I
understand
you
care
because
you're
like
an
API
designer
and
you
want
things
to
be
clean
but
like.
If
we
don't,
then
what
user
is
gonna
complain
and
why,
in
a
real-world
scenario,
I
mean.
C
A
A
There
is
a
what
working
group
proposal:
I
just
dropped
the
link
into
the
chat
number
38
71,
specifically
about
making
import
meta,
although
it's
dot
resolve
URL
rather
than
resolve.
There
is
kind
of
a
couple
different
things
that
I
think
are
really
important
here.
That
I
would
like
us
to
all
be
on
the
same
page
about
before
we
make
decisions
and
I'm
open
to
being
wrong
here.
A
But
to
me
it
feels
a
little
bit
premature
for
us
to
unflagged
this
well,
there's
still
discussion
about
making
a
standardized
interface
upstream,
at
least
on
import
meta,
import
meta
is
a
thing.
That's
going
to
be
shared
between
environments
and
that's
something
that
various
environments
may
want
to
use.
A
I
noticed
that
you
know
like
one
of
the
things
that
guy
mentioned
as
a
motivating
factor
here
is
top-level
awake,
the
top
level
the
weight
is
still
behind
a
flag,
now
kind
of
two
different
things
here
and
I've
trimmed
in
on
this
issue
to
see
if
what
working
group
is
interested
in
still
exploring
this
I
know
that
other
environments,
like
yeah,
no
I,
think
I've
implemented
something
like
this,
but
a
couple
things
that
I
think
are
worth
pointing
out.
First
was
the
like:
hey,
maybe
we
don't
call
it
resolve?
A
Secondly,
if
this
is
a
feature
that
we
think
is
important
to
be
shared
between
import
and
require-
and
it
is
premature
to
put
it
on
import
meta,
perhaps
we
should
consider
putting
it
on
util
or
somewhere
else.
My
understanding
from
looking
at
the
API
and
it
can
be
wrong-
is
that
you're
still
expected
to
pass
import
meta
URL
to
it.
So
maybe
that's
optional,
but
either
way
like
we
could
have
util
dot,
resolved
URL
or
something
like
that.
That
could
be
unknown
specific
API
that
we
could
deprecated
in
the
future
for
import.
A
Wes
raises
a
really
great
kind
of
speaking
out
of
both
sides
here,
where
import
meta
for
suppose
for
host
specific
data,
but
we're
saying
not
to
add
non
agreed-upon
members
Wes
to
that
point,
I
think
that
I
would
say
it's
subtly
different
I
think
that
this
is
host
specific
in
the
fact
that
the
implementation
may
be
specific.
But
then,
when
we're
talking
about
adding
things
that
would
be
useful
and
potentially
shared
across
multiple
hosts,
we
definitely
should
try
to
coordinate
I.
Think
that's
like
what
is
specific
and
important
from
a
spec
perspective
over
a
tc39.
A
It's
that
tc39
doesn't
own
this
so
like
to
me
where
I
would
like
to
see
what
I
would
like
to
see
and
if
it's.
If
what
working
group
isn't
interested
in
this
and
browsers
aren't
interested
in
this,
then
maybe
it's
a
non-starter,
but
if
there
is
something
called
import,
meta
dot
resolve
I
wore
similar
API
I
would
want
the
behavior
to
be
the
same
in
node
and
on
the
browser
and
in
detto
and
in
other
environments.
A
If
that's
something
that
we
could
do
I
point
to
the
URL
object
as
an
example
here,
where
node
has
like
the
URL,
but
then
we
eventually
adopted
what
working
group
URL
and
it's
a
huge
amount
of
legacy
that
we
need
to
manage.
So
to
me,
we're
like
I,
can
see
important
matter
resolved
as
we've
implemented.
It
extremely
useful
I
think
that
putting
it
on
import
meta
right
now
doesn't
seem
to
accomplish
everything
that
we
want
to
accomplish
and
I
would
be
more
comfortable
unflagging,
something
that
is
on
util
or
not
import
meta.
A
Yeah
so
West
your
point:
if
we
wanted
to
do
import
meta,
node
resolve
that
could
totally
be
something
and
we
could
totally
in
the
future
deprecated
that
forward
import
meta,
resolve,
URL
or
whatever
I.
Don't
know
that
I
see
the
advantage
to
doing
that
over
like
a
util,
if
we
want
to
share
it
between
both
environments,
but
I
just
wanted
to
kind
of
point
out
that
as
a
high
level
of
something
that
I
would
like
to
see
us
try
to
accomplish
here.
A
B
Just
just
to
add
in
terms
of
getting
buy-in,
I
think
this
is
a
unique
situation
and
I've
said
it
before
and
I'll
continue
saying
it,
because
the
driving
use
cases
for
this
feature
exist
first
and
foremost
in
Survey
jeaious
engines,
as
opposed
to
browser
engines
due
to
where
we
are
in
terms
of
progress
between
the
platform's.
So
nodejs
actually
has
the
first
mover
advantage
on
this
feature,
and
and
that's
why
it
is
it
a
different
situation
and
why
I
think
the
the
thread
at
what
work
is
being
installed
for
two
years.
E
B
The
same
API
be
enough
of
a
buy-in
to
consider
unplugging
I
do
feel
that
standards
are
meaningless
without
implementation
adoption
when
it
comes
down
to
it.
The
proof
of
a
standard
is
in
the
implementation
shipping
so
that
what
we're
really
looking
to
coordinate
is
the
platforms
that
want
to
ship
this
and.
B
Yeah
III
would
be
careful
being
too
conservative,
because
in
a
few
months,
users
are
gonna
start
requesting
these
sorts
of
features
as
they
want
to
move
to
Azzam
primarily
and
it'll
just
be
another
case
of
oh.
We
don't
have
a
way
to
do
this
and
I
think
we're
far
enough
ahead
to
know
what
our
users
need
at
this
point
and
we
should
serve
our
users.
A
So
I
guess
the
only
thing
I
would
ask
that
I
think
trying
to
coordinate
with
Ted.
Oh
do
you
know,
would
definitely
alleviate
some
of
my
concern
but
I'd
love
to
figure
out
why
it
makes
sense
to
put
on
import
meta
rather
than
util,
or
something
like
that.
If
there's
a
strong
reason
or
module
for
that
matter,
yeah.
B
There
are
two
reasons:
one
its
contextual:
you
don't
have
to
the
important
editor
URL,
it's
contextual
to
the
current
module
you're
in
so
it'll.
Follow
self
resolution.
It'll
follow
all
of
the
sort
of
specific
resolution
cases
and
secondly,
it's
statically
analyzable.
What's
what's
really
nice
about
import
metadata
resolve
is
build
tools,
can
spot
it
a
mile
away
and
actually
one
of
the
major
difficulties
with
optimizing.
B
A
B
Just
don't
understand
why
people
don't
want
to
ship
a
feature
that
is
useful
for
our
users
that
helps
them
do
something
they
can't
do
today
and
like
the
static
analyze
ability
is
about
getting
by
in
between
build
tools.
The
what
matters
in
terms
of
buy-in
here
is
bull
tools
and
platforms,
and
import
arm
edited
or
resolved
very
easily
leads
to
both,
but
not
for
all
our
users.
Only
resn.
C
B
Or
web
pack,
you,
the
the
current
no
J's
built-ins,
are
not
up
to
date,
if
you're
using
webpack
and
you
do
import
URL
like
follow
URL
to
path,
and
things
like
that
on
implement
said
that
built-ins
aren't
maintained
and
no
one
maintains
them.
Where
is
these
kind
of
very
simple
static?
Syntaxes
allow
us
to
move
beyond
standard
library,
static,
analyze,
ability,
cases
and
I
do
think
that
leads
to
simplicity,
that's
important
in
adoption,
but
I
will
shut
up
there
and.
E
What
about
this,
could
we
could
we
perhaps
ship
this
unflagged
as
something
that's
not
on
import
meta
for
now,
like
whatever
you
know,
import
resolve,
URL
for
a
module,
and
it
could
behave
exactly
like
this
I
guess
would
have
to
take
a
import
met
it
as
an
argument,
but
we
could
just
ship
it.
It
would
be
out
there
and
then
you
know
when
if
we
can
get
more
standardization
later
from
from
you
know
and
elsewhere,
then
we
can
also
add
it
to
import
meta,
but
there's
no
reason.
E
E
Say
you
ship
it?
As
you
know,
import
resolved
URL
from
module.
So
it's
not
on
import
meta,
but
it
does
it
functions
exactly
the
same
way,
except
that
it
has
to
then
take
import
matter
as
an
argument,
presumably,
but
we've
shipped
it
and
it's
unflagged,
and
it's
documented.
We
would
just
do
that
now.
Essentially,
unless
there's
any
objection
to
that
and
then
whenever
the
standardisation
process
concludes
with
import
meta,
we
could
potentially
also
add
it
to
there.
But
at
least
we
would
get
it
out
there
on
flag.
Now,
as
some
ability
function
be.
C
A
Let's
see
who
open
this
issue,
I
can
just
introduce
it
really
quickly
because
I
think
I'm
pretty
familiar
with
it,
but
I
think.
The
crux
of
this
is
the
fact
that
exports
does
not
by
default
include
the
package.json
and
people
keep
getting
bit
by
this
I
think
that
there
is
a
request
from
the
community
to
perhaps
change
our
decision
about
what
the
defaults
are
with
exports.
It
is
my
understanding
the
west
todd
has
joined
us
today
explicitly
to
discuss
this
Wes.
Would
you
like
to
to
maybe
kick
off
some
of
your
thoughts,
yeah.
H
Sure
so
I
think
the
the
original
author
came
into
one
of
the
to
the
node
tooling
slack
and
started
chatting
about
it,
which
brought
it
to
my
attention.
So
it's
a
really
common
practice
to
just
say,
require
you
know:
package
Jason
from
you
know,
slash
a
qualified
module
name,
slash
package
Jason
right
from
a
tooling
perspective.
This
is
really
organic.
H
Now,
if
you
have
a
tool
which
is
looking
at
the
entire
tree
for
your
you
know
dependencies
and
suddenly
you
hit
one
with
an
exports
defined.
You
will
break
right.
You
can't
require
the
package
Jason
anymore,
so
I
think
and
then,
and
so
that
then
to
summarize,
there's
been
a
bunch
of
additions
like
possible.
So
other
solutions
here
in
this
thread,
but
really
all
of
them
end
up
putting
the
burden
on
tool.
H
Maintainer
z--,
to
make
a
bunch
of
changes
to
accommodate
this
and
I
think
that
since
exports
is
new,
it's
really,
it
seems
really
odd
to
say
any.
What
we're
going
to
add
this
new
feature
and
it's
going
to
break
everyone
and
now
to
fix
it.
Everybody
who
has
ever
implemented
a
tool
which
uses
require
on
package
Jason
go
update
your
code.
It
seems
like
that's
a
fairly
unacceptable
solution
to
me
anyway.
Lll
stop
down
there.
Maybe
Yan.
G
We
we
knew,
what's
from
another
reactor
thing
in
snowpack,
we're
running
into
this
problem.
We
I
think
the
pushback
we
are
getting
is
not
from
the
white
community.
I
wouldn't
expect
this
to
be
coming
from
the
average.
No
chance
developer.
It's
a
it's
an
important
part,
but
a
small
part
of
the
community
that
is
running
into
this,
so
I
think
it's
I
think
that
is.
G
There
is
a
path
to
ask
those
few
people
that
are
writing
tools
that
need
to
require
packets
Jason
to
adopt
the
new
resolution
feature
just
like
every
other
tool
that
is
interacting
with
metadata
needs
to
adjust
to
the
new
resolution
feature
in
the
interest
of
the
vast
majority
of
people
that
could
be
using
exports.
As
a
simple
feature,
that's
very
explicit,
now,
I
personally,
don't
care
as
much
as
long
as
we
make
it
a
very
clear
exception,
and
the
very
very
exception
would
be.
G
Every
export
implicitly
has
a
fixed
and
non
over
aidable
mapping
of
God's
left
package,
Jason
dot,
slash
package
chasing
and
trying
to
configure
that
mapping
would
not
work.
It
would
not
do
anything
because
it's
enforced
for
every
expose
field,
basically,
which
means
that
nobody
can
decide
how
that
one
magical
specified
should
resolve.
G
It
would
kind
of
introduce
a
reserved
specifier
that
has
an
implicit
meaning,
which
technically
makes
exports
a
little
bit
more
tricky
to
explain,
because
there's
now
a
footnote
to
a
lot
of
sentences,
but
I
think
it
might
be
an
acceptable
trade-off
if
it
unblock
people
so
I
think
it's
not
gonna.
Take
so.
A
I'll,
have
it
something
really
quickly
and
then,
unfortunately,
we're
at
time
and
I
have
a
hard
cut.
I
think
that
exports
is
a
new
thing
and
there's
a
lot
of
edge
cases
and
things
to
learn
and
the
expectations
that
folks
tab
today
is
definitely
built
upon
how
they've
done
things
before
and
in
six
months
a
year
two
years.
Those
expectations
just
won't
exist
anymore.
A
A
For
that
exact
reason,
I
do
think
that
we
can
document
better
that
we
can
have
better
errors,
that
we
can
make
it
easier
for
folks,
but
I
think
that
if
we
kind
of
tried
to
paste
over
everything
for
what
people's
initial
intuition
is
we'd
end
up
with
like
a
much
less
consistent
platform,
it's
at
least
where
I'm
coming
from
it
right
now,
but
I
recognize
that
I
may
be
not
the
only
person
who
feel
I
may
be
the
only
person
who
feels
that
way.
I,
don't.
H
Think
you're
the
only
person
who
feels
away
and
I
think
if
there
was
a
really
great
solution
that
had
no
exceptions,
I'd
be
all
for
it.
I
think
the
concern
here
is
that
the
situation
we
have
now
is
in
order
for
module
authors
to
adopt
this
great
new
feature,
which
I
think
is
absolutely
no
questionable.
A
great
addition
means
that
they
all
will
have
to
go
and
put
dot
slash
package,
Jason,
dot,
slash
package
Jason,
because
that's
the
only
way
it's
going
to
work
with
the
existing
tools.