►
From YouTube: UX Showcase: Expanding the Dependency Proxy
Description
A UX Showcase to show the plan for the expanded Dependency Proxy
A
Hello:
everyone,
my
name,
is
Ian
Camacho
I
am
the
product
designer
on
the
package
stage
today
for
the
UX
showcase
I
wanted
to
share
with
you
some
of
the
work
we
are
doing
around
expanding
the
dependency
proxy
I
apologize
that
I'm
not
there
in
person.
I
had
a
bit
of
a
conflict
assuming
the
schedule
works
out.
A
I
am
actually
having
this
exact
same
conversation
with
the
rest
of
the
package
stage
discussing
where
we
came
to
with
the
design
gathering
their
feedback
and
trying
to
plan
out
how
we're
going
to
implement
something
like
this
as
part
of
our
think
bake.
So
I.
Thank
you
for
your
patience.
With
that
a
real
quick
overview,
the
packaged
stage.
A
We
take
bundled
up
pieces
of
code,
whether
that
be
a
package
or
an
image
when
we
store
them
in
a
registry
and
then
make
them
available
either
for
engineers
to
pull
down
manually
or
to
be
included
as
part
of
the
CI
pipeline.
Today,
we're
going
to
be
talking
about
the
dependency
frog
see,
it
is
a
category
in
the
packaged
stage
that
has
been
minimal
for
a
little
bit
and
our
users
have
been
talking
quite
a
bit
about
the
possibilities
we
could
introduce
in
that
area.
That
would
really
enable
them
some
initiative
goals.
A
We
have
around
expanding
the
dependency
proxy
based
on
some
user
research.
We've
done.
We
learned
that
most
projects
use
a
50/50
mixture
of
external
and
internal
hosted
packages
when
including
a
package
into
an
organization's
codebase.
The
location
it
is
pulled
from
may
vary,
and
this
variance
can
lead
to
confusion.
So
this
is
the
business
area
of
opportunity
where
we
can
make
it
easier
for
DevOps
and
system
engineers,
and
even
just
straight
engineers,
to
be
able
to
pull
and
push
and
pull
packages
more
seamlessly
and
with
less
Squarehead
for
a
user
goal.
A
We
wanted
to
create
an
easy
way
for
the
DevOps
and
system
events
to
manage
a
collection
of
registries
providing
their
team
NCI
tools
with
a
more
predictable
end
point
for
getting
packages
a
little
bit
of
history
around
this
initiative.
The
issue
9/11
64,
was
opened
about
a
year
ago
discussing
the
dependency
proxy
for
NPM.
A
Our
users
have
really
appreciated
that,
but
it
is
a
pretty
narrow
window
of
what
that
can
do.
We've
spoken
to
customers,
and
especially
at
larger
or
older
organizations,
they've
made
comments
that
the
lack
of
robust
features
and
the
dependency
proxy
has
kept
them
from
fully
utilizing
the
Gilad
packaged
registry
offering.
So
we
know
that
this
is
an
area
where
we
can
grow
and
expand
and
we're
really
in
13,
not
oh,
we
conducted
some
problem,
validation,
research.
We
spoke
to
about
8
end-users,
most
of
them
in
larger
organizations
and
discussed
with
them.
A
Some
of
the
headaches
and
problem
areas
they've
had
with
managing
many
different
package
registries
and
kind
of
solutions
that
they
either
expect
or
would
want
to
see
running
right
now.
We
also
have
a
technical
investigation.
The
reason
I
wanted
to
bring
this
up
is.
We
had
a
really
great
opportunity
for
the
design
and
the
technical
investigation
to
happen
at
the
same
time.
A
So
as
the
backend
engineers
have
been
exploring
the
possibilities
of
how
we
could
solve
this
problem,
I
have
been
working
at
the
same
time
working
on
the
design,
which
means
the
two
of
us
have
been
in
balance,
as
opposed
to
other
situations
where
that
the
design
has
to
match
the
back-end
setup
or
the
backend
has
to
respond
to
the
way
the
design
is
laid
out.
It's
been
really
cool
to
collaborate
in
such
a
seamless
fashion.
A
The
backgrounds
about
all
the
things
that
I'm
talking
about
here,
let's
start
with
the
simplest
one,
which
is
just
a
hosted
registry.
This
is
a
place,
that's
on
get
lab,
calm
and
or,
if
you're
self
posted,
wherever
you're
hosting
your
on
get
lab
and
sense,
and
it's
a
single
location
that
you
can
push
and
pull
packages
from.
It
contains
all
the
packages
that
the
organization
has
added
to
the
registry.
The
downside
of
that
is
that
they
don't
have
a
lot
of
those
common
third-party
packages
that
we're
used
to
seeing.
A
So
it
really
is
whatever
has
been
manually
added
there.
It
integrates
reasonably
cygnus
ly
with
the
rest
of
the
gate,
lab
DevOps
lifecycle,
so
we
have
opportunities
for
where
security
scanning
and
caching
and
a
lot
of
those
things
to
make
sure
pipelines
and
build
times
are
nice
display
pretty
easy
for
developers
to
utilize?
And
it's
pretty
easy
for
demos
to
manage
this.
We
have
been
excelling
at
the
package
category
and
the
container
registry
category
in
providing
this.
A
Boasted
in
remote
registries,
this
is
where
we
tend
to
find
most
of
our
users.
They
have
a
small
number
of
locations
where
they
could
possibly
pull
a
package
from,
and
users
generally
know
where
that
is
smaller
organizations.
They
tend
to
use
public
or
third-party
package
registries
that
are,
by
definition,
remote
registries.
For
us
that
can
include
something
like
you
react
package
from
NPM,
something
that's
publicly
available
and
needs
to
be
included
in
the
code
base
for
packages
that
they've
created
internally
in
our
custom
to
their
organization.
A
Some
of
the
downsides
is
that
only
some
of
the
packages
that
are
being
integrated
into
the
codebase
really
take
advantage
of
all
the
features
of
being
part
of
the
DevOps
cycle.
It
is
pretty
easy
for
developers
to
utilize,
as
well
as
CI
tools
and
DevOps
only
manage
a
little
bit
and
trying
to
make
sure
that
this
is
pretty
seamless.
A
The
area
of
opportunity
that
we
saw
is
when
you
have
a
much
more
complicated
registry,
set
up
or
have
many
locations.
This
happens
a
lot
for
large
organizations
when
they've
either
been
around
longer
and
they
have
used
different
tools
to
store
their
packages
or
they
have
a
variety
of
teams
coming
from
many
different
places
that
have
all
had
their
solutions
set
out.
It
can
be
really
difficult
in
the
scenario
for
a
developer
to
know
where
a
cage
for
a
specific
use
case
should
be
pulled
from
now.
A
On
top
of
that,
DevOps
and
system
admins
have
a
tricky
time
managing
access
to
all
of
these
different
registries
and
knowing
where
to
prioritize
when
to
look
for
something
in
one
versus
another.
This
is
an
area
that
we've
seen
a
lot
of
either
struggle
with
and
want
to
have
a
DevOps
want
to
create
a
nice
easy
solution.
So
engineers
don't
have
to
think
about
this,
while
they're
trying
to
produce
our
solution
to
that
overwhelming.
A
Where
oh,
where
is
my
package
problem,
was
by
expanding
the
dependency
proxy
I
am
thinking
of
expanding
it
in
two
different
ways.
One
of
them
is
to
expand
the
idea
of
the
remote
registry
to
allow
users
to
add
more
registries
and
custom
registries.
This
can
lower
the
administration
overhead
by
only
needing
authentication
between
the
remote
registry
itself
and
get
lab,
as
opposed
to
needing
to
create
authentication
for
each
user,
as
well
as
for
each
CI
or
seach
tool,
that's
being
involved
from
an
end-user
perspective.
A
As
an
engineer,
it
would
be
nice
to
account
that
one
single
location
where
they
can
go
and
find
all
of
the
packages
that
a
organization
uses-
and
we
coded
enable
features
for
those
remote
registries
like
hashing
or
security
scanning,
to
raise
the
stability
of
the
built
environment
that
they're
working
with
the
second
feature
that
I
would
like
to
include
and
add,
is
the
idea
of
a
virtual
registry.
This
allows
users
to
combine
multiple,
hosted
and
remote
registries.
A
This
means
there's
one
single
endpoint
that
you
can
provide
to
your
engineering
team
to
say
this
is
the
one
place
you
have
to
go
to
to
find
any
NPM
package
and
on
the
backend,
the
DevOps
engineers
or
system
admins
can
go
through
and
define.
This
should
be
the
first
place.
We
look
for
an
NPM
package.
This
is
the
second
place
and
if
we
still
can't
find
it,
let's
look
at
the
public
domain.
A
A
little
bit
of
expansion
on
that
virtual
registry
idea,
so
what
you
would
do
is
as
a
DevOps
or
system
admin,
you
can
create
a
virtual
registry
of
a
single
package
type,
so
this
would
always
be
looking
for
either
NPM
or
or
Coenen
or
even
docker
images.
You
would
only
need
to
require
authentication
once
so.
A
If
you
have
access
to
the
virtual
registry,
you
would
be
able
to
pull
from
any
of
the
packages
contained
within
it,
but
having
to
worry
about
it,
it
gives
the
opportunity
for
system
admins
and
DevOps
to
really
define
what
order
it
was
priority.
We
should
be
looking
at
to
find
our
packages,
so
this
loads,
lighten
the
load
for
engineers,
have
to
know
that
kind
of
information.
At
a
time.
It
also
gives
us
a
great
opportunity
to
enable
some
cross
stage
features
so
security
scanning
again
hashing
things
like
that.
A
The
really
cool
part
is
that
engineers
and
CI
tools
would
have
a
single
API
endpoint,
which
means
that
your
NPM
RC
file
is
a
lot
cleaner.
It
means
when
you're
building
CI
is
far
more
straightforward.
When
you're
bringing
a
new
engineer
onto
the
team,
admins
don't
need
to
create
additional
authentication,
they
only
have
to
do
it
in
one
place
at
one
time,
they'll
really
save
a
lot
of
profits,
but.
A
Next
steps
of
what
we
need
to
do
for
13,
we
have
scheduled
some
solution,
validation.
We
really
want
to
take
the
opportunity
to
look
at
the
UI
that
we
built
out
and
lay
out
a
couple
of
tasks
for
our
users,
but
really
ask
the
foundational
question
of.
Does
this
solution
enable
larger
organizations
to
manage
many
registries
more
efficiently?
A
We
can
also
ask
questions
like
what
aspect
of
the
feature
set
is
most
important
to
their
organization
and,
as
the
UI
designer
I
get
to
ask
the
question:
does
the
UI
actually
enable
you
to
understand
the
offering
and
is
it
easy
for
you
to
implement
the
dependency
proxy
solutions
once
we
get
through
some
solution?
Validation,
we're
going
to
review
the
design
and
technical
investigation?
This
is
a
pretty
large
endeavor.
A
So
after
we've
looked
at
it
and
analyze
it
we're
gonna,
create
an
epoch
for
updating
the
dependency
proxy
and
then
create
much
smaller
issues
that
are
devoted
to
more
of
that
MVC
and
iteration
building
one
piece
at
a
time
ensuring
each
piece
has
value
creating
a
larger
stage
and
then
lastly,
we
would
like
to
begin
conversations
with
cross
stage
opportunities
earlier.
So
we
can
build
them
in
as
we
build
this
more
robust
dependency
proxy.
A
Thank
you
all
for
taking
the
time
and
I
appreciate
again
your
patience
for
listening
to
the
recording,
instead
of
having
me
there
in
person.
If
you
have
any
questions
around,
this
feel
free
to
reach
out
to
me
or
pay
me
on
slack
or
any
way
that
you'd
like
to
get
a
hold
of
me.
I
would
love
to
share
our
information
that
we
have
around
this
as
well
as
kind
of
get
your
thoughts
and
feedback.
Thank
you
all.