►
From YouTube: Node.js Project Modules Team Meeting 10/21/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
We're
now
live
with
the
october
21st
edition
of
the
node.js
module
team.
I'm
joined
with
myself
and
what
was
six
other
members,
although
one
of
them
has
vanished
five
other
members
of
the
team.
At
this
exact
moment,
we've
got
not
a
super
packed
agenda,
but
we've
definitely
got
some
meaty
topics
to
discuss.
A
B
Sure
I
think
we
carried
this
one
over
last
week
because
we
didn't
want
to
well
either.
We
were
hitting
time
on
on
the
discussion
and
also
at
the
same
time
we
were
looking
to
have
some
follow-ups.
There
haven't
been
any
further
follow-ups
in
the
threads
or
out-of-plan
discussions,
so
I
think
the
discussion
will
probably
go
much
the
same
as
it
did
in
the
last
meeting.
C
A
Okay,
so
want
to
move
on
to
the
other
issues
and
then
come
back
to
this
one.
A
Okay,
so
I
I
think
the
order
of
operations
here
that
would
make
sense
would
be
to
start
with
a
discussion
about
the
experimental
status
and
then
follow
with
the
discussion
about
like
the
ongoing
nature
of
this
group,
because
I
feel,
like
those
two
are
rather
hand
in
hand.
So
I
don't
know
if
anyone
can
help
with
notes
right
now,
but
it
would
be
helpful.
A
Here's
the
I'll
drop
in
the
chat
link
to
the
dock,
the
very
least,
if
you
could
add
your
name,
that'd
be
good.
So
we've
got
the
this
issue
that
guy
opened
yesterday
about
the
experimental
status
of
modules.
A
An
outline
of
things
kind
of
like
breaking
like
separating
between
the
core,
like
esm
implementation
features
versus
package
features,
and
one
hour
ago
someone
chimed
in
asking
about
the
vmesm
apis,
I'm
asking
if
we've
forgotten
about
them.
A
So
I
should
add
that
to
the
list
as
well,
and
I
believe
that
there's
also
kind
of
like
I'll
add
like
a
list
for
kind
of.
Like
other
other
features,
we've
got
the
ds,
vm,
esm
api
and
then.
A
I
think
that
I
guess
we've
oh
jeff
you're
still
there
jeff
were
the
ones
that
you
were
bringing
up
as
well
that
we
didn't
have.
C
Well,
I
guess,
before
we
move
on
to
the
past
the
vm
api,
then
the
main
thing
there-
it's
it's
not
just
experimental,
but
it's
also
incomplete
because
the
it
doesn't
offer
an
equivalent
there's,
no
like
equivalent
to
like
vm.script,
where
you
can
just
like,
run
a
string
essentially
as
if
you're
like
calling
it
calling
it
an
eval
like
there
is
no
equivalent
built
yet
for
that.
The
same
way
that
like,
if
you
wanted
to
do
you,
know
from
the
command
line,
node
input
type
equals
module,
eval,
something
some
string.
C
We
don't
have
a
way
to
do
that,
yet
in
node
core
and
that's
a
blocker
for
ts,
node,
it's
a
blocker
for
the
coffee
command.
It's
a
block
of
her
babble
like
any
any
utility
that
wants
to
like
transpile
into
esm,
javascript
and
then
have
it
be
executed
by
node.
The
only
way
they
can
do
it
right
now
is
like
launch
a
child
process
and
pass
it
in
as
like.
In
you
know,
the
string
into
input,
type
cetera.
D
C
That's
so
that's
something
that
we
need
to
add
to
the
list
of
like
a
missing
feature.
We
really
need
to
add.
I
don't
think
that's
controversial
at
all.
It
just
hasn't
been
built,
the
other
ones
that
that
I
remembered
were.
C
We
currently
have
no
way
to
do
hot
module,
reload
and
that's
a
problem
for
the
build
tools
that
currently
do
hot
module.
Reload
using
cjs,
I
think,
like
gil,
came
up
with
a
like
a
hacky
way
of
doing
it
of
adding
a
like
a
unique
query
string
on
the
end
of
an
import
statement,
but
without
a
way
to
remove
the
old
module
from
the
module
cache.
C
The
node
process
will
just
gradually
take
up
more
and
more
memory.
You
know
the
longer
it's
running
the
longer
a
dev
is
working
and
he
keeps
hitting
save.
So
I
don't
think
it's
really.
I
don't
think
we
can
consider
that
a
solved
problem
just
yet,
since
essentially
it's
only
solved
as
a
memory
leak,
the
other
one
was
instrumentation.
C
That
might
be.
I
mean
that
I
think
that
will
be
solvable
through
loaders,
I'm
not
sure
if
it's,
if
loaders
are
complete
enough
for
it.
I
think
that
was
part
of
the
the
part
of
the
motivation
behind
that,
like
global
preload
code
thing
that
yan
added,
but
I'm
not
sure
if
there's
any
missing
functionality
for
instrumentation
that
there
that
those
tools
are
waiting
on,
maybe
chaining
they're,
all
they're
waiting
on
chaining.
They
need
chaining
for
for
loaders.
In
order
for
that
to
work
so
yeah.
A
C
A
Yeah
I
added
the
I
added
the
that
list
that
we
just
came
up
with
to
to
my
tracking
issue
and
we
can
revisit
so.
I
guess
like
one
one
core
thing
that
I
wanted
to
maybe
just
see
how
people
are
feeling
about
to
start
with
would
be.
A
Do
people
agree
with
this
assessment
that,
like
we
likely,
should
separate
package
features
which
are
features
that
affect
both
esm
and
common
js,
such
as
type
module
input,
type
package,
exports,
imports,
conditional
exports,
sub
path,
exports
and
imports,
export
trigger
and
nested
conditions
and
sub
path
patterns?
Those
are
kind
of
like
one
category,
whereas
esn
itself
is
another
category
which
is
like
the
loader
named
exports.
A
Node
imports
data
imports,
import
meta,
built-in
modules
create
require
the
resolution
algorithm
top
level
away.
Common
js
named
exports,
json
modules,
wise
and
modules,
loaders
and
experimental
specifier
resolution.
Are
there
any?
Does
anyone
disagree
with
separating
those
two
things
from
a
stability
perspective
separately.
A
A
D
A
I
guess
the
the
big
difference
that
I
would
make
guy
is
like
it
feels
like
to
me,
and
I
could
be
wrong
when
we
talk
about
like
esm
and
node.
Like
specifically
esm,
we
could
say
that
esm
is
stable,
but
sub
path.
Export
the
sub
path
patterns
may
not
be
stable
yet,
and
I
don't
think
that,
like
subpath
patterns
not
being
stable,
should
block
calling
the
esm
implementation
itself
stable
right.
B
But
I
I
mean
I'm
saying
it
that
yeah
there's
there's
package
features
which
could
be
considered
unstable,
but
there
is
also
core
features
which
can
be
considered
unstable,
so
I'd
be
weary
of
making
any
blanket
judgments
for
packet
package
features.
A
Yeah,
I
guess
the
other
thing
that
I
was
thinking
about,
and
perhaps
this
is
like
this
could
be.
A
core
thing
is
like
it
feels
to
me,
like
package
features
could
likely
be
considered
stable
individually
as
each
of
those
features.
Some
of
them
obviously
need
to
be
grouped,
but
like
we
could
call
path
like.
I
think
it
goes
without
saying
that
package
exports
at
this
point
is
stable,
but
sub
path
patterns
isn't
some
path.
Exports
are
nested,
conditions
are
like,
and
those
were
kind
of
the
ways
I
was
breaking
it
down.
B
Yeah,
I
see
what
you
mean
that
that
makes
complete
sense
to
me
and
if
you,
if
we
want
to
just
start
going
through
the
list
you
can,
we
can
do
that
on
these
yeah.
A
And
then
I
guess
the
only
difference
that
I
would
say
is
for
esm,
because
I
don't
think
that
you
really
can
like
tease
these
apart
cleanly.
In
the
same
way,
I
feel
like,
and
in
particular
common.js
named
exports
is
like
the
only
one
that
seems
to
be
like
not
quite
there
yet.
I
feel
like
we
can't
call
esm
stable
until
kind
of
like
all
the
features
in
that
grouping
are
stable,
but
we
could
start
like
stabilizing
package
features.
E
Right,
I
think
the
the
part
where
I'm
not
quite
falling
on
that
and
like
the
only
difference
between
common.js
exports
and
subpath
blob
patterns,
is
it
it's?
It's
a
very
fine
difference
from
a
how
tightly
it's
coupled
to
esm
overall
like
in
both
cases,
you
are
importing
something
and
you
get
different
results
depending
on
whether
the
feature
is
supported
or
not.
E
A
And
I
guess
for
me
that
is
maybe
somewhere
where
I
don't
feel
super
comfortable,
because
people
don't
necessarily
know
when
they're
importing
and
doing
a
named
import
from
something.
But
I
guess
the
same
could
be
said
about
like
nesting
conditions
or
any
of
these.
These
features
that
are
being
used
by
module
authors.
I
guess
maybe
that's
that's.
A
big
difference
is
like
name
like
the
the
module
consumer
is
using
those
core
esm
features,
whereas
it's
the
module
author
using
the
package
features.
A
I
guess
to
me:
it's
like
it's
so
fundamental
to
the
way
in
which
esm
works
and
I'm
not
saying
that
we
should
wait
forever
for
it,
but
it's
like
we
just
shipped
it.
So
we
should
wait
like
maybe
a
month
or
two
get
some
feedback
make
sure
there
aren't
bugs,
but,
like
I
think,
simply
simply
put.
I
think
that
I
guess,
if
you
step
back,
I
would
say
right
now:
common
js
named
exports
are
the
only
thing
that
I
think
are
blocking
calling
the
main
esm
implementation
stable.
A
At
this
point,
I
just
dropped
the
issue
into
the
chat.
If
you
all
want
to
take
a
look
at
how
it's
the
order
that
I
put
in
there
in
case
anyone
you
know,
disagrees
with
anything
there,
but
I
think
to
to
an
example
in
the
other
way
is
like
top
level
weight.
A
I,
I
would
say
is
probably
still
arguably
an
experimental
feature
until
you
know
like
it's
actually
shipped
in
chrome,
although
we
are
arguably
may
also
want
to
say
top
level
await
is
an
experimental
feature
until
it's
like
stage
four,
but
that
shouldn't
block
us
calling
like
the
esm
implementation,
stable.
B
One
other
feature
I
can
think
of
user
conditions,
so
the
flag
for
setting
user
conditions.
I
would
like
if
we
could
include
that
as
stable,
because
production
development
workflows
rely
on
that
quite
heavily.
If
you
want
to
set
like
a
development
condition
in
your
conditional
exports,
so
I
mean,
but
I
guess
it
also
depends
on.
If
we're
documenting,
I
don't
think
we're
documenting
it
as
having
a
state,
an
unstable
state
and
then
do
you
want
to
discuss
vm
at
all
as
well
miles.
B
A
I
I
would
leave
it
really
easily,
as
I
don't
think
that
the
vm
modules
work
blocks
us
calling
esm
stable.
I
see
that
as
like
an
additional
feature
in
the
same
way
that,
like
I
don't
think
we
would
have
loaders
block,
doesn't
mean
that
you
know
there
isn't
still
a
lot
of
work
to
do
there,
but,
but
I
personally
don't
see
the
state
of
the
vm
module
as
being
a
blocker
to
call
an
esm,
stable.
C
I
think
there's
a
lot
of
value
in
making
as
many
package
related
features
not
experimental
as
soon
as
we
can
so
that
people
can
just
start.
You
know
publishing
packages
that
use
these
things
and
getting
this
getting
that
stuff
more
into
the
wild.
B
D
I
mean
stage:
three
features
are
like
the
gray
area,
but
I
think
that
for
node,
specifically,
if
because
it's
on
top
of
v8
right
like
miles
implied
earlier
that
when
v8
implements
it,
that
node
will
have
to
make
some
changes.
Is
that
right?
Yeah?
If
they're?
I
would
imagine
so
so
to
me
that
more
than
the
spec
status
is,
the
variable
you
know
is
the
the
risk
with
node's
implementation
of
top
level
weight
like
as
soon
as
chrome
has
shipped
it
and
node
is
using
that
same
implementation.
A
Yeah-
and
it's
like-
I
don't
believe,
but
it
could
be
wrong.
I
don't
believe
that
the
html
integration
has
fully
gone
through
yet
and
not
expecting
that
to
have
major
changes
to
how
it
works
or
how
our
implementation
works.
But
I
think
I
think
it's
inaccurate
to
call
it
stable
until
that's
done.
B
F
Concerns,
I
think
we
should
just
figure
out
what
we
want
to
do
with
vm
in
general,
but
that's
not
on
status
of
esm
itself.
A
I
guess
I
guess,
like
one
question
brad
I
would
have
to
you
is:
do
you
think
that
we'll
see
realms
anytime
soon.
B
Interface,
I
mean
it
does
have
some
similarities
with
compartments
as
well,
so
there
there's
definitely
crossover
in
those
design
spaces
where
foreseeably
in
the
future.
B
D
F
Well,
they
fundamentally
want
to
try
anything
else
before
having
separated
global
state,
so.
C
Getting
back
to
vm,
though,
like
I
looked
into
it
like
a
year
ago,
so
my
memory
is
a
little
hazy.
If
someone
can
remember
better,
but
it's
not
that
far
from
being
ready.
C
If
I
remember
right,
I
mean
it's
experimental,
I
think
what
we
really
just
needs,
like
the
difference
between
you
know
the
command
line
eval
with
input
type
and
the
node
one
is
that
the
node
api
that
you'd
have
to
call
is
the
node
api
requires,
like
100
lines
of
boilerplate
that
are
in
the
dock,
that
you
would
have
to
copy
paste
to
implement
like
your
own
function,
for
how
the
module
should
be
linked
together
and
so
on.
C
I
think
that,
like
all
we
really
need
is
like
another
api
or
a
slight
modification
of
the
current
api
that
just
has
defaults
for
those
like
for
the
linking
function
and
such
that
just
behaves
the
way
node.
Does
it
like
the
linker
from
the
node
loader
and
that's
that
which
I'm
sure
is
what
happens
with
the
command
line
version.
So
it's
probably
not
that
much
work.
So
the
last
time.
E
E
Unless
you
have
a
play
example
when
you
actually
want
to
do
proper
linking
so,
I
think
the
chunk
of
work,
from
my
perspective,
at
least
to
make
vm
modules,
actually
nice
and
usable,
would
be
to
expose
module,
loader
and
loader
job
to
some
degree,
which
is
more
work
than
just
patching
up.
Some
minor
things.
C
E
Think
there's
there's
two
separate
use
cases
for
the
vm
module
module.
One
is
I
just
want
to
eval,
but
otherwise
I
I
want
to
delegate
to
nodes
module
loading.
In
that
case
you
can
just
create
a
data
url
and
import
that,
and
you
get
kind
of
the
same
thing.
So
I'm
not
even
sure
how
much
the
vm
module
has
to
be
involved
with
that.
F
I'd
prefer
that,
but
at
the
time
gus
wanted,
in
particular
the
ability
to
insert
a
vm
dot
source
text
module
into
the
current
context,
module
map,
and
so
that
was
that
was
a
large
part
of
the
decision
for
why
it
wasn't.
E
F
F
B
If
we're
nitpicking
design
decisions,
another
thing
that
I
would
have
liked
to
have
seen
would
have
been
the
ability
to
have
like
a
singular
set
of
hooks
into
a
linking
function,
as
opposed
to
kind
of
passing
around
this
result
having
individual
resolve
functions
into
each
into
each
module
for
the
initialize
import,
meta
and
import
module
dynamically
hooks,
because
you
end
up
having
to
create
a
function
closure
for
every
single
module
for
those
two.
B
E
B
E
Okay,
yeah
but
yeah.
I
I
think
we
are
talking
about
the
same
kind
of
problem
where
it
was
it's
super
awkward
right
now
that
you
have
to
create
it
for
every
single
thing
and
then
also,
if
anything
in
your
virtual
but
effectively
realm
is
a
script
then
it
becomes
even
more
awkward.
I
think
right
now,
because
if
you
want
to
have
dynamic
input
from
the
script,
then
you
also
need
to
take
care
of
that
yeah.
E
F
Yeah,
so
one
thing
that
we
do
have
to
take
note
of
if
we
do
bind
things
to
a
context,
v8
theoretically
supports
cross
context
linkage,
but
they
say
not
to
do
it
because
things
may
break.
They
are
not
actively
trying
to
maintain
that
support.
F
F
A
So
kind
of
stepping
back
to
the
discussion
that
we
were
having
one
thing
that's
worth
pointing
out
also
is
that
I
did
open
a
pull
request
against
node
to
flip
a
handful
of
these
apis
to
be
the
package
features
to
be
considered
stable.
A
I
can
drop
this
into
the
chat,
so
I
think
I
guess
two
two
questions
that
I
think
would
be.
I
would
like
to
have
answered
by
folks.
One
would
be
do
you
agree
with
the
assessment
in
that
that
I
put
there
of
saying,
like
essentially
of
the
package
features,
sub-path
patterns
being
the
only
one
that
is
not
stable
and
are
people
okay
with
us
stabilizing
these
before
we
stabilize
esm
itself?
G
So
really,
yes,
webpack
five
supports
them
as
it
were,
but
the
new
react
apis
that
are
coming
out
require
nested
imports
that
are
defined
to
not
use
extensions
while
they
don't
provide
an
exports
map
that
says
that
they
don't
use
extensions.
So
when
you're
actually
trying
to
use
real
esm,
which
webpack
5
is
trying
to
things
fall
apart,
and
they
can't
change
it
because
it
breaks
preact
if
they
do
it's
fun
times
for
everybody.
G
Now
so
what
it
is
is
there's
a
new
react
api
that
implicitly
adds
imports
to
files,
so
things
that
act
as
transpilers
like
webpack
or
what
have
you
or
pablo
or
something
have
to
add
imports
to
the
file
like
for
the
user
and
those
imports
are
defined,
or
at
least
we're
initially
defined
to
not
have
extensions
on
them
all
right
now,
because
react
originally
didn't
have
an
exports
map.
This
meant
that
this
didn't
work
when
you
were
actually
using
esm
as
your
output
rather
than
common
js.
G
However,
preact
had
already
shipped
an
update
that
included
an
exports
field,
so
adding
the
extensions
broke
preact,
and
so
what
ended
up
happening
there
is
webpack
itself
had
to
change
so
that
it
could
look
it
up
with
or
without
the
extension
and
ignore
node
module
resolution.
G
G
B
F
G
There
is
definite
confusion
as
to
the
safety
of
adding
exports
to
a
package,
especially
considering
like
we
now
have
a
bunch
of
people
advocating
that
yeah
just
add
exports
don't
use
maine
and
that
is
causing
problems
actively
as
tools
and
people's
tool
chains
start
adding
support
for
exports.
Things
start
breaking.
F
It's
more
complicated
than
that.
It's
people
are
using
the
exports
field
expecting
to
have
the
common
js
resolution
algorithm
and
in
the.
B
Case
of
no,
I
mean
yeah
specifically
defined
an
api
with
its
exports
and
then
react
went
and
changed
its
api
when
preact
is
supposed
to
be
mirroring
its
api
and
and
then
that
didn't
support
the
existing
versions
of
react.
So
I
mean
in
theory
the
correct
fix
would
have
been
for
preact
to
ship.
An
update
to
update
itself
to
the
latest
react
api,
supporting
both
with
and
without
extensions.
B
G
Worth
noting,
this
also
broke
tslib
for
typescript
in
the
same
way,
doing
the
same
thing
except
our
fix,
rather
than
waiting
on
webpack
to
figure
out
how
to
sort
it
out
in
a
way
for
every
package
that
has.
This
problem
was
to
include
some
extra
conditions,
just
for
webpack,
like
a
module
condition
and
so
on.
G
B
So
these
are,
you
know
the
strong
edge
cases
that
are
coming
up.
I
mean
we've
got
something
like
one
in
a
hundred
packages
has
es
module.
Was
it
when
we
did
the
test?
What
I
think
ten
percent
of
packages
so
one
in
ten,
and
then
of
that
that
10,
the
ones
that
have
that
default
conflict
that
you
hit
up
against
in
tier
slip,
or
maybe
like
one
in
50
or
one
in
100
or
maybe
even
more
of
those.
B
So
we're
dealing
with
like
the
sort
of
0.0,
0.1
and
below
cases
here
or
even
even
more
than
that
is.
G
E
Just
to
just
to
clarify
on
the
react
side,
so
does
react,
itself
has
exports
and
if
so,
if
they
don't
have
a
export
for
slash
hooks
without
an
extension,
isn't
that
incompatible
with
every
every
single
piece
of
code.
G
G
So
it's
not
that
react
has
exports
react
actually
explicitly
doesn't
have
exports.
Yet
it's
preact
that
has
exports
and
so
react
changing.
Whether
or
not
their
transpilation
plug-ins
added
extensions
to
their
imports
was
a
breaking
change
for
non-react
packages
that
did
have
exports
like
pre-act,
which
was
unexpected,
to
say
the
least.
E
G
G
B
B
B
F
Some
way
responsible
for
that
yeah,
that's
the
exact
issue,
but
on
the
web
you
would
need
the
extensions.
G
G
B
C
D
D
So
we,
we
essentially
created
the
issue
where
some
packages
are
going
to
choose
to
use
extensions
on
the
left-hand
side
and
some
are
not,
and
that
means
users
are
going
to
have
to
figure
out
either
by
reading
or
by
experimenting
which
form
to
use
for
every
single
package.
And
in
this
case
the
experiment
only
played
itself
out.
D
E
And
even
for
the
one
level,
the
the
big
point
for
me,
why?
I
think
the
guidance
of
for
bear
specifiers,
don't
use
extensions
is
correct,
is
because
it
it
is
the
only
choice
that
survives
transpilation
across
a
tree.
If
you
add
an
explicit
extension
and
then
your
dependency
wants
to
have
different
file
extensions
for
common
js
versus
versus
esm,
then
your
code
can
no
longer
be
transpiled
because
it
in
its
transformed
form,
it
would
potentially
need
to
use
a
different
extension
in
a
specifier.
E
And
now
your
translation
is
a
lot
harder
and
all
your
main.
D
E
E
I
think
we,
our
guidance
in
the
docs
in
theory,
already
covers
this,
as
far
as
I
remember,
and
would
have
pointed
them
roughly
in
the
right
direction
of
not
having
the
extension
and
it
is
slash,
hooks,
not
select,
slash
hooks
dot,
js
and
if
they
would
have
used
export
maps
instead
of
depending
on
sub
path
serving
being
wide
open
for
web
usage,
if
they
would
have
used
xbox
maps.
E
So
this
is
actually
an
example
where
react
ran
into
a
problem,
because
it
did
not
depend
on
exports,
they
depended
on
pre-export
behavior.
So
I'm
not
sure
if
this
is
actually
something
about
export
stability.
B
That
web
pack
fix
does
worry
me
because
it
means
that
webpacks
potentially
now
I
basically
intentionally
not
following
the
spec
for
exports
and
as
a
result,
any
resolver
implementations
that
do
follow.
The
spec
are
not
necessarily
going
to
match
the
ecosystem
where
webpack
meets
them
and
that's
that's
kind
of
yeah.
That's
kind
of
annoying
yeah
yeah.
G
E
D
For
almost
a
year
now,
I
think
I've
I've
made
it
very
clear
to
the
react
team
that
I'm
more
than
happy
to
write
a
pr
adding
the
exports
field
as
soon
as
they
tell
me
they'll
what
they
want
it.
I've
made
that
offer
to
a
number
of
packages
and
like
so
it's
not
that
they
even
had
work
to
do.
All
they
had
to
do
was
give
me
a
thumbs
up.
B
This
is
all
contributing
to
like
some
serious
fight
and-
and
maybe
that's
a
good
thing-
maybe
it's
a
good
thing
if
people
adopted
cautiously
and
and
we
slowly
sort
of
integrated
through
the
ecosystem
at
the
same
time,
you
know
there
are
clear
guidelines
that
you
can
follow
and
you
can
do
this
stuff
safely
and
without,
and
you
know
so,
yeah
it's
a
tricky
line.
B
I
mean
I
just
the
worry
with
going
too
slowly
is
webpack
starts
to
do
a
whole
bunch
of
stuff
that
then
sort
of
changes.
The
direction
of
these
specs
that
we've
carefully
worked
out,
and
then
we
have
we're
back
to
compatibility
issues
when
we
want
to
move
off
webpack
into
es,
build
or
other
tools
that
are
that
are
then
just
wanting
to
support
webpack.
F
Assumption
to
my
knowledge,
webpack
is
just
doing
whatever
it
feels
right.
E
G
B
Yeah,
but
you
should
go
to
the
package
that
has
the
bad
config
and
if
webpack
has
the
mentality
that
it's
just
going
to
fix
every
single
case
I
mean
then
we're
back
to
that.
That's
the
root
cause
of
you
know,
compatibility
issues,
and
maybe
it's
good
for
webpack,
because
they
get
to
make
sure
that
their
unique
semantics
can't
be
replicated
and,
and
you
have
to
use
webpack
but
yeah.
That's
not
what
we're
aiming
for
here.
F
Oh
good,
we're
kind
of
passing
blame
around
right
now
and
we
we
have
a
few
things
we
could
do
that
are
more
actionable
than
passing
blame
round.
One
is:
is
there
some
way
we
could
have
provided
detection
for
this
change,
in
particular
the
missing
exports
and
added
exports?
F
F
I
wonder
if
we
could
look
into
adding
that
to
these
tools
rather
than
having
them
go
and
change
the
resolution,
and
this
would
actually
also
encourage
people
like
preact,
because
it
would
instead
of
pointing
the
problem
at
webpack.
It
would
point
it
directly
at
preact,
which
was
what
was
missing
the
exports
field
for
those
with
extensions
there's,
also
linting
things
we
could
do
around.
If
you
are
adding
stuff-
and
you
don't
have
the
extension-
I
mean
we
could
at
least
for
now
encourage
linting
against
it,
while
the
ecosystem
is
upgrading
piecemeal.
F
Also,
when
we're
talking
about
things
like
these
edge
cases,
just
how
can
we
give
users
feedback
so
that
they
can
take
control
of
things?
So
one
of
the
problems
here
is
that
users
couldn't
alter
preact
to
have
this
act.
Did
it
on
their
behalf
by
changing
webpacks
resolver,
we
have
exports
as
an
integrity
mechanism,
I'm
wondering
if
we
could
have
introduced
some
way
to
more
easily
override
what's
on
disk
when
they
start
up
their
application
so
yeah.
I
think.
D
B
F
If
you
use
the
common
js
resolver,
we
could
make
a
linting
library
or
something
like
that.
That
links
the
package
json
and
at
least
for
now
says
hey.
The
entries
in
your
exports
field
do
not
conform
to
everything
that
a
common
js
resolver
would
have.
B
Like
I'm
almost
tempted
to
say
that,
like
the
the
confusion
was
the
subparts
that
that
subparts
shouldn't
have
extensions,
I
mean
I
think,
if
we
could
maybe
agree
to
push
that
quite
strongly
or
not
in
this
group.
You
know
maybe
in
other
ways,
but
I
feel
like
people
like
it's,
it's
the
understanding,
the
distinction
between
subpart
extensions
on
packages
and
using
extensions
in
in
relative
specifiers,
and
if
there
was
some
way
to
get
that
information
across.
I
also
would
have
avoided
this.
E
G
It
would
also
definitely
help
if
we
like
got
package
publishing
tool
chains
like
yarn
npm,
to
check
this
kind
of
thing
automatically
on
publish,
rather
than
relying
on
dogma,
that
we
attempt
to
push
out
and
teach
to
people,
because
well.
Relying
on
education
doesn't
scale
particularly
well.
E
B
Yeah
I
mean,
maybe
this
problem
doesn't
scale
as
much
as
we
think
it
might.
The
concern
is
just
if
the
webpack
patch
inadvertently
creates
patterns
that
then
you
know,
are
now
their
new
compatibility
thing,
but
I
yeah
linting
on
publish
is
a
huge
one,
and
you
know
if
we
were
able
to
suggest
not
using
extensions
in
exports.
I
would
suggest
even
having
linters
lint
if
you're
not
exporting
the
non-extension
form
and
say
it's
normally
advised
to
also
make
an
export
without
the
extension,
because
that
was
actually
react.
B
Misunderstanding
was
thinking
that
they
should
be
advocating
for
react
forward,
slash
hooks
dot,
js
or
whatever
it.
B
I
don't
know
if
we
can
collaborate
with
any
package
teams
on
these
kind
of
things
or
typescript
lenses.
I've
seen
typescript's
got
some
great
linting
for
exports
field
as
well.
These
foodie
we
support
the
exports
field
at
all.
Yet
what
I'm
getting
exports
package.json
linting
in
my
vs
code,
if
it's
not
typescript,
who
is
it?
Oh,
that's!
That's
that's
vs
code
itself.
It
does
json
schema
validation
on
all
json
files,
yeah
I'm
getting
proper
exports,
validation
and
even
caught
something
where
I
actually
entered
the
wrong
exports.
G
That's
amazing
right!
Where
is
that
sourced
schemastore.org.
G
The
ts,
config.json
and
js
config.json
schemas
are
also
up
there.
Every
well-known
json
document.
A
So
it
would
appear
that
we
have
run
through
our
timing,
we're
at
a
time.
I
guess
we
should
wait
until
the
next
meeting
to
have
the
discussions
about
if
we're
going,
to
keep
having
meetings.
A
E
G
Okay,
like
I
I
personally,
am
like
it
can
stabilize,
but
like
I'm
like
so
the
members
of
my
team,
that,
like
were
informed
of
the
situations
that
arose
in
the
past
couple
weeks
or
just
like
we're,
not
adding
support
for
this
in
the
near
future
right.
This
is
clearly
unstable
right,
I'm
just
like
well,
for
now,
it
is
yup
thumbs
up,
definitely
unstable
right
now.
It's
like
it
doesn't
feel
stable
to
people
who
are
looking.
E
Yeah,
I
think
the
the
problem
is
that
we
are
getting
more
and
more
into
chicken
and
egg
problems
where
people
in
order
to
use
it
need
support
in
a
bunch
of
different
ecosystem
tools
and
the
ecosystem
tools,
look
at
the
experimental
status
and
say
well.
We
won't
support
this,
but
it
is
experimental
and
so
important
projects
don't
use
it
because
the
tools
don't
support
it,
which
means
we
don't
get
really
better
signal
or
like
this.
E
Just
it
cannot
really
be
used
right
now
to
to
to
the
full
extent,
because
we
can't
really
solve
these
issues,
because
the
tools
that
we
would
need
to
solve
issues
don't
even
support
it,
because
they
can't
support
something
fundamental.
So
it's
I
think
stabilizing
in
our
docs,
is
a
good
signal
that
we
would
expect
ecosystem
tools
to
help
us
stabilize
it.
B
I
mean
yeah.
The
point
is
that
the
stabilization
that
we're
talking
about
is
the
fact
that
node.js
is
making
a
promise
to
its
users,
that
what
is
implemented
is
not
going
to
change
and
that
they
can
build
on
top
of
it
and
they
can
rely
on
these
semantics
and
things
are
not
going
to
break
out
from
under
them,
and
I
think
that
guarantee
is
the
important
signal
that
that
users
need,
and
the
fact
is
that
we
can't
the
things
that
we're
talking
about
marketing
stable.
B
We
can't
even
change
them
now
that
we've
got
this
degree
of
usage
of
you
know
what
was
it
seven
or
eight
thousand
sorry,
four
or
five
thousand
packages
with
the
exports
field?
Now
so
yeah
I
mean
the
only
thing
is
sorry.
I
know
we're
going
over
time.
I'm
just
thinking
as
I
go
here.
The
only
thing
is
with
exports.
Maybe
we
want
to
do
the
deprecation
for
trailing
path
in
exports
that
we
sort
of
silently
dock
deprecated.
A
So
I'm
sorry
to
interrupt,
but
we
should
stop
the
stream
and
I
have
to
get
to
another
meeting.
Do
we
want
to
kick
this
off
to
the
stabilization
issue
that
we
have
and
and
move
the
con
conversation
async.