►
From YouTube: 2021-07-29- Package Maintenance Team meeting
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
Welcome
to
the
node.js
package
maintenance
team
meeting
for
july
29th
2021.
we'll
follow
our
agenda,
which
was
issue
number
474
in
the
repo
and
before
we
get
there
is
there
any
announcements.
People
would
like
to
share.
B
Actually,
yeah
I'll
jump
in
sorry.
I
wasn't
planning
on
doing
this,
but
we
just
had
a
good
discussion
yesterday
and
so
it
made
me
think
I
should.
I
should
start
promoting
this
more
everywhere,
so
the
package,
vulnerability,
reporting
and
mitigation.
I
think
I
just
got
their
name
wrong,
but
collaboration
space
is
starting
to
kick
off
we're
having
some
discussions
with
some
npm
folks
in
the
rfc
process
about
a
proposal
that
tyranny
made,
which
is
like
counter
claims,
which
is
one
of
the
big
topics
we
wanted.
B
So
I
think
there
is
enough
folks
getting
involved
in
the
discussion
that
it
would
be
a
great
thing
also.
You
know
all
that
really
kicked
off
from
this
group.
So
if
anybody
is
interested
in
joining
that,
I
can
I'll
drop
links
to
the
npm
rfc,
that
tyranny
opened
and
also
the
package
the
the
collab
space
as
well,
so
that
so
folks
can
get
involved
there
well.
B
Well,
probably
the
goal
of
the
collab
space
is
to
facilitate,
but
when
things
are
happening
in
other
repos,
like
the
npm
rfc
repo,
like
that,
that's
great,
and
so
you
know
we'll
we'll
have
sort
of
a
multi-pronged
approach.
I
think
to
getting
those
things
evangelized
and
getting
the
right
people
in
the
room
to
talk
through
them,
so
so
join
it
in
whatever
way,
you
think
is
is
valuable.
A
B
A
I
will
move
on
then
in
the
agenda,
so
the
we
only
have
two
things
tagged
for
the
agenda
and
owen
mentioned.
He
also
has
something
which
we'll
talk
about
when
we
get
through
those
the
first
one
is
number
458
status,
update
and
next
steps
for
pkgs
create.
B
Oh
yeah,
the
last
the
take
the
takeaway
from
the
last
meeting
specifically
was.
I
was
going
to
talk
to
wes
about
trying
to
move
that
org
into
or
that
repo
or
there's
a
create
package.js
repo.
That
wes
has
that
we
were
talking
about
moving
into
the
pkg
js.
I
don't
have
any
particular
updates
on
the
status
of
the
pack,
the
project
in
general.
Again,
it's
another
thing:
cool
cool
good
to
hear
yeah.
B
Oh
cool,
I
didn't
see
that
yeah.
I
did
it
like
like
right
before
the
meeting.
I
was
going
through
the
notes
and
I
went.
Oh,
I
have
an
action
item
here.
I
should
just
do
it
so
that
I
could
tell
them.
I
did
it
for
the
meeting.
That
said
I
I
made
it.
I
made
an
issue
and
commented
one
of
the
things
I
had
been
hoping
to
do
before
moving.
B
It
was
update
to
all
the
requirements
of
this
org
so,
like
I
don't
think
it
has
the
code
of
conduct
in
place
like
it's
missing.
B
The
same
stuff
from
under
my
repo,
which
you
know
whatever,
but
I
just
transferred
it
at
least
that
gets
well
I
had
I
think
I
had
added
everybody
and
those
updates
could
have
been
made
in
place
under
mine
before
moving
it.
I
realized
I
was
being
a
blocker
for
much
too
long
here,
so
I
added
the
collaborators
and
owners
repo,
sorry
user
groups
from
the
create
repo.
B
B
The
contributors
have,
I
think,
right
permissions,
which
is,
I
think,
what
we
decided
was
the
standard
for
for
how
we
would
manage
excess.
I
have
not
updated
anything
on
the
the
npm
side
yet
so
I
can.
I
forgot
how
we
were
planning
on
doing
that,
where
we're
going
to
just
add
all
the
owners.
B
B
Either
way,
I'm
I
am
very
quick
at
doing
administrative
tasks.
So
if
you
need
that,
like
I
like
adding
people
like
anytime,
anybody
asks
for
access
to
the
github
repo,
I
added
them
right
away.
That's
really
easy!
So
if
we
get
to
the
point
where
we
have
a
release
to
make,
which
I
don't
think
we
do
right
now,
I
think
everything
that
was
in
there
that
got
merged
has
been
released.
But
you
know
we
can.
B
I
can
start
adding
people
really
easily
on
the
npm
package.
So
last,
while
I
got
you
since
we're
in
the
since
it's
in
the
org
now
the
license
field
and
the
package.json
I
think
is
ics,
which
I
don't
think
is
a
real
pac
license.
So
I
just
opened
a
pr
to
change
it
to
isc.
B
B
B
I
ran
it
on
the
package
itself
and
one
of
the
things
in
the
diff
was
that,
and
I
was
like
that's
okay,
so
yeah
that
that
makes
perfect
sense.
I
bet
you
any
money,
since
I've
been
using
this
package
to
scaffold
out
my
packages
for
a
long
time
that
that
is
rampant.
Probably
in
a
bunch
of
my
projects,
that's
funny!
Well,
I
literally
just
fixed
the
package.json,
I
think
in
the
code
it
does
it
properly.
B
So,
oh
okay,
maybe
that
had
been
fixed
previously,
then,
okay,
if,
if
not
I'll,
look
into
that
but
yeah
anyway,
let
me
well
while
I'm
on
I'll.
Add
you
because
I'm
not
sure
are
you
in
that
that
group
to
be
able
to
have
right
access?
No,
I
don't
think
so.
Okay,
I'm
looking
at
the
pr
open
and
I'll.
Have
it
right
so
I'll,
find
the
team
and
add
you
right
now
and
same
for
anybody
else
who
wants
to
start
working
on
that
project?
We
have
it
the
team.
Can
the
team
management?
B
A
B
Okay,
so
I've
I've
met
with,
I
think
three,
maybe
four
different
people
and
given
sort
of
a
high
level
overview
of
what
the
initial
design
was
and
there's
a
there's,
an
issue
in
the
create
pkgs
create
repo
which
has
sort
of
a
diagram,
but
really
what's
important,
to
understand
and
about
the
way
that
it's
designed
is
specifically
that
we
as
an
ecosystem,
have
seen
a
lot
of
changes
in
how
people
scaffold
projects
in
the
history
of
javascript
right.
So
we
like
go
back
and
there's
a
lot
of
bespoke
things.
B
Then
there
was
like
a
yeoman
was
very
popular
for
a
long
time.
I
I've
met
with
a
couple
folks,
like
paypal,
has
a
specific
ecosystem
of
things
they
use.
B
You
know
people
like
plop,
there's
the
work
that
the
the
create
react,
app
has,
which
is
sort
of
a
bespoke
thing
as
well,
so
there
anyway,
there's
all
these
different
approaches
that
people
take
to
scaffold
out
packages,
so
the
specific
design
of
create
package
json,
pkgjs
create
and
the
underlying
tool
opta
was
to
try
to
better
interrupt
with
those
other
tools.
B
B
You
could
drop
it
into
your
yeoman
generator
and
take
and
never
use
the
cli
or
the
interactive
prompt,
because
yeoman
already
has
that
and
pass
your
options.
You've
collected
from
the
yeoman
generator
straight
to
our
tooling,
or
if
you
didn't
want
that,
and
you
wanted
to
do
it
the
other
way
around.
You
should
be
able
to
take
our
input
and
pass
it
to
yeoman
right
and
again.
This
is
all
to
just
make
it
so
that
we
aren't
making
like
in
previous.
B
Plop
has
some
opinions
and
if
you
try
to
mix
and
match
yeoman
and
plop
like
those
didn't
work
very
well
so
anyway,
the
idea
here
is
that
our
core
tooling
should
be
flexible
enough,
that
other
ecosystems
can
leverage
it
without
us
having
to
like
jump
through
a
ton
of
hoops
like
providing
adapters
and-
and
you
know,
a
bunch
of
complicated
translation
layers
now,
whether
or
not
it
does
that
so,
I've
tried
it
out
with
yeoman
with
the
pkg
js
create
and
the
create
package
json
things
and
it
seemed
to
work.
B
Well,
I
got
a
decent
user
experience.
I've
also
used
this
same
stack
inside
of
some
package.
Scaffolding
work
in
netflix,
where
we
have
a
tool
that
also
operates
on
you
know
like
in
packaging
or
product
project
init
time,
and
it
does
seem
to
work
pretty
well
and
be
flexible
enough
to
get
the
job
done.
That
said,
it
is
still
pretty
early
stages.
B
So,
like
I
imagine
that
getting
integration
examples
with
other
ecosystems
would
be
a
really
valuable
thing
to
make
sure
that
what
we
provide
can
be
leveraged
by
them
and
isn't
going
to
be.
You
know
the
design
doesn't
have
any
gaps
or
or
problems
with
it.
So
that's
one
thing
I
definitely
haven't
done,
which
I
think
would
be
good
and
then
go
ahead.
Sorry,
I
guess
that's
a
good
stopping
point.
A
B
Yeah,
so
that
is
definitely
one
primary
goal.
I
I
didn't
cover
right,
so
so,
through
a
bunch
of
conversations
with
folks
at
npm,
there
have
been
requests
for
additions
to
npm
init's
default.
Some
of
those
are
rather
complicated.
B
So
if
you
think
of
things
like
package
exports,
which
is
added
by
the
node
project
but
npm
init
has
never
supported
it
right,
so
folks
have
to
go
and
and
craft
the
data
structure
that's
required
there
and
you
know
make
sure
that
it's
right,
it's
sort
of
a
manual
process
similar,
like
the
the
I
hope,
man
and
blanking
them
type
field,
module
or
or
common
js-
was
another
one.
B
That
people
asked
and
there's
a
lot
of
caveats
and
you
need
to
there's
some
user
experience
that
they
weren't
quite
ready
to
tackle.
So
so
the
general
idea
was
like
hey.
Maybe
the
package
maintenance
working
group
can
help
maintain
some
of
that
infrastructure
by
providing
a
package
that
has
good
defaults
and
integrates
more
of
this
functionality
so
that
npm
isn't
a
blocker
right.
So
folks
from
the
modules
team
could
have
come
to
the
package,
maintenance
team
and
said:
hey
we're
going
to
add
package
exports,
here's
how
we
think
they
work.
B
B
And
then
once
we
have
a
robust
solution
here,
we
would
just
have
the
npm
documentation
swap
out
people's
recommendation
from
what
is
today
and
just
npm
init
to
npm,
init,
pkg
and
so
npm
init
pkg
would
then
run
the
our
repo
right,
the
the
our
project
create
pkg
or
sorry
pkgs
create.
I
think,
darcy
got
somebody
to
transfer
the
name,
create
dash
pkg,
so
we
own
that
and
and
can
publish
on
it
now.
B
But
that
said,
that's
just
the
that
is
one
piece
of
it
that
that
the
design
can
work
as
a
standalone
like
the
create
package.
Json
work
standalone,
but
the
key
is
to
be
a
foundation,
so
that
not
only
does
it
work
standalone
and
we
can
start
recommending
it
for
npm
init,
but
people
can
also
integrate
it
into
their
more
complicated
package.
B
Scaffolding
workflows
right,
so
you
know
if
they
have
more
opinion.
Things
like
I
want
mocha,
not
just
right.
Somebody
could
wrap
our
thing.
That
would
then
automatically
install
mocha
and
set
up
a
test
directory
with
all
the
proper
mocha
accoutrements
you
know
or
if
they
were
doing
a
react
project
and
they
wanted
to
then
integrate
our
package
json
scaffolding
and
code
of
conduct
and
all
these
other
little
things
that
we
might
add
into
their
react
project.
B
D
Yeah
one
thing
that
came
to
mind
is
you're
talking
about
the
the
groups
or
like
npm
in
it,
and
all
that
is
there
any
chance
intentionally
or
not
that
somehow
we'd
be
able
to
find
okay,
the
trend
of
like
so
it
sounds
like
this
would
set
a
default
which
maybe
does
or
doesn't
align
with
what
npm
thinks
npn
in
its
default
should
be
for
good
reasons.
D
You
know,
I
know
cjs
esm
still,
you
know
make
making
its
way
through
the
ecosystem,
but
I
know
it's
also
common
that
could
this
eventually
maybe
or
would
npm
do
we
know,
would
be
open
to
be
like
all
right
now,
we've
rolled
this
out
for
six
months,
12
months,
the
overwhelming
majority
of
usages
are
type
module
and
exports
map.
Could
we
maybe
make
these
more
prominent
npm
in
it?
So
you
know
eventually
those
yes.
D
B
Yeah,
so
I
think
there's
definitely
some
discussions
to
be
had
and
they're
pretty
open.
I
think
the
main
issue
is
that
they
really
have
a
lot
of
innovation
that
needs
to
happen
on
just
package
installing
and
like
they've,
been
you
know.
As
far
as
staffing
goes,
they
you
know,
they're,
not
they're,
definitely
not
overstaffed,
you
know.
So
when
it
comes
to
things
like
working
on
more
complicated
init
flows,
I
they
just
haven't
had
the
bandwidth.
B
So
so,
yes,
I
think
they're
willing
to
change
the
behavior
of
npm
init
when
it's
bare
right,
just
literally
npm
in
it,
but
I
think
what
the
hope
is
is
that
there
is
really
a
big
difference
between
initializing,
a
package
and
initializing.
An
application
and
npm
init
serves
both
today
and
I
don't
think
we're
interested
in
trying
to
come
up
with
a
package
scaffolding
for
for
apps
or
some
of
these
other.
You
know
use
cases
we're
really.
Our
work
is
really
focused
on.
B
B
Init
react
right,
I
think
yeah
so,
like
you
can
you
can
do
it
that
way,
yeah,
but
this
is
just
in
a
similar
vein
like
this
is
a
feature
of
a
knit
is
to
call
out
to
a
separate
package
that
does
more
robust
things,
whereas
npm
init
is
strictly
the
bare
minimum,
you
need
to
run
a
to
publish
something
to
npm
right,
and
so
I
think,
even
if,
even
if
they
do
start
looking
at
adaptations,
I
don't
think
that
we
would
take
like
our
create
package
and
just
up
level
it
straight
to
be
theirs,
because
we're
gonna
make
much
more
opinionated
decisions
about
what
a
package
should
be
right,
which
is
gonna.
B
Have
things
like
a
readme
and
gonna
have
things
like
you
know.
I
think
we
have
a
list
of
of
possible
editions
in
in
one
of
the
repos
and
like
that's
just
never.
Gonna
land
as
npm,
and
it
because
it
shouldn't
because
npm
in
that
regard
serves
a
slightly
different
use
case.
D
I
think
that's
a
you
made
a
great
kind
of
point
there
about.
What's
you
know,
is
there
a
good
way
to
frame
the
boundary
around
npm
in
it,
and
it's
like
just
the
minimum
to
get
something
published?
I
guess
maybe
which
makes
sense,
as
you
know,
kind
of
maybe
a
more
or
not
as
superficial
line,
but
I
I
guess
maybe
my
thought
is
or
something
that
comes
to
mind
is:
do
you,
I
guess
maybe
for
your
personal
motivation
or
you
know
or
aside,
is
there
any
interest
to
use
like?
D
I
guess
in
your
from
your
perspective,
like
is
the
defaults?
How
opinionated
is
your
default?
Are
we
talking
about
like
type
equals
module
exports
map,
or
is
it
still
going
to
be
try
and
be
a
bridge
between
the
two?
Or
can
this
be
the
way
to
say?
Let's,
let's
draw
the
line,
the
sand
we're
trying
to
be.
C
B
My
head
around
it
recently
basically
well
one.
I
see
the
first
off.
I
see
create
package
json
as
the
particular
piece
that
will
probably
replace
init,
because
that's
essentially
what
a
knit
is
for
today
is
create.
You
know
you
can't
npm
install
anything
until
you've
run
in
it
essentially,
but
the
way
I
see
that
is
like
I
see
mvp
of
init
being
feature
parody.
Personally,
I
see
it
as
feature
parody
with
npm
init
today,
just
the
same
defaults
and
then
eventually
like
so
the
tool
itself.
B
Exactly
but
then,
basically
making
it
really
easy
to
then
inject
your
opinions,
like
you
know,
you
can
then
require
in
like
a
style
guide
to
then
change
exactly
how
that
works.
Like
jordan,
jordan
asked
a
question
on
the
package
maintenance
issue
about
checking
in
on
this.
That
kind
of
really
helped
crystallize
it
for
me,
which
was
he
was
like
basically
like
those
opinions,
could
look
like.
Is
this
going
to
be
a
package
for
node?
Is
it
going
to
be
a
package
for
browser?
B
B
Maybe
let
me
just
add
a
few
more
little
details
here
that
I
think
that
aligns
pretty
well
with
the
way
I
think
about
it.
One
thing
that
I
think
is
maybe
a
little
different
and
you
know
this
could
be
up
for
discussion
again.
I
I
don't
have
like
all
the
answers
here,
but
I
think
the
default
experience
should
go
above
and
beyond
so
for
even
for
just
create
package.json
should
go
above
and
beyond,
even
in
first
iteration.
If
we
can,
what
npm
init
does
I
think
there
are?
B
So
if
you
look
at
people's
workflows
and
you
look
at
prior
art
here-
no
one
really
just
leaves
it
at
npm
in
it.
So
even
like,
like
I
was
thinking,
tyranny
has
this
tweet
that
he
retweets
every
every
six
months
or
something.
That's
like
here's,
how
I
start
a
package
and
it's
like
npm
init,
npm
licensee,
create
licensee,
and
then
he
has
like
three
or
four
steps
right
and
so,
like
really,
I
see
even
the
default
from
the
create
package.
Json
level
should
be
a
bit
more
robust
here
right.
B
That
is
the
stuff
I
see
landing
even
as
defaults
in
create
package.json
right,
and
then
we
go
to
the
next
level
up
the
create
pkg
or
whatever
we
call
it.
You
know,
that's
the
package
name
that
we
want
to
publish
under
that
would
then
encapsulate
strong
opinions
from
this
team
right.
A
D
Change
the
intent
of
the
package
like
the
license
field,
or
authors
or
audits,
or
all
the
kind
of
ecosystem,
as
opposed
to
like,
because
if
you
make
a
change
to
module,
you
know,
that's
that's
fairly
substantial.
That's
either
gonna
break
or
keep
your
package
working.
So
that's
that's
interesting
in
that
regard
yeah.
So
I
think
that
all
makes
sense
and
also
sounds
like
another
advantage
of
this
over
just
delegating
the
npm
in
it
is
that,
in
a
way
you
can
almost
unlike
npm
minute,
you
can
almost
kind
of
pipe
into
this.
D
So,
like
your
default
start
with
their
defaults
can
go,
be
the
baseline
for
your
defaults
and
you
kind
of
just
merge
one
on
top
of
the
other,
and
then
it
goes
the
next
layer
of
opinion
and
the
next
layer
of
opinion,
and
they
can
cherry
they
can
either
just
take
it
or
be
like.
Well,
I
like
everything,
but
at
this
you
know
more
opinionated
level,
just
change
this
one
property,
but
I'll.
D
Take
everything
because
that's
I
think
for
myself
and
I
think
what
would
be
really
awesome
for
something
like
this
is
also
just
seeing
very
plainly
like
here
is
a
modern
package
json
if
you're,
making
a
ui
library
like
a
web
component
library
you're
going
to
want
type
equals
this
and
exports
looks
like
that.
I
think,
on
top
of
that,
I
don't
know
if
they
exist
the
tool
for
making
export
maps.
D
I
don't
know
if
that's
too
out
of
scope
for
this,
but
it
would
be
nice,
especially
during
the
transition
to
just
kind
of
be
like
here.
You
know,
in
addition
to
the
the
tool,
but
also
like
just
concrete,
I
hate
to
say
copy
paste,
but,
like
you
know,
you
could
in
theory,
if
you
weren't
integrating
into
toy
like
I
just
I
forget
what
it
is.
D
Can
I
just
see
an
example:
it's
like
it's
there,
because
that
was
the
one
thing
I
started
to
regret
about
things
like
yeoman
is
that
it
was
very
hard
to
just
see
the
example
output,
because
everything
was
just
so
granularly
broke
down
step
by
step.
Like
you
just
couldn't
see,
you
know,
I
start
with
nothing
and
is
just
the
10
lines
that
I
just
went
through
20
questions
to
get
so,
but
you
know
for
cras
and
all
those
things
this
would
be
awesome
to
keep
everybody
consistent
on
those
settings.
D
B
Yeah,
so
I
could
maybe
give
a
little
bit
of
a
ideas
that
I
was
thinking
about
for
some
of
what
you
mentioned
so
first
seeing
examples,
that's
something
that
it's
not
doing
very
well
right
now.
One
thing
I
think,
from
a
ci
perspective
we
should
have
for
this
package
is
we
should
have
a
directory
called
examples
that
has
my
goal,
and
this
is
a
testing
goal
really
is
to
have
the
tests
output
one
of
every
variant
to
an
examples
directory
and
then
the
cool
thing
would
be
is
if
you
had
ci.
B
That
would
like
that.
You
could
use
that
as
like
a
snapshot,
testing
approach
right.
So
I
this
is
one
of
the
things
I
wanted
to
integrate,
but
never
had
the
time
to.
I
think
chris
maybe
worked
a
little
bit.
He
submitted
a
pr
that
started
and
we
chatted
about
this
particular
topic.
I
I'd
have
to
go
back
and
look
at
the
history,
but
he
sort
of
made
some
improvements
there.
B
I
think
that
would
be
a
really
great
task
for
somebody
to
go
in
and
look
at
making
his
snapshots
snapshot,
testing
approach
that
also
outputs
example
directories.
So
people
can
go
and
reference
what
what
the
package
does
it'll
be
great.
There
was
another
thing
you
said,
and
I'm
trying
to
remember
what
it
was
examples.
B
B
B
No,
it
was
four
and
then
I
had
a
create
package,
but
I
think
it
was
like
a
I
just
did
it
as
a
placeholder
and
it
just
set
like
one
default
for
get
and
one
default
for
the
create
package.json,
and
then
I
had
a
final
top
layer
which
was
like
at
wesley
todd,
crate
package,
and
so
that
was
my
opinionated
layer,
so
I
put
in
there
I
said,
like
hey
by
default.
Npm
test
should
run,
I
think,
standard
and
mocha,
and
then
I
made
sure
that
it
all
by
default,
installed.
B
Standard
and
mocha
is
dev
depths.
You
know
I
had
like
those
kind
of
opinions
that
were
just
my
workflow
and
apparently
misspelling
of
the
ics
license.
You
know,
but
like
those
kind
of
things
where
those
were
like
opinions
that
I
wanted
to
add
on
top
of
the
underlying
right,
and
so
that
is
the
workflow
I
intended
folks
to
use
when
they
come
in
and
say:
hey,
I'm
create
react
app,
and
I
want
to
start
leveraging
the
create
package.
B
Tooling,
okay,
I'll
pull
it
in,
but
we
know
we
need
to
install
react.
We
need
to
install
like
all
of
these
scripts
like,
and
so
our
tooling
should
just
support
them.
Passing
that
to
us,
instead
of
them
having
to
like
re-implement
all
the
logic
that
that
it
creates
that
you
know
create
react-app
does
today,
you
know
that's
sort
of
the
end
goal
once
we
have
all
this
stuff
flushed
out
underneath
and
it's
pretty.
B
Yeah
yeah
and
that
and
and
that's
definitely
another
concern-
and
it's
one
that
I
tackled
quite
a
bit
in
the
great
package
jason
is
running
over
existing
projects.
I
think,
should
be
a
100
requirement
if
we
want
to
land
things
like
the
support
spec
into
this,
the
we
have
to
be
able
to
run
it
on
existing
projects
to
get
by
and
across
the
community,
in
a
good
user
experience
right.
B
B
B
D
I
should
do
a
little
homework
because
it
might
be
fun
or
I
have
a
little
time
next
month.
So
let
me
just
do
a
little
homework,
and
maybe
I
can
reach
out
more
directly
to
you
guys
in
the
slack.
B
A
C
B
Does
again,
this
is
I've
been
the
blocker
here,
so
I
pushed
a
bare
bones
version.
Let
me
go.
It's
yeah
create
it's.
It's
the
pkg
js
slash
create
package
is
the
create
package,
the
create
dash
package
in
pm
space
that
we
have
it's
the
it's
that
project,
I'm
pretty
sure
and
we
have
not
published
it
yet,
but
darcy
has
it.
So
if
we
need
to
publish
it,
he
can
add
people.
B
It
looks
like
the
name
in
the
package.
Jason
is
still
wrong,
there's
a
bunch
of
things
that
need
to
be
updated.
I
think
what
I
did
here
was
just
do
the
bare
minimum,
which
is,
I
remember,
I
said
I
wrote
a
proof
of
concept
that
pulled
in
package
jason
get
and
then
like
a
couple,
small
things,
that's
basically
what
I
pushed
here,
but
it
is
not
complete.
So,
like,
I
think,
the
the
steps
there,
the
next
steps
there
is
get
it
to
be
a
feature
complete.
B
Whatever
we
consider
feature
complete
and
then
publish,
I
think
there
are
some
requirements
for
that
package
that
will
actually
be
implemented
in
createpackage.json.
B
So
I
think
that
was
what
like
chris
hiller
had
been
working
on:
let's
see,
if
there's
any
open
pr's
from
anybody
else.
B
Oh
yeah
cool,
rawdion,
dependable,
well,
the
pandabot
yeah,
but
that
doesn't
count
yeah,
but
anyway,
I
think
there's
a
few
other
things
that
could
be
pushed
there's
just
a
lot
of
prs
here.
I.
A
B
Yeah,
that
would
be,
I
think,
the
great
status.
So
technically,
you
can
do
that
with
my
version
of
it
and
it
exercises
all
of
the
same
underlying
tools,
but
but
I
think
it
doesn't
have
the
same
opinions,
and
so
I
think
we
really
want
to
push
to
get
a
version
that
has
our
opinions.
A
A
B
A
I'm
just
saying
one
good
next
step
is
to
you
know
some
cleanup
cleanups
of
cleanup
validation,.
D
Sorry
wes:
what's
the
difference
between
create
and
create
package
json.
B
Yeah,
so
that's
the
layering,
so
let
me
I
should
have
maybe
just
shared
the.
If
you
look
in
the
cr
I'll
share
a
link
here.
B
My
my
issue-
titling
here
was
left
a
lot
to
be
desired,
but
this
issue
issue
number
seven
on
the
create,
shows
sort
of
how
I
thought
of
decomposing
this
stuff
and
it
sort
of
shows
the
package
names
right.
I
put
that
I
linked
to
that
by
the
way,
so
it
is
captured
in
the
minutes
that
specific
issue
all.
B
D
Unless
everybody
has
any
objections,
I'm
gonna
pin
issue
seven.
If
that's
okay,.
B
Change
the
name
to
make
it
sound
more
like
something
that
somebody
should
read
as
an
intro,
because
I
realize
I
named
it
just
like
I
was
thinking
about
how,
like
I
was
just
doing
like
a
design
exercise
of
decomposing,
and
so
I
titled
it
that
and
it
just
doesn't.
I
don't
think
it
draws.
People's
attention
is
like
this
is
the
design
spec.
A
D
And
yeah,
maybe
if
there's
a
few
moving
parts
that
need
to
get
to
that
kind
of
mvp
milestone,
maybe
we
could
chuck
them
into
a
top
level
project.
So
that
way
you
can
kind
of
sum
up
a
few
pieces
into
one.
B
A
D
A
The
next
thing
we
have
on
the
agenda's
suggested
list
of
modules
to
get
help
get
support
info
in
into
I,
don't
I
don't
think,
there's
any
update
that
I'm
aware
of
on
that
front,
so
we
can
probably
move
on
to
oh
and
you'd
mentioned.
There
was
something
else
you
want
to
talk
about
right.
B
Can
I
before
we
move
on,
I
I
just
realized.
I
had
one
last
detail
to
share.
That
was
actually
pretty
important
and
I
totally
missed
it,
but
I
was
going
through
it
just
to
make
sure
the
main
current
state
is
not
merged.
Yet,
so,
if
you
are
looking
at
createpackage.json
the
branch
you
actually
want
to
look
at,
I
think
it
yeah
is
1.x.
B
Maybe
we
just
need
to
merge
it,
but
anyway,
one.x
is
the
branch
there.
We
probably
also
need
to
switch
master
to
main
now
that
I'm
sorry
yeah
master
domain
now
that
I'm
looking
at
it
and
in
create
oh,
it
is
okay
and
create
we
are
up
to
date.
It's
just
that
in
create
package.json.
B
D
Oh
sorry,
the
okay
duck
was
on
my
desk
yeah,
just
real,
quick.
Well,
there
was
a
there's
more
of
an
open-ended
conversation.
We
could
have
I'll
just
throw
my
quick
question
and
I'll
hand
that
over
to
john
actually,
but
my
quick
question
I
can
hopefully
maybe
get
through
in
a
minute
or
so
then
we
can
close
out
on
what
john's
been
up
to.
D
I
was
doing
a
little
homework
on
just
a
side
project
of
mine,
just
trying
to
learn
a
bit
more
about
like
how
node
supports
like
export
maps
and
mains
and
all
that
stuff
was.
D
Or
can
I
just
literally
only
kind
of
say,
like
you
know,
I
guess
the
way
to
say
it
is
like
definitely
support
me
or
definitely
support
exports?
If
you
want
to
support
the
rest
and
be
you
know,
kind
of
supportive
of
those
packages
you
can,
but
it's
also
just
easy
to
say
the
spec
is
main
or
export.
So
I
wasn't
sure
if
anybody
had
any
experience
with
those
two
and
other
those
other
deals
that
have
popped
up
and
how
how
you
know
you
would
respect
or
honor
those
in
terms
of
prioritization
from
them.
C
B
I
mean
my
I
mean
my
take:
is
I'm
only
using
maine
right
now
so
and
that's
an
intentional
choice,
because
there's
just
too
many
foot
guns
with
the
rest
of
it?
So
you
know
that.
Take
that
I
I
have.
I
try
to
keep
things
very
simple
and
have
very
simple
use
cases
mostly
so,
but
that's
been
working
for
me,
does
npm
maintain
a
specific
spec
for
what
is
validpackage.json,
I
mean,
I
know
they
have
their
documentation,
but
do
we
know
if
there's
a
spec?
B
There
is
not
a
question
there
is
not
and
they
do
not
intend
to
because
they
don't
own
it.
There
is
no
single
owner.
It's
a
shared
document
across
the
ecosystem.
We've
had
a
bunch
of
discussions
about
this
way
back,
trying
to
remember
if
any
of
them
were
like
documented,
because
even
like
at
the
beginning
of
the
support
spec,
we
were
talking
about
well
where's,
the
home
for
that,
because
that's
a
package
jason
edition
right,
yeah.
B
D
Like
a
mango
deep,
it's
like
a
no
sql
just
you
can
put
whatever
you
want
in
it.
I
suppose
yeah.
I
think.
A
D
Well,
I
guess
it's
I
mean
well,
I
guess
that's
kind
of
where
my
understanding
is
trying
to
come
from.
It
sounds
like
at
the
beginning.
There
was
just
made
and
then,
when
esm
came
into
node.js,
that's
when
export
maps
were
added,
but
in
the
meantime
bundlers
and
all
these
kind
of
next
generation
code,
chomping
tools,
kind
of
it
seemed
like
came
up
with
their
own
solutions.
To
say
this
is
a
module
or
this
is
umd
or
this
is
something
like
these
effectively
hints
right.
D
D
But
I
guess,
as
far
as
node
is
concerned,
from
what
I
got
from
their
official
documentation
as
far
as
what's
canon
in
their
perspective,
it's
maine
for
cjs
and
exports
for
dsm,
or
I
suppose
you
could
put
esm
in
your
main.
But
I
think
the
idea
is
that
for
a
while,
packages
may
need
to
have
dual
module
support,
and
so
you
know
if
a
bundler
is
going
into
your
package.
Json
like
okay,
I
see
a
main
and
I
also
see
an
export.
D
I
should
use
the
export
first.
You
know
if
I'm
in,
like
a
you
know,
if
someone
set,
you
know
es
2020
to
true
in
my
typescript
config
or
something
like
that.
You
know
so
I
was
just
making
sure
I
was
you
know,
because
if
you
go
splunk,
I'm
sure
anybody
who's
gone
splunking
and
packaged
jsons.
D
You
do
see,
as
you
guys
said,
a
lot
of
stuff
in
there
and
I
was
just
kind
of
trying
to
figure
out,
what's
actually
canon
or
spec
and
what's
kind
of
just
been
the
community,
as
you
say,
trying
to
work
together
to
you
know,
fill
in
the
gaps
when
there
wasn't
a
spec
so
anyway
I'll
you
know
I'll,
keep
it
alive.
Maybe
I'll
ping,
jordan
on
slack
yeah.
B
D
Okay,
yeah,
I
mean
I
could
just
be
bad
at
reading
the
node.js
stuff,
so
but
it's
yeah
anyway,
yeah
just
kind
of
throw
it
out
there
to
see
what
everybody
else
has
how
they've
interpreted
or
what
they've
done.
So
my
perspective,
it
sounds
like
export
first
main
and
then
whatever
else
like
or
export
any
of
the
other
things
and
then
fall
back
to
me,
because
I'm
trying
to
do
a
esm
first
tool.
D
So
it's
like,
if
I
can't
find
the
others,
then
I'll,
find
your
maid
and
I'll
run
that
through
some
sort
of
cjs
to
esn
parks
or
something-
and
you
know
sure,
you'll
get
an
extra
100k
in
your
bundle,
but
at
least
you'll
be
able
to
use
anything
from
npm
kind
of
like
the
sky
pack
thingy
or
whatever
all
right,
cool
thanks.
That
was
my
question,
like
my
other
topic,
was
from
the
issue
was
the
same
as
john
so
I'll.
Let
him
go.
B
Cool
yeah,
you
guys,
might
have
noticed
I
before
the
meeting
I
just
started
going
through
issues
just
to
look
at
you
know
I
was
just
triaging
a
little
bit.
Basically
there's
nothing
particularly
actionable
right
now,
but
I
want
one.
I
created
a
new
label
which
I
just
figured
hey.
I've
got
the
permissions
I'll.
Do
it
just
want
to
make
sure
that
was
cool?
I
created
a
stale
quest,
stale
quest,
stale
question
mark
label.
I
don't
like
stale,
I
don't
like
my
justification.
B
B
You
know
stale
label
on
them
so
that
people
in
the
group
can
go
through
and
read
them
at
some
point
and
say
you
know
I
basically
I
don't
have
the
context
to
just
say:
no,
we
can
close
this
so
basically,
next
meeting
or
before
next
meeting
I'll
make
another
comment
to
be
like
hey,
you
know,
requests
like
hey
people
go.
Please
look
at
these
issues
and,
just
you
know
close
anything
you
want
to
close
or
link
anything
to
any
new
conversations
going
on
and
stuff.
There
is
a
link
to
that
stale
label.
B
In
my
comment,
if
you
want
to
see
it,
I
closed
like
maybe
four
or
five
issues
which
there's
a
link
to
show
you
those
issues
that
I
closed.
If
you
want
to
just
check
my
work,
you
know,
but
it
it
there's
some
issues
that
I
would
love
to
for
the
group
to
go
over.
B
Maybe
we
can
talk
about
at
another
meeting
and
specifically
one
thing
that
I
found
was:
there
was
a
tool,
an
idea
for
a
tool
which
I
just
changed,
the
title
of,
because
the
original
issue
didn't
matter
anymore
and
was
all
talk
about
the
tool
it's
number
214,
but
basically
it
would
be
to
look
at
use.
B
Githubs
like
used
by
to
see
what
are
the
most
popular
by
stars,
consumers
of
a
dependency,
so
that
maintainers
could
basically
look
at
like
who's
the
most
popular
user
of
my
stuff,
which
they
probably
already
know,
but
mateo
said
it
would
be
a
great
tool,
and
I
figure
that
I
think
the
api
it
depends
on
might
be
more
stable
now
in
github.
So
just
something
to
look
at,
but
there's
some
really
cool,
interesting
stuff,
hidden
away
in
the
repo
and
as
long
as
you
guys
are
okay
with
it.
B
That's
what
I
wanted
to
ask:
are
you
guys?
Okay,
are
you
gonna
be
opposed
to
me,
adding
this
stale
label
to
some
of
them?
It
specifically
means
hey.
I
would
like
more
eyes
on
this,
and
maybe
we
close
it
or
maybe
we
bring
this
conversation
forward
again.
So
the
idea
is
that
the
label
should
be
temporary.
B
I
don't
like
scaling
stuff
and
ideally
we
can
take
it
off
or
I
can
eventually
delete
the
label,
but
we
only
have
like
60-something
issues,
which
isn't
very
many,
but
we
only
have
like
maybe
20-25
active
issues,
so
I
would
like
to
try
to
reduce
it
just
because
you
know
there's
a
lot
going
on
in
this
group.
So
I
would
like
to
reduce
our
issue
count
if
possible.
A
One
thing
we
did
that
semi-related
in
the
node
api
team
is
we
turned
on
the
stale
bot,
which
will
automatically
mark
things
stale
after
a
certain
amount
of
time.
But
then,
when
things
get
marked
stale,
we
have
an
issue
which
we
go
through
each
time
we
get
together
and
if
you
see
something,
that's
been
marked
stale
that
you
think
wait
a
sec
that
shouldn't
really
just
get
stale
and
be
closed.
A
We
add
it
to
that
and
then
that's
the
list
of
things
and
it's
very
similar
to
what
you're
describing
we
go
through
that
to
say,
okay,
this
is
this
has
been
out
there
a
long
time
we
haven't
done
anything.
We
should
really
give
it
some
more
attention,
so
I
just
want
to
mention
that
is
like
that's
actually
turned
out
to
be
quite
useful.
A
You
know
two
things,
one,
the
stale
bot
kind
of
is
like
a
no
judgment.
This
has
just
been
around
a
long
time
and
that,
coupled
with
the
like,
like
you
said,
you
don't
want
things
to
go
stale
that
shouldn't
die
some
things
it's
just
like
nobody's
interested
anymore
and
they
can
just
go.
But
if
is
you
know,
on
the
other
hand,
it
it
reminds
us
to
look
at
things
and
say
well,
no,
this
should
we
should
discuss
this
right.
B
What
group
did
you
say
that
you're
doing
that?
It's.
B
A
Well,
yeah,
actually,
so
the
actual
issue
itself
is
in
no
abi
stable
node.
Here,
let
me
find
it
for
you:
okay,
perfect,
because
that's
great
yeah,
it's
just
because
yeah
it's
that
kind
of.
So
here's
the
here's,
the
issue
now
you
know
the
idea
of
the
label
may
be
just
as
good.
You
know
is
another
just
as
good
a
way
to
do
it
right
like
but
having
something
like.
A
Maybe
it's
just
an
issue
that
has
a
link
to
the
a
query
with
that
label,
and
you
know
if
then,
if
it's,
if
you
have
an
issue
and
you
tag
it
for
the
agenda,
then
it
will
show
up
on
the
agenda
and
we'll
remember
to
do
it,
but
and
then
separately.
We
could
think
about
whether,
like
the
stale,
bot
or
something
is
something
we
want
to
automatically
have
looking
at
things
that
that
get
old.
D
D
That
john
brought
up
was
that
there's
also
a
lot
of
some
really
thorough
conversations
and
some
of
those
issues
that
stale
or
not,
I
think,
could
also
maybe
benefit
like
grab
a
paragraph
or
a
couple
sentences
and
throw
it
on
the
read
me
in
the
section
and
put
it
its
own
some
potential
for,
like,
I
guess,
just
extraction
as
as
well
as
opposed
to
like
hey,
you
opened
a
bug
and
we
asked
for
a
repro
and
then
you
ghosted
on
us.
D
You
know,
I
think
it's
more
like
you
know,
either
continue
the
conversation
or
close
this,
but
someone
needs
to
like
extra
it's
not
just
close
or
not
right.
It's
continue
or
close
with
extraction,
or
you
know
some
sort
of
you
know
at
least
some
of
those
looked
like
there
was
good
info
in
them
and
then
just
real
quick,
the
top
that
tool
you
referenced.
I
feel
like
that
might
be
a
really
great
companion
to
whippy.
You
know
how
do
you
know
who
you're
gonna
break
without
you
know?
D
C
D
Want
to
be
part
of
my
libby
program,
you
know
I
ran
this
tool
and
you
seem
like
a
good
candidate
based
on
these
multiple
factors,
so
it
could
be
interesting.
B
B
A
B
B
Cool
that
that
covers
that
for
me,
basically,
I
just
I'm
gonna,
probably
keep
doing
it
by
hand
just
while
I
have
time
but
ideally
I'll,
think
more
about
having
a
stale
bot.
Do
it
because
that's
the
whole
point
is,
I
just
want
the
group
to
be
able
to
look
at
these
things
and
be
like.
Oh
did
we
ever
do
this?
B
Do
we
still
want
to
do
this
and
it
sounds
pretty
easy
to
like,
basically
have
an
issue
where
if
we
have
a
light
agenda,
we
can
just
like
let's
go
through
this
list
and
talk
about
them.
That
sounds
great
to
me
or.
D
A
D
A
The
stale
bot
that
somebody
said
hey,
let's
put
them
here
because
then
that's
like
you
know,
one
of
the
team
members
has
looked
at.
It
decided
this.
This
is
interesting
enough
that
we
should
keep
looking
at
it
right
and
it
and
if
the
things
just,
if
nobody
actually
does
puts
it
on
the
list,
then
having
it
be
closed
by
the
bot
like,
I
think
it
gets
a
warning.
You
know
it
first
says:
hey,
this
is
stale,
hasn't
been
done
and
then,
like
30
days
later,
it
actually
closes
it.