►
From YouTube: Node.js Project Modules Team Meeting 06-17-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
With
June
17th
meeting
of
the
node.js
modules
team,
we
do
not,
unfortunately,
have
a
large
group
here
today,
so
we
are
going
to
wing
it
and
just
kind
of
have
a
discussion.
We
may
not
even
use
the
full
time,
but
we
started
a
cool
discussion
where
we
were
waiting
for
people
to
join
and
figured
probably
better
to
just
kick
it
off.
So
the
things
that
we
had
on
the
agenda
for
today
included
special
treatment
for
a
package.json
resolution,
and
experts
is
what
issue
module
CJ
s.
Exports
detection
is
a
second
one.
A
A
So,
if
you're
watching
us
you're
not
familiar
with
it
package
exports,
the
newer
feature
that
we've
introduced
into
node
and
there's
now
been
back
ported
all
the
way
to
no
12
and
it's
a
way
in
which
you
can
like
programmatically,
define
the
interface
of
what
modules
or
deep
imports
are
exported
by
the
package.
This
affects
both
command
j
s
and
e
sm
one
place
where
people
have
been
bit
a
couple
times
is
by
not
having
package.json
defined
in
there.
A
Some
folks
had
the
intuition
the
package.json
should
be
in
there
by
default,
and
that
is
one
of
the
discussions
that
we
were
having
and
so
the
discussion
that
we
were
having
before
we
interrupted
for
like
six
minutes
now
to
get
this
string
set
off
up
and
set
context
was
you
know
like?
Do?
A
But
you
know
there
are
ways
that
you
can
use
that
to
resolve
from
a
specifier
where
it's
entry
point
is,
but
you
have
no
way
of
guaranteeing
that
that
entry
point
is
at
the
root
directory
of
the
module
and
I.
Think
there
is
some
fuzzy
stuff
that
you
would
need
to
do.
Like
I
mean
you
could
crawl
up
the
file
tree
from
that
root
until
you
find
a
folder
that
matches
the
name
of
the
module,
but
that's
like
the
heuristics.
They
are
not
perfect.
B
Additionally,
be
presents
package.json
scan
so
required
with
the
exports
field
required
dot
resolve
of
a
specifier
with
a
slash
after
it
can
point
to
a
nested
directory.
That
directory
can
contain
a
package
JSON.
That
package
JSON
might
even
be
a
like
a
CPD
package
JSON
from
the
root
of
the
package,
so
the
name
field
and
it
might
already
match.
B
What's
the
directory
that
that's
in
like
where's
node
looking
for
a
package.json
that
provides
a
poly
fillable
path
for
tools,
it
still
needs
some
heuristics
for
the
few
versions
of
node
that
have
exports
support,
but
lack
this
API,
but
I
feel
like
that's
somewhat
acceptable
and
like,
but
then
it
also
completely
avoids
any
need
to
force
package.json
to
be
part
of
the
external
API
of
a
package.
Because
then
you
can
FS
dot,
read
file.
The
packaged
error
plus
with
path
joins
to
package
JSON.
If.
A
A
B
A
Yeah
I
guess
this
is
like
one
of
I
guess.
One
of
the
things
that
would
be
interesting
here
to
figure
out
would
be
like
a
heuristic
that
I
could
imagine
could
work,
although
like
could
it
be
a
little
bit?
Weird
would
be
like
if
you're
a
package,
if
we
made
it
an
ecosystem
package
and
that
package
was
called
like
you
know,
J
package,
JSON,
finder
or
whatever
right
like.
A
But
the
case
where
this
would
matter-
and
this
is
like
what
I'm
not
100%,
but
the
case
for
this
is
where
this
would
matter,
and
my
personal
thing
would
be
I
am
a
project.
I
have
a
dependency
I
want
that
dependencies.
Package.Json
like
it
would
all
like
this
is
the
the
hierarchy
that
we're
always
talking
about
here,
so
in
in
that
hierarchy.
If
that
hierarchy
is
guaranteed,
any
package
that
I
install
as
a
direct
dependency
will
always
be
a
direct
peer
of
any
package
that
I'm
trying
to
get
the
package.json
of.
B
A
Guess
the
thing:
that's
that's
tricking,
my
brain,
and
maybe
it
just
needs
to
be
whiteboard
it.
A
little
bit
is
like
if
I
am
it
so
the
workflow
that
you're
talking
that
is
like
I'm
a
dependency
I
am
like
a
CLI
utility
or
something
I'm,
a
dependency
of
a
project
and
maybe
I'm
doing
something
like
bundling
or
building
or
like
whatever
I
am
being
instrumented
by
the
top-level
package,
and
then
I
need
to
know
where
all
of
like
the
other
dependencies
are
like.
A
B
A
Guess
what
I
mean
is
like
the
the
child,
like
the
the
dependency,
will
always
resolve
things
relative
to
itself?
So,
let's
say,
for
example,
that
the
dependency,
a
dependency
that
is
assembler
major
difference
than
the
dependency
of
the
Ruth
project,
I
couldn't
just
use
like
require
a
thing.
/
JSON,
like
the
name
of
the
project,
to
resolve
that
JSON,
because
I
will
get
my
dependencies
version
of
it
not.
B
If
it's,
if
it's
overlapping
yeah,
but
if
yes
like
but
there's
all
but
the
way
that
like
node
path
works
is
as
well,
which
still
exists
is
I
could
specify
73
directories
in
a
specific
order
and,
like
writing,
an
algorithm
that
checks
each
one
of
those
like
it's
doable.
But
it's
a
whole
lot
of
unnecessary
work.
Since
nodes
already
got
the
logic
to
do
that.
Work
in
a
regular
require
outer
yeah.
A
That
are
not
reasonable,
because,
like
to
what
I
was
saying
is
like:
if
you
are
the
root
package,
and
you
have
a
dependency,
you
need
to
know
what
the
root
packages
that
you're
resolving
everything
off
of
no
matter.
What,
and
once
you
know
that
you
know
that
we're
package,
/
node
module,
/
things
slash
package
JSON,
is
always
the
path
that
you're
going
from
right.
B
That
last
part
is
not
correct,
though,
like
even
if
you
know
the
root
package,
I'm
saying
that
you
you
do
not
know
that
that
packages
node
modules
folder,
contains
the
thing
you're
trying
to
require.
That
is
not
a
guarantee
you've
ever
had
in
node,
and
you
continue
to
not
have
it
now
and
so
there's
not
an
like.
That's
the
99.99%
common
case,
of
course,
like.
A
I
guess
what
I'm
saying,
though,
is
even
if
we
give
you
an
API
and
node
doing
what
you're
asking
for
that
API
will
still
either
need
to
be
given
the
route
that
you're
resolving
from
or,
alternatively,
be
resolving
from
the
roots
of
the
package
that
you're
running
and
so
I
don't
actually
see
why
this
is
any
different
than
just
giving
a
user
land
thing.
The
route
that
you're
using
is
the
base
of
your
resolve
like
I.
Don't
know
why
this
needs
a
custom
API
unknown
to
do
it.
B
So
the
what
I'm
saying
is
the
hard
part
isn't
knowing
the
route
like
tools
already
have
that
with
like
process
CWD,
so
that
the
the
issue
is
that
there
is
no
way
from
a
specifier
with
in
the
presence
of
exports
to
reliably
know
where
the
package.json
that
has
that
experts
field
lives.
It's
just
not
like.
It
sits
in
the
common
case,
it's
easy,
but
in
the,
but
there
exist
cases
where
it
is
impossible
to
know
for
sure
and.
B
B
B
A
Yeah
I
guess
like
the
workflow
here,
but
I
would
imagine
that
would
make
a
ton
of
sentences
like
this
sounds
like
a
useful
user
than
package
that
we
should
try
to
hit
like
100
percent
test
case
of
and
if
we
find
edge
cases
that
cannot
work
and
require
api's
in
dude,
then
we
should
totally
explore
and
do
that.
I
am
just
not
immediately
convinced,
but
I
could
be
wrong.
I'm,
not
immediately
guidance
that
we
need
a
node,
specific
API
for
it
right,
yeah,
I,
know
and
I'll.
A
A
A
We
now
need,
like
some
sort
of
grammar
for
excludes,
which
I
know
is
like
something
that
is
being
discussed
right
now
of,
like
private
versus
public
is
one
but
like
it's
different
from
like
excludes,
so
it's
like,
if,
if
we
may
package
JSON
on
by
default,
what
about
the
cases
where
people
do
not
want
the
package
JSON
to
be
part
of
their
API,
that's
exposed?
So
now
we
need
to
do
like,
like
the
the
I
could
think
of
like
an
exclamation
mark
at
the
beginning
of
something
being
or
like.
B
B
A
And
I
guess
maybe,
like
the
big
question
here,
would
be
like
how
many
use
cases
are
there
realistically,
where
we
don't
want
to
give
people
the
package.json
right,
I
and
and
perhaps
oh
hello,
Jeffrey
you've
joined.
Perhaps
it
is
worth
kind
of
stepping
back
in
and
reevaluating
our
defaults
here
and
saying
like
hey.
A
If
we
don't
really
have
many
use
cases
or
many
people
who
are
raising
their
hands,
saying
we
don't
want
the
package
like
we
want
to
exclude
the
package.json,
then
perhaps
the
amount
of
a
tooling
and
infrastructure
and
ecosystem
stuff
that
we're
saying
we
have
to
do
in
education
is
maybe
not
worth
it
Jeff.
To
give
you
a
quick
update,
we're
going
back
and
forth
on
the
excluded
package.json
or
whether
or
not
it
should
be.
You
know
on
by
default,
in
the
experts
map
and
what
kind
of
tools
we
might
need.
A
C
I'm
I
remember
the
discussion
of
last
time.
I
learned
if
we
made
any
progress,
I'm
still
leaning
towards
at
least
not
doing
anything,
at
least
for
now,
because
I
kind
of
want
to
get
a
sense
of
how
big
a
ecosystem
problem.
It
is
because
it
doesn't
seem,
like
all
tools,
have
this
issue,
so
you
know.
Is
it
only
a
very
few
number
of
tools?
Is
it
that
big
of
a
deal
for
them
that
to
update
you
know,
I'm
not
like
a
hard?
No,
we
should
never
do
anything,
but
I
mean.
A
You
know,
like
that's,
not
necessarily
a
huge
issue,
but
like
I
could
see
that
being
something
that
people
aren't
thrilled
about.
I
think
I'd
be
personally
make
more
sense
to
teach
people
that,
like
anything,
that's
not
in
the
exports
field,
is
not
import
about
or
require
about
period
instead
of
everything.
But
it's.
B
A
totally
fair
point
that
the
caveat
of
like,
if
we
make
it
implicit,
then
all
the
tools
have
to
explicitly
exclude
it,
and
so
there's
tooling
work
either
way.
So
my
preference
remains
having
the
packaged
or
API
being
a
node,
and
then
no
packages
have
to
ever
add
package
JSON
unless
they
have
some
weird
reason
why
they
want
to
and
I'd
be
able
to
remove
it
from
all
my
packages
right
like
it's
only
in
there.
So.
C
C
You
probably
know
the
answer
to
this
like
so
that
that,
like
test
script,
that
I
was
writing
on
to
inspect
the
commonest
named
exports.
The
I've
been
a
little
busy
lately,
as
you
guys,
might've
heard,
but
the
next
step
I
was
gonna
make
on
it
was
to
try
to
do
some
kind
of
naive
analysis
of
the
readme
files
of
all
these
damn
packages
to
try
to
see
well.
C
A
C
A
C
Jason,
so
it's
sort
of
like
you
know,
I
haven't
started
writing
the
code
yet,
but
I
was
thinking
like
oh
I
could
do
like
require
it
out
resolve
package
name,
but
that
doesn't
get
me
the
root
of
the
package.
It
just
gets
me
like,
whatever
the
main
is
and
then
I
guess,
I
could
like
work,
my
way
up
the
path
to
find
the
node
modules
folder
or
the
first
path.
That's
a
node
modules
then
go
down
from
there
to
find
the
package.
B
A
B
That's
a
chicken
and
the
egg
thing
for
an
arbitrary
package,
so
it's
yeah,
that's
the
whole
whole
issue
is
there's
no
reliable
way
to
do
it?
I
think
for
readme
MD
you're
better
off,
because
those
are
unlikely
to
be
duplicated,
whereas
package
JSON
with
type
module,
are
bound
to
be
littered
throughout
the
tree
so
like
for
finding
the
root
directory.
Maybe
you
could
use
the
readme
as
a
placeholder,
but
like
there's
packages
without
read
means
there's.
You
know
well.
C
C
My
purposes
I
would
just
excuse
ones
that
I
couldn't
find
it
read
me
for,
but
like
right,
this
does
come
back
to
like
the
thing
we
were
talking
about
of
like
should
there
be
maybe
like
a
helper
method.
That's
like
get
package
route
so,
like
I
feel
like
that.
Maybe
we
shouldn't
be
too
much
debate
about
adding
so
be
the
same
as
resolve,
except
instead
of
resolving
to
the
main
it
just
resolves
to
like
the
folder
that
the
root
level
package.
A
A
B
C
B
B
And
then
would
there
there
would
have
to
be
a
user
land
module
for
this,
whether
regardless
of
whether
that
was
before
or
after
it
landed
a
node
like
there
would
be
a
user
land
module
and
then
and
that
would
serve
as
a
polyfill.
So
all
the
tools
could
migrate
to
use
that
for
almost
all
versions
of
node
and
then
like
now,
there's
no
longer
any
question
about
the
consumable
API
of
a
package
versus
the
location
on
disk
of
a
package.
Well,.
B
A
B
The
specific
reason
it
won't
is
that
people
often
use
babel
with
the
copy
files
option,
which
includes
copying
the
package.json
into
the
output
folder,
which
means
disk
slash
package.
Json,
will
be
an
identical
copy
of
route
package
JSON
for
that
package,
which
means
that
you
can't
check
the
name
field
or
the
exports
field.
There's
no
indication
that
it's
not
a
route
package
from
the
disk
folder
well.
C
A
It's
been
work,
but
I'm
pretty
sure
there
wouldn't
be
because,
like
the
internal
API,
that
you're
talking
about
here
in
Jordan
would
be
essentially
doing
something
similar,
but
not
exactly
to
this
like
we
would
be
resolving.
You
would
have
to
do
like
a
resolved
of
like
the
package
itself
to
get
like
the
root
folder.
A
Now
we
have
like
internal
api's
that
that
that
do
that
but
like
if
you
use
required,
not
resolve,
for
example,
or
if
we
made
module
dot
resolve
as
we're
talking
about,
because
we
weren't
sure
if
we
want
to
import
matter
result,
but
if
we
had
we
had
module,
will
not
resolve
and
module
dot
resolve
gave
you
like
the
path
to
the
thing
that
the
specifier
resolved
to
and
also
have
a
secondary
option
to
like
change.
What
the
root
of
that
result
is.
A
B
So
it
just
as
you're
talking
it's
sort
of
I
think
you're
right
in
that
it
is
a
hundred
percent
possible.
Essentially,
what
it
would
require,
though,
is
actually
like
the
Sutton,
so,
for
example,
resolve
already
needs
to
duplicate
the
entire
exports.
You
know
no
resolve
algorithm
once
it
does
that
I
could
expose
a
subset
of
it
from
resolve
as
they
get
packaged
or
API,
which
would
work
100%
of
the
time
so
I
I
think
you're,
right
and
I
was
wrong.
A
Can't
you
just
like
I
mean
two
things
that
you
could
do
depending
on
like
the
direction
you
want
to
do
it
is,
you
could
either
use
like
import
meta?
You
are
L
and
create,
require
and
then
use
the
require
result
from
that
or
you
can
just
use
important
matter.
Resolve
require
resolve
or
we
could
make
module
resolve.
It
comes.
B
B
To
do
this,
I
I'm,
not
sure
it
does,
because
there's
not
even
guaranteed
to
be
a
node
modules.
Folder
anywhere,
the
like
the
it
is
possible,
with
node
alone
without
patching,
require
to
not
have
any
file
system
at
all
and,
like
your
excuse,
me
not
have
a
node
modules
on
disk
and
just
use
like
node
path,
to
have
no
node
modules,
folders
anywhere,
but
have
a
folder
full
of
node
modules
and
and
so
any
crawling
up
and
down
just
wouldn't
work.
So
wait
like
the
problems.
A
A
B
B
I
think
there's
a
number
of
angles
of
attack
and
they're
all
worth
exploring,
but
the
I
still
am
I
think
that
the
reality
is
that,
even
if
it
ends
up
being
four
with
all
of
these
methods
doable
in
userland
correctly,
it
still
seems
kind
of
silly
to
not
put
it
in
nodes.
Since
that
work
is
already
done
in
node,
it's
literally
just
like
taking
the
required
algorithm,
taking
a
subset
of
it,
putting
that
in
another
API
and
sharing
it
like
yeah.
C
A
A
A
Think
that
we'd
have
to
we'd
have
to
go
through
and
and
look
at
how
the
algorithm
is
implemented
and
where
it's
implemented,
because
I
mean
it
may
require
a
refactoring,
but
it
may
not
be
as
straightforward
as
you
might
think.
It's
worth
digging
into
like
I.
Don't
think
that
I
would
object
to
it.
I
know
that
upstream,
there's
like
a
high
bar
for
adding
new
API
so
like
this
is
at
least
something
that
we
should
consider.
A
I
think
I
think,
but
I
could
be
wrong
that,
like
what
we're
identifying
here
as
a
gap,
either
way,
though,
is
really
like.
There
is
not
something
like
resolve
available
in
the
ESM
goal,
other
than
using
important
matter
resolve,
which
is
currently
behind
a
flag
and
like
we
were
talking
about
trying
to
like
coordinate
with
w-with
what
week
before
landing
that.
So
what
we
may
want
to
push
for
is
some
sort
of
resolve
like
api
or
suite
of
resolve
like
AP.
Is
that
live
on
either
util
or
module
and
I?
A
C
Also
that
one
that
I
proposed
like
a
year
ago,
which
was
like
get
get
type
or
get
package
type,
or
something
like
that
where
it's
like
for
this
file
on
disk
or
this
URL
sort
of
a
file,
will
node
interpret
this
file
as
commonjs
or
as
ESM
as
in
like
if
it's
a
AAS
file
like.
Is
it
in
a
ESM
package
scope
or
not?
Essentially
the.
B
A
B
A
A
B
And
then
from
there
you
can
apply
whatever
module
system
logic
you
want,
or
you
know
you
can
read:
FS
read
file
whatever
file
like
yeah,
I'm
I
think
it's
all
these
things
are
worth
exploring.
Many
of
most
of
these
things
are
good
and
I
think
we
should
have
them.
I
think
that
in
particular,
I
remain
convinced
that
we
should
have
a
first-class
get
module
route
or
get
package
route
or
whatever
API.
A
A
C
Talked
about
that
one
we
ever,
we
called
it
get
package
metadata
in
the
in
the
description
and
at
the
point
of
that
was
like
for,
if,
for
whatever
reason,
it's
not
actually
a
package
based
on
a
disk
but
like
the
package
is
being
loaded
through,
you
know
some
kind
of
caching
or
in
memory
or
shenanigans,
an
HTTP,
loader,
etc.
Then
this
should
provide
some
other
way
of
getting
that
this,
but
the
data
that
would
be
in
package
Jason
but
would
not
necessarily
be
where
you'd
expect
to
find
it.
In
other
words,
yeah
good.
A
A
Yeah
yeah
well
well,
I
mean
I,
think
it
depends
on
what
we
want
to
do
right
because
like
if
like,
if
all
that
we're
trying
to
do,
is
give
you
information
that
we
can.
You
know
like
resolve,
for
example,
without
having
to
do
any
stats
or
file
system.
Reads
like
it
would
be
a
faster
API
so
like
if
we,
if
we
can
give
you,
for
example,
from
the
module
like
what
is
its
root
directory
and
like
what
is
the
path
to
its
package
JSON
or
something
like
that.
A
C
A
A
C
Other
thing
I'm
thinking
is
like
the
exports
and
conditional
exports
are
so
complicated
that,
like
sure,
a
package
like
resolve
could
duplicate
all
that
logic
for
userland,
because
because
I'm
thinking,
what
what
needs
to
be
able
to
replicate
that
logic.
Besides
node,
it's
gonna
be
bundler
right
like
something
like
roll-up
for
web
pack.
That
wants
to
like
you,
want
to
be
able
to
give
it
like.
Okay
bundle,
the
thing
that's
either
under
the
import
condition
or
the
module
condition
or
whatever
the
browser
condition,
and
then
it
like
knows
how
to
deal
with
conditional
exports.
C
And
yes,
someone
can
write
a
usually
on
module
like
resolve
that,
then
all
these
bundlers
will
depend
on,
but
I
almost
wonder
if
it's
better
to
be
part
of
node,
because
then
it's
like
for
sure
gonna
be
correct
and
like
can
up,
can
it
can
update
over
time
and
the
and
the
bundler
will
update
with
it
I?
Don't.
A
Know,
I,
guess:
I
guess
the
intuition
that
I
have
that's
gonna,
be
like
something
we
need
to
like
debate,
and
figure
out
is
like
what
is
the
core
functionality
that
we
need
to
do
this
in
a
reproducible
and
reliable
way,
I
think
that,
like
especially
when
we
talk
about
like
maintenance
ability
to
iterate
on
the
API
ability
to
make
breaking
changes,
ability
to
extend
it
like
there
is
actually
a
fairly
large
cost
to
putting
this
a
node
from
a
maintenance
standpoint
in
like
in
a
negative
direction.
It
makes
things
much
less
flexible.
A
It
makes
it
much
harder
to
iterate
on
the
API,
so
I
really
do
think
like,
as
we
start
talking
through
the
complexity
of
this,
as
we
start
talking
through
like.
Should
this
be
a
synchronous,
API
or
an
async
API
or
like
what
kind
of
workflow
should
we
have
here
like
stuff
like?
Can
we
hook
this
into
the
internal
caches
right
like
something
like?
A
That
might
be
useful
to
the
point
you
were
saying:
Jeff.
There
is
like
to
talk
to
different
bundler
and
see
like
where
are
your
limitations
right
now?
What
are
the
things
that
you're
trying
to
do
that
are
hard
and
start
thinking
about
like
what
are
the
minimal
number
of
like
resolve
base
API
is
that
we
need
to
make
for
individuals
to
like
cover
the
baseline
of
what
they
all
need?
If
we
start
making
things
in
node
that
have
too
much
of
an
opinion
in
the
API,
we
can
start
making
something.
A
C
A
C
A
more
common
I
asked,
you
know,
that's
gonna,
be
a
lower.
Give
me
lots
of
loaders
that
need
that
type
of
thing,
and
so
far
we've
like
gotten
away
without
needing
extra
methods
by
kind
of
repurposing,
the
hooks
the
node
hooks
themselves
as
those
methods,
but
it's
a
little
it's
a
little
honey.
So
anyway,
that's
the
other,
like
broad
area
where
this
kind
of
stuff
would
come
up.
B
A
B
A
A
Looking
at
some
other
things
that
we
had
on
the
agenda
today,
I
think
there's
a
couple
stuff,
a
couple
things
in
here
that
have
that
are
being
flagged
for
the
agenda.
That
I
think.
Maybe
we
could
draw
now
specifically
rediscover
of
order
CJ
s
exec.
That
issue
has
not
had
a
comment
on
it,
since
May
does
anyway.
So
any
concerns
I.
A
C
Can
drop
that
one,
but
that
I
think
it's.
The
conversation
has
shifted
to
that
other
PR.
That
guy
worked
on
with
the
comedy
is
named
exports
detection,
which
I
think
is
definitely
still
in
flux
or
in
development.
Gus
is
the
main
objector
there
and
I.
Don't
think
he's
on
today's
it's
so
maybe
it's
not
worth
talking
about
that
one
today,
but
I
have.
C
C
A
C
A
A
C
A
C
Well,
I
mean
that's
true,
but
the
main
objection
people
had
that
I
remember
to
that
earlier
proposal
was
just
well
if
someone's
gonna,
if
someone's
gonna
update
the
package
at
all,
they
could
just
add
a
wrapper
like.
Why
are
we
providing
all
their
alternatives
to
kind
of
the
quote?
Unquote
correct
way
of
doing
this
and.
A
C
Think
we
kind
of
need
to
I
almost
feel
like.
We
need
to
get
it
as
good
as
we
can
with
guys
branch
and
maybe
merge
it
in
behind
a
flag
to
try
to
get
some
user
feedback
because,
like
it's
really
all
about
what
our
user
expectations
here
and
it's
like
you
know,
you
users
have
to
look
up
documentation
anyway,
just
to
know
what
the
names
are
that
they're
trying
to
import.
So
it's
sort
of
like
you
know
anyone.
C
It's
not
like
it's
an
ambiguous
thing
where
sometime,
it's
not
like
it's
in
deterministic,
where
sometimes
it
works
and
sometimes
doesn't
like.
If
it
works
for
a
particular
package,
it
will
work
for
that
package.
At
least
you
know
until
that
package
does
a
major
upgrade.
So
if
someone
writes
a
an
import
statement
against
a
package
for
which
it
works,
either
you're
right,
they'll
either
work
or
fail
right
off
the
bat.
C
The
moment
they
first
try
to
import
the
package
and
then
they'll
write
their
code,
one
way
or
the
other
and
probably
never
update
it,
and
that's
probably
fine
for
people,
that's
kind
of
like
the
same
as
if
they
had
picked
a
particular
named
export
to
bring
in
and
they're,
assuming
that
in
the
index
board,
it's
not
going
to
change.
You
know
short
US
number
major
change
of
that
package.
You
know
I
mean.
B
I
guess
I.
The
concerns
I
have
their
first
of
all
is
that
the
package
is
people
really
gonna
want
to
do
this
on
our
packages
that
aren't
going
to
get
updates
and
separate?
The
second
is
that
starting
to
use
Babel
is
already
a
cember
major
change
unless
you're
super
careful
and
as
is
starting
to
use,
exports
and
I
am
mildly
concerned
that
the
heuristic
will
be
more
likely
to
break
because
of
a
Babel
change
and
like.
C
B
Battlespire
output,
which
alters
the
heuristic
either
it
gets
more
exports
or
less
exports,
and
but
it's
either
less
would
be
the
breaking
change,
but
yeah
or
the
name
you
know
like
the
name
of
them
is
mangled
or
something
I
don't
know
like
it.
It
just
depends
on
what
the
heuristic
is
right
and
it's
I
think
it's
possible
to
write
something.
That's
it's
not
brittle
in
that
way,
but
I
have.
B
A
B
So
you're
right,
I
think
the
risk
of
that
is
low,
but
it's
just
kind
of
I.
Don't
know
it.
I
think
that
in
general,
if
it's
gonna
require
like
two
miles,
this
point
I,
think
or
two
miles
as
a
suggestion.
I
think
it's
gonna
require
action
on
the
part
of
the
author.
The
rapper
is
actually
not
that
difficult
and
like.
B
C
A
C
I
think
III
really
I
think
it's
a
real
open
question
that
we
should
try
to
get
really
use
your
feedback
on
and
be
like.
Is
it
better
for
half
or
two-thirds
or
whatever
we
ultimately
get
to
for
those
to
have
named
exports
that
are
kind
of
magically
detected
and
the
other
ones
don't?
And
you
have
no
idea
before
you
try
it,
which
packages
are
gonna
work
and
or
which
ones
aren't,
or
is
it
better
to
just
know
that
they're
all
default?
C
A
Think
doing
sort
of
user
research
study
is
is
not
a
bad
idea
by
Dorothy.
Oh
yeah,
I
think
I
think
that
the
problem,
the
problem
that
we
may
run
into
here
is
like
biased
responses,
because,
like
do
you
want
named
experts
for
coming?
Yes,
it's
gonna
like
definitely
be
a
yes,
no
matter
what,
but
the
subtlety
here
is
like.
Would
you
want
it
if
it
works
X
percent
of
the
time
now
it
starts
maybe
getting
different
answers
or,
like
the
other
thing,
from
like
a
module,
author's
perspective,
you
know
like
and
I
guess
this
is.
C
C
A
C
B
I
mean
what
the
pattern
I
use
in
all
of
my
like
shims,
for
example,
is
that
the
default
export
is
a
function
right.
However,
that
function
has
a
bunch
of
properties
on
it
that
are
conceptually
named
exports
and
in
the
packages
I've
updated,
I've
written
a
wrapper
that
makes
those
as
named
exports
and
the
function
as
a
default.
So
my
intention
there
is
that
there
is
a
default
and
there
are
named
exports,
but
like
like
it's
not
an
object
full
of
that.
It's
not
just
named
exports.
B
A
C
A
A
The
potential
of
pushing
to
like
release
this
feature
under
a
flag,
an
experimental
flag
so
that
people
can
can
play
with
it
is
definitely
worth
exploring.
I
think
the
main
thing
that
we'd
want
to
figure
out
with
putting
it
behind
a
flag
would
be
like
this
feature
if
I
recall
correctly,
is
potentially
putting
like,
like
a
corn
in
the
like
hot
path
of
starting
up
note
now,
which
it
wasn't
before.
I
could
be
mistaken
with
that.
But
I
do
know.
C
It's
it's
pulling
in
some
wasm
library
for
oh
yeah,.
A
C
A
A
C
Or
the
flipside
could
be
like
all
the
people
that
are
currently
complaining
to
us,
that,
like
named
exports,
don't
work,
you
know
as
in
they
don't
work
like
they're
used
to
at
transpilers.
If
they're
still
complaining
that
they
don't
work
under
this
flag,
then
it's
like
okay,
so
we're
missing
the
mark
on
user
expectations
like
if
we're,
if
we're
never
gonna,
be
able
to
give
them
what
they're
expecting
then
we
might
as
well.
You
know
go
back
to
the
status
quo
where
it's
default
only,
and
we
have
a
good
error
message
or
something
like
that.
C
C
Complaining,
no
just
a
handful
of
issues
but
well
I.
Think
if
you
maybe
look
at
the
PR
that
guy
opened
I
think
he
linked
to
like
a
bunch
of
like
tweets
and
stuff,
but
like
it's
definitely
a
pain
point
like
it's
something
that
people
on
Twitter
have
pointed
out.
It's
like
this
is
a
really
big
missing
feature
from
like
node
zsm
implementation
that
that
named
experts
from
comedy
s,
don't
work
so.
A
A
thought
process
that
I
have
here
that
may
even
be
sufficient
as
well,
is
like
we
have
the
experimental,
specifier
resolution
flag,
which
we
may
or
may
not
remove
at
some
point,
but
it's
there
and
it's
not
being
liked
it's
there.
So
if
you
want
to
like
load
something
and
you
want
to
import
stuff,
it
feels
like
in
a
way
this
being
behind
a
flag.
A
That's
unobservable
off,
combined
with
the
experimental
resolution
flag
that
if
someone
wants
to
just
use
note
as
if
it's
babel
well
just
put
these
two
flags
on
in
your
project,
and
now
you
should
just
be
able
to
work
in
the
99%
case
right.
So
when
we,
when
we
think
about
like
ecosystem
transition,
there's
possibly
even
just
like
a
lot
of
value
in
having
this
behind
a
flag,
is
kind
of
just
an
escape
hatch.
A
C
But
the
flipside
is
that
you
could
do
either
of
these
things
in
loaders,
but
but
arguably
loaders
could
do
all
sorts
of
that.
We
would
never
merge
into
node
proper,
like
it
could
do.
It
can
actually
do
what
babbles
doing
it
actually
transpile.
You
know
we
can
do
JD
the
SM
thing,
and
so
then
they
like
really
get
that
that
that
perfect
user
experience
that
they're
expecting
these.