►
From YouTube: Think BIG 10-9-19
Description
In which we talk about improving the package registry UI and UX
A
A
The
goal
now
for
moving
forward
is
to
start
to
talk
about
and
introduce
new
ideas
that
aren't
necessarily
come
from
those
epics
and
for
today,
actually
Nick
not
to
put
you
on
the
spot
light,
but
you
sent
over
a
document
that
had
a
bunch
of
ideas
for
how
to
improve
the
packet
registry
and
even
open
some
issues.
So
I
thought
we
could
just
use
that
main
document
that
you
opened
as
a
launching
point
to
maybe
brainstorm
some
new
ideas,
but
Ian
I
think
you
had
a
couple
of
things
on
the
agenda.
B
A
B
Thing
was
that
this
meeting
actually
got
quite
a
bit
of
traction
and
attention.
Quite
a
few
people
reached
out
about
the
survey
data
I
presented
last
week.
A
lot
of
people
I
wasn't
expecting
asked
to
get
access
to
the
the
agenda
and
the
docs,
so
I
just
wanted
to
share
that
I
think
it's
kind
of
exciting
that
we're
doing
something
that
other
people
are
interested
in.
B
So
that's
just
one
note
and
the
other
one
is
I
for
12.54
a
part
of
the
creative
process.
I
would
like
to
try
an
asynchronous
brainstorm.
This
is
a
one-hour
session
that
used
to
be
a
workshop
that
I
would
run
before
I
would
start
a
big
design
sprint
or
a
big
design
effort
kind
of
getting
everyone's
ideas
together.
I
want
to
do
this
in
an
asynchronous
fashion
to
do
it
the
gitlab
way,
which
I
think
Dan's
gonna
be
very
happy
about.
So
this
is
a
kind
of
a
trial
run.
B
It's
designing
the
metadata
and
that's
not
a
very
exciting
UI
challenge.
So
the
focus
is
really
I'd
like
to
see
what
it's
like
for
us
as
a
team
to
do
this
asynchronous
workshop
and
see
how
we
can
brainstorm
together
and
kind
of
foster
that
creativity,
we
have
a
huge
group
of
our
users
are
also
on
our
team.
So
it
seems
kind
of
silly
not
to
take
advantage
of
that
kind
of
setup.
So
I
added
an
issue.
I'm
gonna
flesh
out
the
details,
but
I
just
kind
of
wanted
to
see.
C
I
think
this
is
a
really
good
idea
in
thanks
for
adding
that
issue.
Could
you
could
you
make
sure
you
add
that
to
the
package
team
sync
meeting
as
well,
just
to
remind
people
to
be
thinking
about
it,
I
want
to
make
sure
that
we're
all
sort
of
keeping
it
in
mind,
but
I
think
it's
a
great
idea.
Thank
you
for
putting
that
together.
You.
A
D
Katie
from
say,
as
of
last
week,
we
had
a
bit
of
a
discussion
about
some
ideas
of
what
we
thought
the
PAX
registry
could
go
in,
and
we
came
to
agreement
that
we
just
create
issues
for
these
and
use
this
as
a
starting
point
to
discuss
ideas.
So
that's
what
I
did
so
I
had
a
few
ideas
and
I
created
some
issues
for
them.
So
that's
what
these
issues
are
essentially
so
they're
now
out
there
so
they're
free
for
anyone
to
take
and
do
what
they
live
and
what
they
want
with
them.
D
You
know
I'm
not
like
possessive
over
these
ideas
or
anything.
So
if
you've
got
better
ideas
or
once
you
use
them
for
inspiration
or
how
many
comments
and
just
leave
them
on
the
issues
actually
fun
the
first
one,
then
was
the
idea
that
I
think
I
vocalized
in
the
last
meeting,
which
is
basically
like
I.
Have
this
idea
that
we
could
streamline
project
creation
from
the
packages
page
itself,
so
in
my
head,
I
feel
that
packages
are
quite
detached
from
anything
else.
Don't
get
that
they're,
just
it's
like
a
dumping
grounds
like
an
ftp
place.
D
You
just
put
some
files
on
a
server
somewhere
and
that's
it
and
they
don't
really
have
any
connection
anywhere
else
to
get
loud
at
this
moment
in
time,
or
at
least
not
without
like
extreme
effort
like
by
default
they're
just
on
their
own
kind
of
thing
and
live
in
a
project
join
a
group
whatever
it
may
be
so
yeah.
My
thought
process
was
is
that
it
would
be
great
if
all
of
these
packages
started
as
projects
on
get.
D
That
would
allow
like
way,
tighter
integration
between
a
package
and
a
pod
magic
package
and
a
project,
and
when
we're
looking
at
in
survey
data
there's
a
lot
of
data
in
there.
That
is
actually
project
type
data,
but
you
still
or
that
users
want
to
see
at
the
package
level.
So
right
now
we
can't
supply
any
of
that
data
to
these
users,
because
there's
just
no
link
there
between
a
package
and
a
project.
So
the
idea,
then,
is
to
encourage
users
to
carry
packages
via
gitlab
itself.
D
So
by
clicking
this
new
package
button
in
the
UI
that
existed
in
the
UI
that'll,
take
you
down
a
pathway
to
create
a
project
which
would
use
one
of
the
other
ideas
that
we've
got
floating
around,
which
is
the
templates.
So
it
would
create
a
project
of
perhaps
an
NPM
package,
but
that
NPM
package
would
be
seeded
with
the
template
files
for
it
to
work
inside
either
your
project
or
group.
So
it'd
have
the
NPM.
Rc
file
have
a
preferred
out
package
JSON
file.
All
of
that
kind
of
stuff
could
be
done
as
just
like.
D
D
So
you
in
the
NPM
package,
maybe
package
of
chronium
package,
and
then
that
would
take
you
to
the
git
lab
new
project
screen
which
would
be
modified
because
you're
now
creating
a
project
for
a
package
and
that'll
be
modified
in
the
sense
that
it
might
be
prefilled
based
on
what
package
earth.
So
what
project
or
group
you
came
from
exactly
exactly
whether
we
can
do
there
to
sort
of
make
the
journey
smoothly
user.
The
button
as
well
would
also
have.
It
could
be
one
of
our
dual
buttons
where
we've
got
so.
D
You've
got
a
main
action
and
then
you've
got
a
sub
action
and
a
sub
action
could
just
be
to
download
the
package
templates
that
we
want
to
build
and
offer
to
our
users
so
that,
instead
of
like
creating
a
project
that
would
basically
just
allow
the
user
to
download
the
zip
file,
and
that
would
include
all
the
files
that
the
project
would,
but
it
sort
of
you
download
it
to
disk
and
then
you'd
use.
Whatever
repository
you
wanted
for
hosting
that
package.
D
So
yeah.
That
was
basically
my
full
price
and
I'm
thinking
that,
if
we
can
offer
this
to
use
this,
and
that
gives
them
a
like,
it
encourages
them
to
host
their
package
on
git
lab
itself
and
to
host
the
project
on
get
lab.
And
once
we've
got
this
connection
between
the
two,
we
could
then
offer
the
additional
things
like
issues
inside
package
pages
or
mr.
How
many
am
I
open?
Emma's
arrived
like
build
status
and
all
these
other
piece
of
meth
data
that
our
users
are
actually
interested
in.
Seeing
and.
A
D
Yeah
I,
don't
see
why
not
we
could.
We
could
do
all
kinds
of
things
with
this
like
we
could
highlight
identity
even
in
the
UI,
the
package
lists
page,
for
example,
we
could
highlight
packages
that
are
projects
inside
inside
gitlab
itself
versus
packages
that
just
just
packages
on
their
own
and
perhaps
hosted
elsewhere.
So
yet
there's
a
lot
of
things
that
we
could.
We
could
do
here,
I
think
one.
B
B
While
his
team
may
only
make
a
new
package
once
every
few
months,
his
company
is
generating
new
packages
once
a
week
and
they're
being
created
so
I
think
there's
definitely
a
use
case
for
our
big
clients
that
want
to
be
able
to
jump
in
and
create
a
new
package
and
have
it
just
set
up
to
work
automatically.
So
I
I've
heard
that
this
could
be.
You
know
really
useful
for
our
users.
A
D
No,
no
I
I
mean
like
pretty
much
every
package
is
gonna,
have
a
repository
somewhere
like
a
normal,
get
repository
somewhere
in
the
case
of
NPM
they're.
All
the
packages
are
pretty
much
hosted
on
github
in
terms
of
that,
the
actual
project
itself
is
hosted
on
github
and
then
they
just
produce
the
bills
which
goes
to
NPM,
but
you'll
notice.
Some
things
that
NPM
that
they
will
have
like
number
of
issues
and
then
direct
links
to
the
repository
and
all
of
that
kind
of
stuff,
which
is
obviously
something
that
we're
missing.
D
A
D
I,
don't
think
so.
I
think
the
thing
that
you'd
have
to
establish
is
the
link
between
a
package
and
a
repository
or
a
link
between
a
package
in
the
project,
so
that
would
have
to
exist
somewhere
in
the
case
of
I.
Think
in
the
case
of
NPM
relating
package
Jason,
you
can
actually
put
your
project
euro
in
there.
So
I
don't
know
about
the
other
package
registries,
but
that
would
be
presumably
like.
D
If
you've
got
a
link
between
the
two,
then
it's
it's
relatively
easy
to
grab
the
data
from
from
one
and
display
on
the
other.
So
it's
just
having
that
link
essentially
and
then
all
the
options
around
it
like.
Perhaps
if
a
user
doesn't
want
to
have
their
package
linked
to
a
project
like
being
able
to
destroy
that
link
or
change
it
or
whatever.
B
Do
you
think
that
there
is
a
big
difference
in
kind
of
setting
up
these
templates
with
the
different
package
managers
or
from
kind
of
that
UI
wizard
experience
to
all
the
package
managers
kind
of
follow
a
similar
flow
I'm
only
really
familiar
with
NPM,
so
I'm,
not
sure.
If
there's
like
a
huge
Delta
when
you
move
over
to
Nathan
or
Conan.
D
D
I
think
what
our
templates
are
looking
to
solve
is
not
necessarily
for
a
package
itself,
but
for
a
package
to
work
on
get
lab,
so
it
include
all
the
additional
or
any
additional
files
or
settings
that
might
need
to
be
applied
to
a
package
for
it
to
work
on
get
lab
out
of
the
box
at
least
that's.
Why
I
think
the
templates
are
trying
to
solve.
A
One
of
the
things
that
Sid
has
been
pushing
me
on
is
to
to
enable
inner
sourcing
for
companies.
So,
like
I,
the
example
that
Ian
gave
were
a
large
enterprise
company.
They
are
creating
hundreds
of
packages
a
year,
but
they
you
know
they
don't
want
to
open-source
those,
but
they
do
want
to
host
them.
So
this
it
feels
like
this
would
be
the
best
way
to
to
do
that,
especially
if
we
can
figure
out
how
to
maintain
those
links
and
make
it.
A
D
D
D
Yes,
so
this
one's
another
one
that
we've
I've
definitely
brought
up
in
the
past,
perhaps
not
spoken
about.
So
this
is
something
that
lab
itself
suffers
from,
at
least
on
the
front
end.
So
I
noticed
that
one
of
our
main
tenets
was
talking
about
how
they
have
to
manually
manage
dependencies.
So
when,
when
a
dependency
version
changes,
they
have
to
manually
create
a
mr4
that
change
the
update.
D
The
dependency
version
run
all
the
tests
against
it,
except
to
accession
and
validate
that
this
actually
like
this,
we
can
upgrade
without
like
breaking
stuff,
which
is
obviously
quite
a
lot
of
work,
especially
like
a
Jurassic
world
would
depend
he's
changing
quite
often
and
I
miss
you,
and
this
is
just
a
problem
in
general
like
they,
where
I
used
to
work.
We
had
this
pump
all
the
time
where
dependencies
would
change,
and
it
would
it
would
take
weeks.
D
Sometimes
if
there
was
a
big
update
for
us
to
move
across
versions
and
stuff
like
that,
so
I
think
in
like
continuous
integration
world,
like
one
of
these
things
that
I
certainly
remember
being
told
about
my
I,
don't
go
very
senior
practice.
Is
that
actually
it's
Bennet
or
it
can
be
better
to
just
update
and
and
if
you're
always
updating
as
soon
as
the
version
is
released,
enough
sort
of
forces
you
to
fix
any
problems,
but
the
the
the
plus
side
to
that
is.
D
Is
that
you're
always
going
to
be
running
the
latest
versions
you're
always
going
to
have
to
lay
security
updates?
Accessories
such
as
so
so?
There
are
pluses
to
that
approach,
and
it
occurred
to
me
that
this
is
something
that
could
automatically
happen
inside
get
allow
itself,
especially
if
you're,
using
the
internal
like
our
package
registry.
D
So
if
you've
got
a
project,
that's
using
the
package
from
get
labs
package
registry,
then
we're
gonna
know
when
that
package
version
updates
and
I
was
thinking
that
we
could
build
processes
off
of
that
that
the
user
could
opt
into
to
help
them
manage
their
dependencies.
So
if
you
imagine
that
you
update
a
new
version
of
a
package,
you
upload
a
new
version
package
and
then
all
the
projects
in
that
package
depends
on
gets
an
mr
that
updates
their
package.
D
Json
file
to
the
new
version
it
kicks
up
a
pipeline
does
a
build,
runs
all
the
tests
and
if
all
of
that
is
green,
it
just
automatically
merged
that
new
version
of
the
package
in
that
that
lifts
a
huge
weight
off
of
the
developers
backs.
You
know,
and
all
they
have
to
do
then,
is
just
verify
that
everything's,
okay
and
now
I'm
not
going
to
say
that
every
single
project
is
gonna
want
to
work
like
that.
D
It's
like
a
point
of
responsibility
and
then
all
they
have
to
do
is
even
press.
Yes
or
no,
so
the
idea
behind
this
is
to
reduce
the
amount
of
friction
that
these
developers
are
gonna
feel
for
this
particular
scenario,
and
they
say
this
is
upon
that.
Gitlab
has
itself
on
the
front
end
and
there
are
people
that
sit
and
do
this
manually,
and
so,
if,
if
there's
anything
that
we
can
do
to
help,
this
I
think
this
is.
This
is
an
area
that
we
could
look
into
and
like
doing
will
benefit
users.
E
From
my
past
experience,
this
is
extremely
true.
Every
time
there
is
an
update.
There
is
friction
that
is
not
just
for
the
developers
team,
but
sometimes
you
need
to
set
in
a
time
to
do
that,
update
because
you
really
need
it
because
a
security,
it's
difficult
to
explain
to
your
manager
why
you
are
setting
away
a
week
for
producing
nothing.
So
if
we
can
smooth
this
out
as
much
as
possible,
it
would
be
great.
Maybe
we
could
do.
E
We
could
go
even
as
far
as
actually
spinning
as
an
instance
of
their
product
with
the
updated
packaging
like
to
be
testable
the
pipeline,
our
similarity
so
that
they
can
actually
check
in
it.
Everything
is
alright
and
be
more
confident,
even
probably,
for
majors
and
for
security
related
stuff.
There
is
a
tool
that
me
we
made
look
is
called
dependable
and
it's
about
that
growls
your
packages
and
generates
PR,
because
this
is
on
github
with
updates
and
also
keep
keep
them
in
sync.
D
Think
that
particular
part
is
being
floated
about
as
an
idea
to
solve
it
in
Gila
for
the
30-lap
codebase
I,
don't
know
if
it's
that
exact,
what
those
but
there's-
and
there
is
a
bot
that
is
being
floated
as
a
way
to
solve
this.
So
yeah
like
if
that
seems
like
a
suitable
solution
and
maybe
that,
like
MVP
style
approach
that
we
could
take,
that.
A
That's
awesome
and
do
we
know
when,
like
I,
haven't
seen
when
I
update
a
package
anything
show
up
in
the
Activity
Feed
I
was
debating
opening
an
issue
for
that
and
in
twelve
five
do
we
know
like
when
we
bump
a
version
or
create
a
new
version
of
an
NPM
package.
Do
do
we
know
when
that
happens,
would
do
we
have
or
do
we
have
to
add
some
triggers
or
web
hooks
or
something.
D
D
Now
I
don't
feel
I
personally
feel
it's
like
impossible.
I
think
there's
some
considerations
to
it,
though,
like
for
example,
scanning
every
dependency
for
every
project,
I'll
get
out
is
going
to
be
quite
the
undertaking.
You
know
like
scalability,
that's
that's
kind
of
a
problem,
but
you
could.
You
could
like
an
MVP
could
just
work
on
the
packages
inside
the
gitlab
package
registry
and
then
we
don't
check
packages
that
are
out
sourced
or
also
stored
from
other
package,
so
we
will
be
calling
MPM
checking
for
updates.
A
C
F
A
Think
we
haven't
decided
that
yet
right
now
we're
just
the
idea
of
saying
like
the
problem
is
for
developers
is
that
they
have.
This
need
to
update
the
dependencies
when
they
come
in
and
we'd
like
to
do
that.
But
we
haven't
come
up
with
a
solution
yet
I
made
I
am
talking
to
Nicole
on
the
security
met
this
morning.
I
could
find
out
a
little
bit
more
about
what
they're
working
on
and
see
if
we
could
tie
into
that
at
all.
C
We
and
I
think
we've
sort
of
idea
or
cooking
in
with
what
secure
is
doing,
has
already
kind
of
come
up
with
regard
to
this,
the
dependency
firewall
category
that
we've
been
considering
so
I
think
this
is
a
good
question
to
be
asking
right
now
and
as
Tim
mentioned,
these
are
chatting
with
Nicole
about
it.
So
yeah
might
be
an
opportunity
to
answer.
Some
of
these
questions
is
with
for
people's
experience,
they've
already
implemented.
So
good
idea,
thanks
for
you.
A
D
D
So
yeah
help
users
identify
the
correct
version
of
the
package
to
use.
So
this
was
just
I.
Don't
really
have
any
solid
ideas
here.
This
was
just
just
a
few
points,
and
but
I
noticed
that
in
the
survey
like
one
of
the
reasons
why
they
use
the
UI
is
to
see
which
version
of
the
package
they
should
be
using
in
their
local
environment.
So
I
figure,
that's
probably
quite
common
scenario
and
there's
probably
a
bunch
of
things
that
we
could
do
to
to
facilitate
that
and
help
make
that
a
bit
easier.
D
So
one
of
those
is
so
on
project
creation.
We
could
check
if
the
user
created
a
project
or
the
group
that
the
project
is
we
create
within,
is
hosting
any
packages,
and
then
we
could
like
prompt,
have
some
kind
of
prompt
to
the
user
to
say
you
want
to
include
any
of
these
packages
as
part
of
your
project
setup
so
yeah.
We
know
there
are
some
considerations
with
that.
This
is
a
bit
of
a
pie
in
the
sky
kind
of
idea,
but
yeah
like
we
could
say,
look
do
you
want
it.
D
We
could
add
a
button
inside
somewhere
inside
the
projects
pages
itself.
So
basically
the
reverse,
where
you
could
add
a
pack
into
your.
So
let's
say
you
wanted
to
add
a
patch
package
to
this
project
and
then
you
could
browse
and
navigate
to
a
package
to
add
so,
basically,
just
some
UI
elements
on
both
sides
of
the
equation
to
be
able
to
add
easily
add
packages
to
a
project,
and
we
could
have
something
like
use
latest
version
or
something
like
that
as
the
button.
D
So
if
you
imagine
these
are
dialogues
and
you
could
select
which
version
of
the
package
or
project
you
want
to
add,
you
can
basically
just
select
latest
versions,
so
they
user
doesn't
have
to
worry
about.
Look
it
up
a
particular
version,
yeah
and
then
the
final
idea,
which
is
again
like
on
the
packages
list
page
highlight
new
releases
in
some
manner,
say,
for
example,
right
now
we
do
list
out
all
the
releases
for
a
package
as
a
single
sort
of
row
in
the
table
which
could
get
lost
and
yeah.
D
If
that
table
goes
large,
like
you
might
not
know
which
one
is
the
latest
one,
for
example,
you're
trusting,
you
might
be
just
looking
at
the
created
date
and
if
the
latest
version
was
two
weeks
ago,
then
you
don't
really
know.
If
that's
the
latest
version
or
not,
and
now
we
are
adding
sort
to
that
page,
but
we
could
have
like
another
feed
or
something
at
the
top
outside
of
the
table.
A
D
Yeah
I
think
that
could
be
useful.
I
think
it
raises
some
additional
features.
So
if
you
just
enabled
labels,
for
example
and
say
you
are
using
labels
to
denote-
which
one
is
the
latest
version,
which
is
something
that
the
NPM
tags
do
then
yeah
we
was
like,
for
example,
if
the
user
then
update
a
package,
it
would
rely
on
the
user
to
then
go
and
move
the
latest
label
around
or
potentially
would
depend
on
how
it
was
implemented.
D
So
I
think
we'd
have
to
be
like
quite
strict
on
the
definition
of
what
a
label
is
and
how
it
potentially
differs
from
a
tag
attentively.
But
in
theory,
I
do
like
the
idea.
Cuz
I
do
like
the
idea
of
being
able
to
keep
groups
and
things
like
that
out
of
labels.
So
if
you
imagine,
you
had
a
suite
of
packages
and
all
of
and
some
of
these
packages
apply
to
I,
don't
know
a
chat
application,
so
you
labeled
all
of
those
packages
as
chat.
D
E
C
C
Maybe
a
work
for
here
that
would
be
useful
to
describe
what
I'm
thinking
here
is,
as
a
user
I
would
come
to
get
web
say
I'm
on
my
phone
and
then
I
actually
went
to
get
lab
and
looked
at
some
of
my
packaged
mother's
to
packages
and
I,
see,
there's
a
let's
just
say
a
tag
right
now.
How
do
I
interact
with
that
tag?
C
How
do
I
actually
do
anything
right
right
now
with
it
if
we
actually
surface,
and
obviously
this
a
bunch
of
like
technically,
should
considerations
here
if
we
actually
surface
those
tags
as
labels
anyway,
it
means
that
the
user
could
actually,
for
example,
make
it
work
flow,
would
be
the
the
latest
label
is
applied
and
I
think
that
one
should
be
applied
automatically,
but
just
for
argument's
sake.
Let's
say
it
ism
that
if
the
tag
is
lightest
because
that's
actually
a
tag,
maybe
you
could
do
tag
:,
lightest
or
something
like
that.
C
That
would
be
a
concept
that
would
apply
across
most
of
the
package
managers
and
if
a
used
I
could
see
a
cool
scenario
in
the
future
where
the
user
goes
and
removes
that
label
from
a
package
and
then
then,
that
sort
of
triggers
a
rebuild,
maybe
well
something
like
that.
I'm
not
saying
that
is
a
workflow
that
users
might
want
to
use.
But
it's
that
idea
of
like
hey.
Why
don't
we
surface?
This
has
gitlab
native
concepts
rather
than
adding
a
whole
separate
thing.
That's
going
to
be
managed
only
from
the
command
line.
D
Can
see
that
no
I'm
figure
that
and
yet
tags
and
labels,
essentially
the
same
thing
they're
just
a
way
of
applying
some
kind
of
hawk
tiger
label
to
a
piece
of
data,
so
yeah
I
kind
of
agree
with
that
that
we
could
just
they
could
all
just
be
bundled
together
as
one
particular
thing,
and
then
the
command
line
is
just
a
way
of
applying
those
as
well
I.
Don't
see
why
not
yeah.
C
I
think
I
think
that
would
be
trying
to
regularly
call
out
that
we're
trying
to
make
we're
trying
to
integrate
what
we're
doing
and
Ian
not
to
you
know,
step
ahead
of
any
of
your
research,
I
think,
which
is
a
really
important
point
here,
but
I
think
that
concept
is
like
a.
We
have
these
labels
we
have
latest.
We
have
versions
that
are
actually
associated
so
shouldn't
those
things
be
surfaced
into
our
gear
lab
labels,
if
possible.
C
No,
that
would
make
it
sort
of
a
first
party
experience
and
means
I've
been
looking
to
get
laughs
on
my
phone
and
look
at
a
package
repo,
because
that's
the
other
concepts
we
have
here
right
of
linking
the
two,
not
necessarily,
but
it
could
and
then
just
as
I'm,
actually
doing
a
build
here,
pushes
it
off
and
we
can
run
a
process
that
actually
says.
Okay.
This
is
version
two
point
three
point:
one
I'm
gonna
label
it
with
that.
So
it's
actually
first
party
and
then
further
integration
would
be.
C
A
On
sorry,
I'm
any
anything
else
on
that
Dan
sorry
I
was
gonna.
Ask
about
the
adding
oops.
What
is
it
so
I
lost
it
just
now,
I
don't
know
but
adding
like
having
a
button
where
you
could
add
a
packaged,
adding
a
button
to
the
group
package
view
since
they
add
it
to
my
project
or
vice
versa.
Having
a
button
in
the
package
can
we
can
we
actually
do
that?
Are
there
like
for
maven
some
files
live
on
my
local
machine
and
is
that
this
is
like
my
NPM
RC
file
lives
on
my
local
machine.
A
E
Well,
they
need
to
leave
on
your
local
machine
where
they
actually
need
to
live
in
the
repository
that
is
consuming
the
package,
so
we
can
probably
make
that
happen
in
a
semi
automatic
way
or
automatic
way,
or
certainly
on
project
creation.
If
you
say
this
project
depends
on
this
project
and
this
project
I
generate
this
package
shown
on
this
package.
We
can
actually
add,
for
example,
the
NPM
RC
or
canonical
txt
I
thought.
E
A
E
D
So
in
my
head,
those
two
parts
to
this
particular
feature-
the
first
part
would
be
so
if
you're
clicking
the
the
button
in
the
UI
to
sort
of
say,
add
this
package
to
my
project.
Really
all
that
would
do
is
that
would
create
an
M
R
for
that
project
which
would
modify
the
package.json
file
or
whatever
file,
to
include
that
package
and
that
version
yeah.
D
So
that's
all
that
the
UI
would
do,
but
it
would
rely
on
whoever
is
building
that
Packer
so
that
project
to
have
the
appropriate
files
in
place
to
be
able
to
pull
from
the
get
lab
package
registry.
So
if
that's
a
local
user,
then
they
might
need
I,
don't
know
in
the
case
of
NPM
the
NPM
RC
file
on
their
system
to
be
able
to
pull
from
Gil
a
package
and
if
they
haven't
set
that
up
previously
say
this
is
the
first
package
from
within
get
that
that
they
want
to
add
to
their
project.
D
Then,
yes,
they're
gonna
have
to
go
through
some
kind
of
setup
process
to
be
able
to
set
that
file,
set
their
tokens,
etc,
etc.
To
be
able
to
pull
that.
So
as
part
of
this
UI,
we
could
have
like
links
to
the
documentation,
or
even
let's
say,
to
those
template
files
that
we
can
come
back
to
where
you
could
just
download
a
copy
of
the
NPM
RC
to
put
into
your
project,
and
then
that
would
give
them
that
the
the
start
basically
would
guide
them
along
their
journey
to
be
able
to
make
that
case.
D
C
Sorry
my
way
to
think
about
that,
as
well
as
like,
ideally
in
my
head
again,
I
have
my
own
little
like
planet
I'm
living
on
so
I
come
out
saying
this
is
like
necessarily
the
first
step,
but
ideally
the
user
doesn't
have
to
be
involved
at
all
and
that
you
know
we
have
a
pipeline.
That
then
goes
and
builds
the
thing
that
we
changed
and
so
then
that
in
NPM
RC
or
whatever,
whatever
sort
of
build,
related
configuration
file
gets
generated
or
the
DevOps
kicks
off.
C
We
get
a
pipeline
running,
it
gets
executed,
the
user
never
has
to
be
on
the
computer
to
make
that
happen,
that's
kind
of
that's
what
I'm
this
idea
of
a
couple
of
times,
but
that's
where
I
would
like
to
go.
I
think
this
is
a
great
first
step.
I'm,
not
suggesting
this
is
needs
to
do
something
different,
but
I
don't
think
we
should
be
to
walk
into
the
idea
that
someone's
can
be
running.
C
You
know
in
thean,
build
or
whatever
like
build
command,
that's
gonna
generate
or
validate
those
those
configuration
files
and
that
actually
will
be
running
them
at
some
point.
So
I
think
that
maybe
version
2
or
3
or
something
like
that
once
we
sort
of
figure
out
but
that's
valuable
I-
think
it
will
be
but
it'd
be
nice
remaining
11.
D
D
E
So
from
the
point
of
view
of
alchemy,
they
identify
the
correct
version.
Now
we
are
just
thinking
about
the
latest
or
latest
update.
Sometimes
it
happens
that
you
need
to
lock
yourself
on
a
precise
version,
because
after
that
thing
they
had
a
bug
before
that,
even
that
the
feature
that
you
need
and
I
think
it
would
be
helpful
if
we
managed
to
sometimes
it
ends
up
that
you
are.
Writing
your
new
keynesian
say,
including
this
ish.
The
list
is
blocked
until
library,
except
ex-wife,
epsilon
or
packaging
inception
is
updated.
E
C
C
This
doesn't
mean
a
security,
but
that
idea
of,
like
hey
here's,
a
list
of
things
that
you
need
to
be
aware
of
with
regard
to
this
build-
and
maybe
that
is
referring
to
some
blocking
issue-
yeah,
that's
a
I
like
that.
That's
awesome,
I,
don't
know
if
I'm
getting
the
notes
down
properly
Nico,
because
you
skin
that
next
term
recording
them
correctly.
That's
a
great
idea!
Thank
you.
B
Just
was
awesome,
thank
you
for
putting
all
those
issues
together,
a
lot
of
what
you're
talking
about
resonates
with
what
the
research
has
been
showing,
especially
the
qualitative
research.
So
I've
been
talking
to
users,
and
you
are
kind
of
spot-on
for
addressing
some
of
the
issues
and
headaches.
Definitely
talking
about
like
updating
to
the
right
version.
Is
that
comes
up
a
lot,
so
good
job
I'm
excited.
C
E
C
If
you
see
a
pain
point
whilst
you're
doing
that
call
it
out
like
we,
don't
always
have
the
access
to
uses
that
we
might
want
to
really
validate
or
understand
what
what
struggles
they're
facing,
but
you're
doing
it
and
Konan,
for
example,
Steve
right
where
you're
saying
this
seems
weird,
but
it's
probably
just
me
doing
it
wrong,
which
is
probably
what
we're
all
doing.
Maybe
just
call
that
out
as
an
issue
and
saying
hey
in
this
process
of
me,
uploading
I
found
this
to
be
kind
of
a
pain
point
for
me.
C
You
don't
have
to
you
know
it
doesn't
have
to
be
as
detailed
and
amazing
as
Nick's
effort
here
with
the
document
and
everything
that
he's
done,
which
is
awesome.
Thank
you
so
much
for
that.
It
can
just
be
a
simple
issue,
a
like
I
mentioned
before
just
call
out
the
problem
and
a
suggested
solution,
and
then
we
just
sort
of
flesh
that
process
out.
A
Yeah,
that's
true,
even
if
you
just
write
one
sentence
and
and
put
it
in
an
issue,
that's
still
helpful
and
I'm
always
happy
to
add
details
and
things
like
that
and
ping.
You
with
questions
like
thank
you
Dan
for
for
mentioning
that,
for
we
have
this
meeting
again
in
two
weeks
from
now,
I'll
be
proud.
A
Try
and
talk
to
people
and
Ian
will
do
the
same,
like
I
think
for
adding
some
new
topics
for
two
weeks
from
now
and
see
what
we
could
talk
about-
maybe
maybe
some
front-end
stuff,
or
maybe
some
back-end
stuff
or
something
entirely
new
and
but
yeah.
This
was
great.
Thank
you
for
for
putting
all
that
together
and
going
through
all
this
is
really
helpful.
I
can't
wait
to
rewatch
this
video.