►
From YouTube: Learn how companies like Phone2Action are using npm - Daniel Sauble and Daniel Thompson
Description
In this case study discussion, gain insight into how companies like Phone2Action are using npm in their front-end development.
A
Hello,
everyone
and
welcome
to
today's
webinar
learn
how
companies
like
phone
to
action
are
using
NPM
in
their
front-end
development.
My
name
is
Danielle
Wambach
and
I'll,
be
a
moderator,
I
work
on
the
marketing
team
here
at
NPM
and
I'm
excited
to
be
hosting
today's
session
I'm
pleased
to
introduce
today's
speakers.
Daniel
Shaw
ball,
head
of
product
here
at
NPM
and
Daniel
Thompson
front-end
developer
at
phone
to
action
before
I
hand
it
over
to
Daniel
as
a
few
housekeeping
items
to
cover
about
the
presentation
in
the
bright
top
webinar
platform.
A
First,
today's
webinar
will
be
available
on
demand
after
the
live
session
and
it's
accessible
through
the
same
length
you're
using
now,
we've
also
added
some
attachments
which
are
available
through
the
attachment
tabs
at
the
bottom
of
your
screen.
This
is
where
you'll
find
today's
slides
and
other
related
content
content
such
as
our
blog
next
we'd
love
to
hear
from
you
during
today's
presentation.
We
have
a
question
for
the
Daniel.
Please
feel
free
to
send
it
through
the
ask
the
question.
A
B
B
So
there's
kind
of
these
three
classes
of
leaves
these
three
categories
of
the
software
that
you
contribute
to
as
a
developer,
and
so
NPM
prose
was
really
intended
to
provide
a
place
that
encapsulates
these
last
two
areas
and
the
thing
is:
there's
a
lot
of
developers
that
are
kind
of
like
you,
and
so
we
all
kind
of
intuitively
know
how
open-source
works.
You
have
a
large
body
of
maintained
errs
who
are
focused
on
making
the
ecosystem
as
good
as
it
possibly
can
be.
B
And
so
with
NPM
Pro,
we
wanted
to
solve
this
problem
and
basically,
if
you
get
to
a
point
in
your
personal
project,
maybe
it's
the
start
of
idea
or
it's
something
that
you
aren't
quite
ready
to.
Let
the
project
community
see
yet
you
can
maybe
pull
in
one
other
person
or
two
other
people
and
have
them
help
you
make
it
better
and
get
it
ready
to
to
go,
live
to
others
and
the
public
at
large,
and
so
a
way
you
can
think
about.
B
Npm
Pro
is
that
it's
essentially
a
box
that
it
belongs
to
you
and
encapsulate
all
of
your
personal
projects,
and
so
you
can
invite
other
NPM
Pro
users
inside
your
box
to
maintain
specific
packages
that
you
want
to
collaborator
on,
and
they
can
do
the
same
for
you,
but
to
make
sure
the
NPM
Pro
is
consistent
with
the
way
that
most
people
use
NPM.
Today.
B
So
with
NPM
Pro,
you
get
an
unlimited
number
of
these
private
personal
packages
as
well
as
those
public
packages,
but
in
addition,
you
also
get
basic
support
for
when
you
run
into
issues
using
NP,
and
you
also
have
access
to
all
those
great
NPM
security
features
that
you
get
to
use
today,
including
things
like
NPM
audit,
which
helps
to
automate
that
research
and
remediation
process.
When
you
run
into
packages
that
have
vulnerabilities
and
then
finally,
with
NPM
Pro,
you
get
that
dedicated
namespace.
B
But
how
does
NPM
pro
compared
to
NPM
teams,
so
we
recently
renamed
NPM
orcs
to
NPM
teams.
So
now
we
have
these
two
products:
side
by
side,
NPM,
Pro
and
NPM
teams
and
understanding
the
difference
between
them.
I
think
is
really
important
because,
while
they
look
very
similar
from
the
outside
they're
actually
intended
for
very,
very
different
use
cases.
B
So
you
remember
earlier
I
mentioned
that
a
typical
developer
has
kind
of
these
three
areas
where
they
write
and
contribute
code.
You
have
your
day
job.
You
have
those
open
source
projects
that
you
write
on
the
side
and
then
you
also
have
those
personal
projects
that
you
write
on
the
side
and
NPM
teams
is
really
intended
for
that.
First
category
of
your
day,
job.
B
So
how
you
can
think
about
teams
is
that
it's
essentially
a
box
that
sits
around
your
entire
company's
organization,
so
all
of
the
developers
in
your
company
and
all
of
their
packages,
both
public
and
private,
fit
within
this
box
and
because
your
organization
probably
has
more
than
just
one
development
team.
Npm
teams
makes
it
possible
to
accurately
map
to
what
your
organization
structure
actually
is.
B
So
if
you
have
two
teams,
each
with
say
five
developers,
the
five
developers
in
the
first
team
can
have
access
to
the
packages
they
need
to
do
their
job
and
the
developers
and
the
second
team
can
have
access
to
the
packages
that
they
didn't
even
their
job.
An
NPM
team
provides
a
really
convenient
wrapper
around
this
construct.
B
B
B
B
So,
with
this
great
popularity
comes
a
great
responsibility
to
make
sure
that
the
NPM
ecosystem
is
as
good
as
it
possibly
can
be,
and
so
these
are
four
areas
that
we're
actively
looking
to
make
better
I
want
to
talk
about
each
one
of
them
briefly,
so
the
four
areas
are
discovery,
collaboration,
security
and
the
developer.
Experience.
B
So
discovery
becomes
a
really
difficult
problem.
When
you
have
so
many
packages
in
the
case
of
NPM,
you
literally
have
a
million
packages
to
choose
from.
So
how
do
you
find
the
one?
That's
the
best
for
your
application,
and
so
today,
if
you
go
to
NPM
J
Escom,
you
can
search
for
packages.
You
can
even
look
at
categories
of
packages
to
help
winnow
down
those
million
packages
into
a
subset,
that's
more
manageable,
but
we
want
to
make
this
search
experience
even
better.
So
this
is
an
area
that
we're
actively
looking
to
improve.
B
But
another
problem
is
collaboration,
and
so,
when
you
have
an
ecosystem
that
consists
of
11
million
developers,
who
are
collectively
responsible
for
maintaining
all
1
million
of
those
packages,
how
do
you
make
sure
that
they
can
do
that
effectively?
I
think
those,
as
we
all
know
from
from
recent,
has
security
issues.
B
Sometimes
packages
can
fall
through
the
cracks,
even
packages
that
are
heavily
relied
upon
by
an
entire
ecosystem,
so
making
sure
that
we
service
packages
that
are
in
need
of
help
and
assistance
is,
is
a
really
important
ingredient
to
making
sure
that
the
ecosystem
can
remain
healthy
as
it
grows,
and
one
thing
that
we've
done
recently
to
to
make
this
better
is
announcing.
The
new
NPM
fund
account
some
command
within
the
CLI,
which
lets
you
essentially
put
within
your
package.
Json
a
field
where
you
can
link
to
a
funding
platform
that
you
use
to
support.
B
The
development
of
a
particular
package
and
NPM
fund
makes
this
field
visible
to
others
who
are
installing
and
using
your
packages,
but
we
also
have
other
things
that
we're
also
looking
to
do
to
make
this
particular
area
of
improvement
even
better,
and
this
feeds
really
closely
into
this
issue
of
security.
So
NPM
is
well
known
for
having
a
high
degree
of
modularity.
B
So
if
you
have
a
dozen
top-level
dependency
specified
in
your
application,
chances
are
when
you
run
NPM
install
you're
actually
going
to
download
hundreds,
or
maybe
thousands
of
intermediate
or
transitive
dependencies,
and
the
problem
is
if
any
one
of
these
thousands
of
dependencies
has
a
security
issue.
The
effects
of
that
can
trickle
down
into
your
application.
So
it's
really
important
to
know
when
any
of
these
many
hidden
dependencies
have
problems
that
you
need
to
know
about,
and
so
we
already
have
tools
to
to
address
this.
B
So
what
we're
trying
to
do
NPM
actually
raise
more
of
these
signals
up,
so
that
you're
able
to
get
the
information
that
you
need
to
make
an
informed
decision
about
what
packages
you
should
or
should
not
use,
rather
than
relying
on
a
pure
binary
black
and
white
policy
and
the
final
area
of
improvement.
Is
this
concept
of
the
developer
experience?
So
when
you
have
a
registry,
that's
growing
at
forty
percent
per
year,
it
becomes
a
really
large
effort
to
make
sure
that
the
registry
performs
as
well
as
it
possibly
can.
B
Our
goal
for
the
registry,
this
court
to
be
invisible.
We
want
it
to
always
be
there
when
you
need
it
and
we
want
it
to
be
really
really
fast.
So,
when
you're
running
npm
install',
you
don't
even
realize
that
there's
this
registry
upstream
of
serving
all
these
hundreds
and
thousands
of
packages,
but
the
other
component
of
the
developer
experience
is
the
interface
that
you
use
to
interact
with
it.
And
for
most
of
you,
that's
going
to
be
the
NPM
CLI.
So
we
have
a
whole
team.
B
C
C
C
So,
for
instance,
if
they
have
a
new
campaign
coming
up
or
a
new
issue,
they
can
announce
that
out
to
the
people
who
previously
participated
in
order
to
increase
engagement,
this
email
tool
is
one
of
our
newest
features
and
it's
one
a
kind
of
a
number
of
features
that
we've
implemented
over
the
past
couple
of
years
and
we've
started
to
notice
a
couple
of
issues
in
our
front-end
development,
with
the
addition
of
you
know
kind
of
attacking
on
of
each
of
these
new
features.
So
what
are
those
issues?
C
These
are
pretty
common
front-end
development
issues,
I
would
say
in
any
sort
of
growing
project.
We
have
seen
some
code
duplication
across
different
features
of
the
site
with
similar
UI
elements,
so
maybe
tool
tips
or
modal's
or
something
like
that
showing
up
duplicated
in
different
parts
of
the
site.
In
those
cases,
we've
also
seen
some
small
inconsistencies
in
the
design,
so
how
those
things
look?
And/Or?
C
The
implementation
of
those
elements,
so
the
code
might
look
a
little
bit
different
in
one
place
to
the
other,
and
all
of
that
comes
together
to
make
it
really
hard
to
confidently
update
the
elements
that
we
already
have.
So
if
we
decide
you
know,
we
want
to
change
the
background
color
of
all
the
tooltips
on
the
website.
We've
got
to
go
through
and
find.
C
Luckily,
these
are
somewhat
frequently
run
into
issues
in
the
front-end
development
world,
and
there
are
some
good
solutions
out
there.
What
we've
decided
to
do
is
build
a
design
system,
so,
in
addition
to
addressing
these
issues,
that
I
was
just
talking
about.
Our
design
system
is
also
built
to
work
along
with
a
feature
by
feature
redesign
of
our
platform
of
our
admin
dashboard.
So
this
design
system,
we
called
it
beacon
it
serves
both
as
a
brand
and
style
guide
and
a
component
library.
C
So
it
gives
us
kind
of
a
single
source
of
truth
for
both
the
design
things
like
what
colors
are
allowed
to
show
up
on
the
site.
What
sort
of
you
know
spacing
we
can
have
on
things?
What
specifically
do
our
modal's
look
like
or
or
our
tooltips
etc?
All
of
our
different
UI
elements
and
then
also
gives
us
the
single
source
of
truth
for
code.
So
it
gives
us
kind
of
a
limited
API
of
CSS
classes.
C
This
design
system
is
actually
hosted,
so
this
is
where
NPM
comes
into
play.
Our
design
system
is
hosted
as
a
private
package
on
NPM
through
well,
what
was
NPM
Awards
and
what
will
now
be
NPM
teams,
I
believe
so
you
might
be
wondering
well.
Why
did
we
decide
to
do
this
as
a
separate
package
and
not
just
include
these
components
in
some
sort
of
you
know
shared
folder
nested
within
our
platform
code,
and
there
are
a
number
of
benefits
to
that.
C
Some
of
these
are
just
kind
of
the
standard
benefits
that
come
with
any
sort
of
you
know
open
source
type
library.
So
we
get.
You
know
we
have
semantic
versioning
on
this.
We
can,
you
know,
bump
up
the
version
number
as
we
make
changes
in
the
design
system
code
and
then
ensure
that
we've
prepared
for
those
changes
on
the
platform
side
when
we
include
it.
C
It
also
lets
us
reuse
this
design
system
code
across
our
project,
so
we
can
actually
ensure
consistency,
not
just
within
the
admin
dashboard,
but
then
across
our
various
other
projects
and
products
as
well.
One
of
the
the
big
benefits
that
that's
come
from
this
division
here
actually
is
a
clear
delineation
of
who
owns
what
code.
C
So
we
have
a
design
system
team,
particularly
that
is
made
of
front-end
developers
and
designers
and
some
full-stack
developers
on
all
of
whom
are
also
working
on
our
main
platform,
but
who
are
really
in
charge
of
this
design
system,
code
and
API.
So
this
removes
some
of
the
obligation
from
other
platform
developers
to
do.
You
know
some
of
the
more
intricate
UI
work.
If
we
have
some,
you
know
new
version
of
a
modal
or
new
tweak
to
a
UI
element.
C
We
get
the
people
who
are
in
charge
of
the
design
system
to
worry
about
things
like
okay.
How
are
we
going
to
test
this
across
browsers?
How
are
we
going
to
worry
about
responsive
design
here?
How
are
we
going
to
make
sure
that
this
remains
accessible
and
because
we've
had
we're
able
to
focus
that
only
on
the
design
system
team,
it
frees
up
the
rest
of
the
platform
developers
to
focus
on
you
know
the
other
parts
of
the
work
that
they're
working
on.
C
This
also
means
that
we
can
have
a
totally
separate
flow
review,
so
we
have
different
JIRA
tickets,
we've
got,
you
know
hub
issues
and
pull
requests
and
such
that
are
all
going
to
a
separate
repository
rather
than
all
being
concentrated
in
one
place.
So
we
just
again
are
limiting.
Who
is
working
on
what
stuff
so
that
you
know
they
can
focus
on
things
that
they're
really
intending
to
work
on
and
then,
finally,
as
you
saw,
we
have
a
documentation
site
for
begin.
C
The
code
for
that
documentation
site
is
included
in
our
package
in
NPM
so
that
we're
able
to
you
know
on
board
new
design
system
developers
and
team
members
as
necessary
without
having
to
worry
about
you
know
getting
all
the
other
dependencies
of
our
or
platform
site
in
place
and
I
believe.
That's
all
that
I
had
so
I'll
turn
it
back
to
Daniel
and
I.
Think
we'll
take
some
questions.
C
As
you
said,
you
know
many,
many
many
or
you
know
the
vast
majority
of
javascript
code
is
already
using
NPM,
and
so
we
really
in
order
to
get
the
package
in
place
on
the
platform
side,
it
was
as
easy
as
adding
one
little
line
to
our
package
that
JSON
and
getting
the
package
actually
hosted
by
NPM
again
was
with
a
very
kind
of
quick
and
easy
flow
there,
so
that
the
hardest
part
of
all
that
was
the
actual.
You
know,
writing
the
code
in
a
way.
B
C
Say
absolutely
honestly,
I
kind
of
want
to
break
out
some
of
the
other
stuff
that
we
have
in
our
platform
into
other
packages
too.
We've
got,
you
know,
I
think
it
especially
for
me
the
biggest
benefit
there
is
that
breaking
up
of
the
teams
and
really
being
able
to
totally
focus
on
you
know
the
things
that
we're
working
on
and
making
sure
that
we're
not
putting
the
brunt
of
the
UI
work
on
somebody
who's.
Just
trying
to
you
know,
implement
something.
So
they
can.
You
know,
build
in
a
filter
or
something
like
that.
B
C
To
end
up
being
the
design
system,
we
certainly
have
some
rules
with
into
the
design
system
about
how
pages
should
be
laid
out,
and
you
know
how
the
sidebar
and
stuff
should
work.
This
is
sort
of
an
incremental
process.
So
right
now
it's
mostly
just
kind
of
the
smaller
UI
components.
We've
got
buttons
and
tooltips
and
moodle's,
and
a
couple
other
small
things,
and
because
we're
doing
this
as
a
feature
by
feature
redesign
as
well,
we
have
pages
on
the
site
that
are
still
using.
B
C
So
we
use
kind
of
a
combination
of
git
and
github
permissions
and
NPM
permissions.
So
anyone
can
anyone
on
our
whole
engineering
team
can
submit
a
pull
request
to
our
design
system
repository
on
github,
and
then
we
have
a
process
through
there,
where
only
members
of
the
design
system
team
can
review
and
improve
those
pull
requests.
And
then
we
have
an
even
smaller.
You
know
group
of
people
who
are
in
charge
of
actually
getting
the
code
from
github
into
NPM
and
getting
that
package
updated.
B
C
Yeah
first,
we
would
like
for
that
to
be
as
automated
as
possible
right
now,
I
believe
when
we
merge
into
master
even
on
github,
there's
already
an
automatic
hook.
That
goes
there
and
I
think
that
somebody
just
has
to
prove
that
in
order
to
to
make
it
go
all
the
way
through.
So
there's
a
pretty
limited
amount
of
real
work
that
we
have
to
do
once
that
it
gets
approved
by
the
team.
Awesome.
B
We
have
another
question
here
about
multiple
private
packages.
So
do
you
have
multiple
affect
private
packages
and
if
so,
what
are
some
of
the
things
you
have
learned
while
breaking
them
out
into
multiple
packages?
And
what
tips
do
you
have
for
those
who
are
in
the
process
of
breaking
out
a
codebase
into
multiple
packages?
I
thinks.
C
It's
a
good
question
right
now.
Our
design
system
is
the
only
private
packet
or
well.
So
we
have
a
couple
other
private
packages
that
are
one-off
tools,
but
this
is
the
only
one
that
we
use
in
this
way
where
we're
really
importing
it
into
a
bigger.
You
know
the
bigger
product
of
the
platform.
I
think
it
has
been
helpful
for
us
to
do
this
breakout
into
the
design
system.
C
As
you
know,
in
line
with
a
redesign
because
it
makes
it
more
obvious,
especially
the
people
who
are
looking
at
this
design
system
everyday
to
see
which
parts
of
the
site
have
already
kind
of
implemented.
The
design
system
in
which
parts
haven't
I
think
that
if
we
were,
you
know
going
back
and
pulling
out
content
that
was
already
written,
because
this
actually
came.
C
B
B
B
B
Also,
it
looks
like
we
got
a
quick
clarification
on
the
mono
repo
question,
so
it
looks
like
what
they
meant
by
micro
repos,
essentially
the
difference
between
having
a
single
mono
repo
for
all
of
your
packages
versus
having
kind
of
one
repo
for
each
package.
So
basically
you
have
all
your
packages
in
one
repo
or
do
you
kind
of
split
them
up
and
kind
of?
What's
your?
What's
your
take
on
what
the
right
approach
is,
yeah.
C
Absolutely
so
I
think
you
know,
as
some
as
I've
talked
about
I,
think
I
enjoy
the
benefits
of
having
these
actually
broken
out
completely
and
really
letting
people
that
are
working
on
different
parts
of
the
site
not
even
have
to
think
about
or
worry
about.
The
other
things.
I
think
that
that
is
a
you
know,
I'm
sure
that
that
is
a
a
good
solution
for
us
right
now.
I
can't
say
that
that's
you
know
going
to
be
good
across
the
board,
for
everyone.
C
I
definitely
understand
some
of
the
benefits
of
doing
a
mono,
repo,
but
I.
Think
in
this
case,
where
we
have
a
dedicated
team,
that's
in
charge
of
this,
and
that
team
is
not
totally
Tyson's.
You
know
completely
off
to
the
side,
we're
also
continuing
to
work
on
the
core
platform.
It
actually
makes
a
lot
of
sense
to
have
it
to
kind
of
protect
ourselves
and
to
protect.
You
know
the
boundaries
of
the
design
system
from
the
rest
of
the
platform,
I.
Think
having
the
kind
of
multiple
repositories
here
is
really
helpful.
C
B
A
You
thank
you
Daniel
and
Daniel.
As
mentioned
earlier,
today's
webinar
will
be
available
on
demand
after
the
live
session
and
it's
accessible
through
the
same
link
you're
using
now,
we've
also
added
some
related
materials,
including
today's
slides
in
the
attachment
tab
at
the
bottom
of
your
player.
Thank
you
happy
holidays,
and
thank
you
for
joining.