►
From YouTube: OpenJS Foundation AMA- ESLint
Description
The OpenJS Foundation is a member-supported non-profit organization that provides a neutral home for some of the most important project in the JavaScript ecosystem.
Learn more and join us at https://openjsf.org
A
Great
and
we
are
live,
welcome
everybody
to
the
openjs
foundations,
monthly
ama,
where
we
spotlight
cool
things
and
projects
happening
in
the
community,
and
we
get
your
questions
answered
today.
We
have
kai
cataldo
and
brandon
mills
from
eslint
and
before
I
hand
it
over
to
these
fine
folks,
I
wanted
to
let
you
know
how
to
participate
in
today's
ama.
A
B
Hi,
I'm
kai
first
of
all,
thanks
for
having
us
today.
We're
really
excited
to
be
doing
this.
Just
a
little
background
about
myself.
I
am
a
former
musician
turned
web
developer.
B
Who's
been
working
on
open
source
projects,
namely
in
in
the
javascript
tooling
space.
For
about
I
think,
five
years
now,
four
or
five
years
I
got
involved
in
open
source
at
adobe,
where
I
worked
on
a
team
with
henry
joo,
who
is
a
maintainer
of
babel.
B
He
introduced
me
to
to
linting
and
to
and
help
me
actually
land,
my
first
pr,
which
is
what
sparked
my
interest
in
all
of
this
and
yeah.
I've
been
on
the
technical
steering
committee
for
eslid
for
past
couple
years,
and
as
of
last
winter,
I
was
hired
as
the
first
dedicated
maintainer
for
eslint,
and
so
I've
been
working
part-time
on
the
project
for
past
seven
or
eight
months.
I
guess,
and
I'm
also
a
maintainer
of
babel
as
well
yeah.
I
guess.
C
That's
that's
all
about
me
very
cool.
Well,
I'm
brandon.
I
am
also
on
the
eslint
technical
steering
committee.
I
have
been
contributing
since
2014.
I
think
I
started
contributing
to
open
source
when
I
found
abstract
syntax
trees
as
part
of
a
parser's
class
in
school
and
thought
it
was
pretty
cool
and
realized.
C
There
was
a
lot
that
I
could
do
with
abstract
syntax
trees
and
saw
this
really
cool
eslint
project
that
was
new
for
javascript
and
started
playing
around
with
it
and
writing
rules
and
kept
contributing-
and
I
remember
my
very
first
open
source
pull
request.
I
did
not
have
somebody
like
henry
to
be
a
mentor
for
that.
It
was
just
pushing
some
code
out
into
the
ether
and
all
of
a
sudden
it
was
merged
and
released,
which
is
a
really
cool
feeling
and
I
haven't
lost
that
contributing
to
open
source
can
be
really
cool
like
that.
C
So
do
we
want
to
start
off
with
just
background
on
eslint,
and
all
that
sounds
good
to
me.
Okay,
so
the
founder
of
eslint
nicholas
is
not
on
the
call
today.
So
what
you'll
be
getting
is
the
summary
as
best
as
kai-
and
I
can
tell
it,
but
earlier
on
in
javascript
there
was
jslint
and
js
hint
and,
as
I
understand
it,
the
biggest
motivation
for
eslint
was
to
be
completely
pluggable,
and
so
eslint
will
look
at
your
code
parse.
C
It
turn
it
into
an
abstract
syntax
tree
and
through
whatever
configuration
you
provide
and
whatever
plugins
you
provide,
it
will
say:
hey.
I
found
this
problem
here,
you're
using
this
variable
that
you
haven't
defined
and
there's
something
over
here
that
you
might
want
to
take
a
look
at
this
doesn't
seem
right
and
that's
all
done
through
your
plugins,
your
rules,
your
your
configuration
on
that
abstract
syntax
tree
and
when
nicholas
started
it
there
was
no
ecosystem
and
all
the
rules
were
in
core.
C
B
Yeah,
so
I
I
do
think
that
esl's
flexibility
has
really
contributed
to
its
success.
The
web
development
landscape
has
changed
a
lot
over
the
past
decade
and
you
know
there's
all
there's
new
syntax
being
added
to
javascript.
There
are
all
these
different
runtimes
for
javascript.
We
have
jsx,
we
have
view
we
have
all
these
things
and
so
having
an
extremely
opinionated
set
of
rules
that
only
links
javascript
would
only
serve
a
very
small
subset
of
the
community
and
yeah
so
anyway.
B
That
flexibility,
I
think,
is
what
has
led
to
eslint
being
adopted
so
so
widely.
Last
time
I
checked,
I
thought
it
was
something
on
npm,
something
like
12
million
downloads
a
week
or
something
something
astronomical
kind
of
mind-boggling
and
yeah.
I
guess:
do
we
wanna
talk
a
little
bit
more
about
what
a
linter
is
for
those
who
may
not
have
used
one
before
yeah
cool?
I
can.
B
I
can
do
that
if
you
want
so,
as
brandon
was
saying,
a
linter
is
a
tool,
that's
kind
of
like
spell
check
for
your
code.
It
lets
you,
that's
how
I
think
of
it
anyway.
It
lets
you
check
for
syntax
errors.
I
think
traditionally
I
don't
know
too
much
about
the
history,
so
it
could
be,
could
be
a
bit
wrong
about
this,
but
at
least
in
the
javascript
landscape.
Linters
have
very
opinionated
rules
where
you
didn't
have
control
over
what
it
was
telling.
B
You
was
incorrect
or
correct,
and
so
the
the
goal
of
eslint
is
not
to
tell
you
how
to
write
code,
but
to
allow
you
to
write
the
code
that
you
want
to
write
and
enforce
that
we
really
don't
want
to
be
in
the
business
of
saying
like
hey,
you
should
write
code
this
way.
B
We
we
think
that
you
should
make
that
decision
for
yourself,
but
leaving
that
to
humans
on
pr's,
on
pull
request.
Reviews
is
a
lot
of
wasted
energy
and
being
able
to
automate
that
away
is
a
big
time
saver
for
everyone.
I
guess
one
other
thing
I'll
say
about
eslint-
is
that
one
of
the
reasons
I
started
contributing
is
that
I'm
a
self-taught
developer
like
like
many
of
us
and
using
at
this
point
this
was
earlier
on.
B
So
this
was,
I
think,
j
s
hint,
but
finding
js
hint
and
having
some
kind
of
feedback
on
my
code.
As
I
was
writing,
it
was
actually
really
huge
for
me
saved
me.
A
lot
of
time
taught
me
a
lot
of
things
and
that's
one
of
the
reasons
why
I
love
contributing
to
eslint,
actually,
is
that
I
think
it's
it's
a
great
way
for
people
who
are
maybe
new
to
to
coding
or
new
to
javascript,
to
quickly
pick
up
on
some
core
concepts
that
they
might
not
otherwise
and
get
feedback
on
their
code.
C
Yeah,
that
was
a
lot
of
good
stuff
in
there.
I
think
one
of
the
key
points
is
that
we're
not
in
the
business
of
telling
you
what's
good
code
or
what's
bad
code,
we
have
our
recommended
configuration
that
people
can
extend
from,
but
we're
very
careful
about
what
we
include
in
there.
So
if
you
extend
eslint
recommended
you're
only
going
to
get
the
rules
that
we're
pretty
sure
are
actual
bugs
in
your
code,
like
hey,
you
referenced
a
variable
here,
it
doesn't
exist,
it's
probably
going
to
throw
an
exception
at
runtime.
C
C
We
also,
I
think,
see,
people
thinking
that
eslint
is
just
about
style
and
formatting
and
to
me
at
least
the
most
value
comes
from
the
rules
that
look
at
how
the
code
is
structured
rather
than
how
it's
formatted
and
do
look
and
say:
hey
you're,
comparing
with
a
triple
equals
to
null
here,
but
this
might
also
be
undefined
and
that's
a
case.
You
aren't
checking
and
it's
it's.
The
actual
flow
of
the
program
that
I
find
really
valuable.
C
There
are
pretty
prettier,
is
a
really
popular
formatter
and
that
will
normalize
styling
for
a
project
and
team
and
there's
a
prettier
plug-in
for
eslint
and
I
think,
there's
an
es1
plug-in
for
prettier,
but
you
can
integrate
those
tools
and
and
so,
for
example,
my
team
at
work.
We
use
prettier
for
all
the
formatting
and
default
to
its
rules
there,
but
then
we
also
use
eslint
to
look
at
how
our
code
is
written
and
tell
us
ways
that
we
could
refactor
it
and
improve
it.
B
Yeah
this,
this
might
be
a
bit
of
a
controversial
opinion,
but
I
actually,
after
having
spent
a
lot
of
time
on
this,
I've
become
a
firm
believer
that
styles
should
be
handled
by
a
formatter
and
not
not
the
linter,
and
that
the
linter
should
be
used,
just
as
as
brandon
is
describing
because
putting
all
of
it
in
the
linter
makes
the
kind
of
puts
them
at
the
same
level,
and
I
don't
think
like
using
single
quotes
instead
of
double
quotes
should
be
as
high
priority
or
should
be
like
warned
as
high
priority
as
like
a
syntax
error,
or
some
very
dangerous
pattern.
B
C
C
I
I
really
agree
with
agree
with
that,
and
you'll
often
hear
people
say
that,
if
somebody's
commenting
with
a
knit
about
formatting
or
something
like
that
in
a
pull
request
that
doesn't
really
build
value
for
the
time
it
takes
to
comment
on
it
and
then
fix
it
and
then
approve
the
comment
and
the
change
the
real
solution.
There
is
throw
it
in
the
linter
and
then
you
never
have
to
think
about
it
ever
again,
and
so
a
lot
of
those
things
around
hey.
C
C
C
That
yeah,
let
me
pull.
B
Do
not
have
this
memorized.
Maybe
I
should
okay
yeah,
so
we
recently
decided
to
commit
to
a
public
roadmap.
B
We
had
a
lot
of
internal
discussions,
some
public
discussions
on
github
and
yeah,
so
we
have
a
couple
things
that
are
that
we
have
decided
that
we
want
to
commit
our
resources
to
over
the
coming
months
and
we're
really
excited
about
all
of
them.
So
I'll
start
with
the
thing
that
I
guess
I'm
most
excited
about,
because
I'm
working
on
it,
maybe
selfishly.
B
We
are
participating
in
google
season
of
docs,
which
is
a
program
run
by
google
that
matches
technical
writers
with
open
source
projects
to
improve
their
documentation
and
we're
just
starting
that
process.
Now
we
have
our
technical
writer
selected
and-
and
he
and
I
are
having
meetings
and
and
kind
of
figuring
out
where,
where
we
want
to
go
with
this,
but
we're
going
to
be
working
on
the
configuration
documentation
which
your
eslint
has
been
around.
B
I
think,
since
2011
is
that
right,
2012
12
13,
something
like
that
yeah
okay-
should
have
looked
it
up
beforehand,
but
anyway
it's
been
around
a
long
time
and
as
a
result,
the
documentation
has
existed
for
a
long
time
and
has
been
iterated
on
for
for
very
for
a
very
long
time.
B
Now,
and
in
that
process,
we've
added
a
lot
of
new
options
and-
and
you
know,
as
I
said
before,
the
javascript
ecosystem
requires
a
lot
of
configuration
just
because
of
all
the
runtimes
and
different
syntax
and
and
so
so
on
and
so
forth,
and
so
the
configuration
documentation,
probably
initially
when
it
was
written,
was
very
clear
and
concise
as
a
one-page
document,
but
has
since
grown
to
be
this.
B
This
giant
one-page
document
that's
pretty
hard
to
navigate,
and
so
our
focus
is
going
to
be
on
improving
that
so
that
that
people
can
find.
You
know,
find
the
information
that
they
need
quicker
and
more
easily.
B
All
of
our
repositories-
branches
from
the
from
master
to
maine
we're
going
to
be
doing
that
over
we've
started
a
little
bit
of
work
on,
I
think
nicholas
has
has
started
updating
our
tooling
for
it,
but
we've
committed
doing
that
and
that
will
be
ongoing
over
the
next
couple
months.
I
think
github
is
also
planning
to
implement
some
some
tooling
on
there
and
that'll
make
it
easier
for
us
as
well
yeah.
C
And
if
you
go
to
our
rfc's
repository,
you
can
find
the
simple
config
proposal
and
see
everything
about
it,
but
similar
to
what
I
was
saying
about
accumulating
years
worth
of
documentation
all
of
those
options
also
accumulated
over
years,
and
so
our
existing
configuration
system.
We
have
what
we
call
the
cascade.
So
if
you
have
a
parent
directory,
you
might
have
a
config
file
in
there
and
then
you
might
have
a
couple
different
directories
in
there
that
each
have
their
own
configuration
files.
And
so
we
have
to
look
when
we
see
a
file.
C
C
So
the
new
configuration
system
that
nicholas
is
working
on
will
use
imports
or
requires
and
you'll
be
able
to
resolve
plugins
that
way,
and
so
that
should
fix
a
lot
of
weird
edge
cases
that
we
currently
have
around.
How
do
you
properly
npm
install
the
right,
plugin
and
all
of
its
dependencies,
we'll
just
be
building
on
top
of
the
node
module
resolution
algorithm
and
get
that
basically
for
free?
How
do
I
use
esl
plug-in
import?
Well,
you
import
it
and
that's
that's
all.
There
is
to
it
with
this
new
configuration,
so
yeah
check
that
out.
C
The
rfc
is
public
and
nicholas
is
working
on
that
now
then,
the
other
big
project
that
we'll
be
tackling
on
the
roadmap
is
something
that
we've
been
wanting
to
do
for
a
few
years
and
that's
parallel
linting,
where
we
don't
have
to
lint
everything
serially
anymore.
We've
done
some
infrastructure
work
on
that.
We
recently
introduced
a
new
top
level
api
for
eslint.
C
We
used
to
use
a
class
called
cli
engine,
and
that
was
all
synchronous
so
before
we
could
do
anything
with
parallel
linting,
we
needed
to
introduce
a
new
node.js
api,
and
so
that's
now
asynchronous
and
it
allows
us
to
implement
parallel
linting
underneath
that
api,
and
so
that
one
is
still
in
the
design
stages.
There's
an
rfc
if
you
have
thoughts
or
requirements
that
we
would
need
to
address
in
that
proposal,
feel
free
to
chime
in
on
the
rfc.
B
I
was
just
there
yeah,
no,
nothing
to
add
to
what
you
said.
I
adding
to
what
I
said,
though.
I
realized
that
I
did
not
talk
about
the
most
important
part
about
why
we're
switching
from
master
domain
for
our
our
branches,
and
that
is
that
we
as
a
community
want
to
be
inclusive
of
everyone
and
so
we're
we're
following
a
lot
of
other
projects
in
moving
from
a
language
that
can
be
exclusive
to
inclusive
language.
B
B
Looking
at
the
time,
maybe
we
should
move
on
to
the
questions.
We've
talked
a
lot
about
eslip,
but
I
know
that
that
people
have
have
some
questions
for
us
yeah.
That
sounds
good.
C
So
one
of
the
ones
that
was
really
interesting
to
me
was,
will
you
add,
html
linting,
similar
to
html,
lint
or
html
hint.
So,
as
kai
said
earlier,
when
eosin
was
started,
it
was
just
javascript
that
we
need
to
lend
and
we've
gradually
expanded
to
lint
view
and
react.
C
Linting
html
directly
is
a
new
thing
that
we're
kind
of
playing
with
there
was
an
rfc
recently
merged
for
generic
ast
support,
so
eslint
to
date
has
been
built
with
the
assumption
that
it
will
receive
a
javascript
ast
of
some
sort,
that
it
will
have
certain
properties
that
the
root
node
will
be
named
program
that
every
node
will
have
a
type
with
a
string
in
it
that
every
node
will
have
location
information
and
how
that's
structured
and
so,
for
example,
babel
esling,
which
is
a
really
common
parser
that
people
use
uses
a
slightly
different
ast
structure
than
eslint's
default.
C
Parser
typescript
also
uses
a
different
ast
structure
than
esl's
default,
polisher
parser.
So
what
this
would
allow
is
eslint
processing
asts
that
it
wasn't
originally
designed
to
process,
because
we've
made
certain
things.
Generic
and
a
parser
can
now
tell
eslint
here's
how
you
figure
out
what
variables
are
in
scope,
wherever
you
are
in
this
file
on
this
node
and
other
things
like
that.
So
the
translation
process
that
babel
eslint
and
typescript
eslent
and
the
processors
do
now.
C
We
might
be
able
to
do
even
better
than
that,
and
not
even
just
for
javascript
and
languages
that
compile
to
javascript.
So,
for
example,
you
might
be
able
to
do
it
with
json.
You
could
perhaps
pass
in
a
json
ast
if
you
had
the
right,
parser
and
parser
support
and
look
for
things
in
your
package.json
or
another
json
configuration
file
or
yaml.
If
you
want
to
lint
a
docker
compose
file,
that's
something
that
we
could
do
or,
as
the
question
asks,
html
yeah.
C
B
Yeah,
that's
definitely
exciting.
I
do
think
that
that's
that's
something.
That's
been
discussed
a
long
time
within
the
team
and
and
outside,
and
I
do
think
that
that
would
that
could
be
a
really
big
win
for
the
community
as
a
whole,
because
I've
looked
for
linters
for
other
other
languages
that
I
you
know
use
as
a
web
developer
day
to
day
and
generally
have
found
them
to
not
be
as
configurable
or
you
know
not
not
quite
as
robust
and
so
yeah
having
one
tool
to.
C
C
One
of
the
things
we
also
wanted
to
talk
about
was
just
what's
new
in
some
of
the
latest
releases.
Oh
yeah,.
B
Do
you
want
to
take
that
one
yeah
sure,
let's
see
so,
we
did
a
release
this
week
that
I
guess
the
the
most
exciting
part
about
it
is
adding
support
for
es
for
some
syntax
for
es2021
and
that
is,
namely
numeric,
separators
and
logical
assignment
operators,
so
that
as
of
7.8.1,
because
we
had
to
release
a
patch
release,
it
is
available
to
everyone.
Please
check
it
out
and
let
us
know
if
you
find
any
issues
with
it.
So
anything
else,
that's
been
really
exciting.
Recently,.
C
One
of
the
great
things
about
having
kai
as
a
dedicated
maintainer
is
that
we
have
a
default
person
to
do
the
releases
rather
than
trying
to
figure
out
who
else
on
the
team
can
find
time
at
a
specific
on
their
schedule
for
it.
So
it's
been
great
having
kai
around
to
do
that.
Among
many
other
things,
thanks.
B
Cool,
so
here's
another
question
which
is
miles
asks:
what
is
the
most
controversial
linting
rule?
This
is
an
easy
answer
for
me,
that
is
the
indent
rule.
B
It
is
so
we
get
so
many
issues
for
it
that
we
actually
have
a
label
just
for
that
rule
on
github
issues,
and
that
is
because
you
know
indentation
people
have
a
lot
of
opinions
about
that
and
a
lot
of
ideas
about
what
how
how
that
should
be
enforced,
and
at
this
point
in
this
intent
rule,
is
so
massive
that
we,
though
we
would
like
to
accommodate
everyone.
B
We
we
generally
don't
make
changes
to
it
because
there,
if
you
look
at
the
the
documentation,
page
and
configuration
information,
there
are
so
many
so
many
different
ways
to
configure
it
yeah.
That's
that's
my.
C
My
pick
for
most
controversial,
I
have
to
agree
when
I
saw
that
question
come
in.
It
was
okay,
so
it's
obviously
going
to
be
a
stylistic
rule
which
one
I
can't
think
of
anything.
That's
more
controversial
than
indent,
and
it's
there
are
like
I
said
earlier.
People
are
endlessly
creative
and
how
they
want
to
format
their
code
and
there's
only
so
many
different
cohesive
ways.
We
could
come
up
with
a
configuration,
that's
even
internally,
consistent
for
what
people
might
want
to
do
that
rule.
C
B
C
So
we
should
probably
talk
about
getting
started
as
well.
Yes,
so
our
getting
started
docs
are
linked
on
the
website
and
step
one
install
eslint
npm
install,
and
then
we
also
have
an
init
tool.
So
you
don't
have
to
set
up
a
configuration
for
yourself.
Initially,
you
can
run
npx
eslint
dash
dash
in
it
and
that
will
walk
you
through
a
wizard
of
sorts
on
the
terminal.
That
will
ask
you
some
questions
about
your
code
and
help.
C
You
get
started
with
that,
and
then
there
are
all
sorts
of
different
tutorials
and
guides
for
whatever
scenario
that
you
might
have.
That's
not
the
standard,
plain
javascript
that
we
can
address
in
our
getting
started.
If
you
have
react
code,
for
example,
there
are
all
sorts
of
guides
for
react.
I
think
in
fact
create
react.
App
includes
eslint
now.
C
There
there
are
all
sorts
of
of
different
configurations
that
you
could
come
up
with.
That
would
have
their
own.
How
do
you
get
this
setup
if
you're
using
typescript,
for
example,
the
typescript
eslint
getting
started,
is
probably
the
way
to
go
for
that
and
when
you're
getting
started
when
you've
moved
beyond
just
eslint
init?
When
you
want
to
start
customizing
things,
I
I
think
it
helps
to
start
with
a
lot
of
the
plugins
have
recommended
configurations.
So
we
have
our
own
eslint
recommended.
B
I
guess
just
to
add
to
that
one
question
that
I've
seen
come
up
fairly
regularly
over
the
years.
Is
you
know?
Why
does
eslint
not
have
a
default
configuration?
Why
can't
you
just
install
eslint
and
then
it
just
it
just
works,
which
is
a
really
fair
question,
because
configuration
is
always
difficult
and
especially,
if
you're,
you
know
less
familiar
with
javascript,
you
might
not
actually
even
know
like
what
the
answers
to
some
of
these
questions
are
like
what
environment
things
are
running.
Things
like
that,
and
the
answer
is
twofold.
B
One
is
that,
like
I
said
earlier,
we
don't
want
to
be
in
the
business
of
telling
people
how
to
write
code.
We
want
just
to
give
them
a
tool
to
allow
them
to
to
enforce
writing
the
the
writing,
the
kind
of
code
that
they
want
to
write
and
the
other
one
is
actually
just
an
inherent
difficulty
in
javascript
itself,
which
is
that
javascript
in
in
javascript
a
lot
of
times.
We
don't
have
control
over
the
execution
environment.
If
you're
running
a
node,
then
you
do.
B
But
if
it's
running
in
the
browser,
you
really
have
no
idea.
B
You
have
to
make
your
best
guess
as
to
what
your
users
are
using
and
the
the
environment
that's
running
in
and
therefore
like
what
syntax
is
supported
and
so
on
and
so
forth,
and
so
it's
actually
a
problem
where
we,
it
would
be
great
if
we
as
a
community,
I
think,
came
up
with
a
solution
that
says
like
here
are.
B
My
here
are
my
targets
and
then
every
all
the
tools,
you
know
read
that
and
then
we're
able
to
configure
themselves
accordingly,
but
without
that
we
have
to
leave
it
up
to
the
user,
because
we
don't
want
to
make
any
guesses
and
be
wrong
about
that.
C
Yeah
the
trade-off
there
is,
should
we
by
default,
allow
the
new
es2021
syntax,
or
should
we
by
default,
say
well,
if
you're
targeting
this
older
version
of
edge
or
safari,
you
aren't
able
to
use
these
things,
so
will
would
we
default
everybody
to
like
ie
11
support?
I
don't
think
that
would
be
a
popular
choice
and-
and
so
kai
is
exactly
right-
that
we,
we
don't
want
to
put
ourselves
in
a
position
of
declaring
here's
what's
default
normal,
because
there's
there's
very
little
agreement
on
what
that
even
might
be.
C
But
there
are
some
tools
around
that
there's
a
tool
called
eslint
nibble
that
will
help
you
add
eslint
to
an
existing
project
where
it
will
say,
hey.
You
have
a
bunch
of
errors
on
this
rule.
Do
you
want
to
just
disable
it
for
right
now
and
you
can
come
back
later
say
it's
a
formatting
rule.
That's
just
not
important
to
have
day
one
versus
some
of
the
other
rules
that
might
might
actually
be
reporting
hey.
This
will
be
a
runtime
exception.
C
B
Yeah,
so
we're
we're
running
out
of
time,
but
I
did
want
to
touch
on.
We
went
over
getting
started
as
a
user
of
eslint,
but
there's
the
other
side
of
getting
started
as
a
contributor
to
eslint.
B
B
We
one
thing
that
eslint,
I
think
does
really
well
is,
as
for
an
open
source
project,
at
least
is
try
to
document
everything
we
do
and
and
make
sure
that
expectations
are
clear
on
both
sides,
and
this
is
actually
one
of
the
reasons
why
I
started
contributing
to
eslint,
as
as
someone
new
to
open
source
and
a
fairly
new
developer
at
that
time,
it
was
it
built
a
lot
of
trust,
knowing
what
the
team
would
expect
of
me.
The
maintainers
would
expected
me
and
what
I
could
expect
of
the
maintainers.
B
We
don't
have
a
ton
of
time
to
go
through
it.
So
I
won't
go
through
it,
but
I
am
always
available
on
twitter
on
github
to
help
people
contribute.
We
also
have
a
discord.
B
Which
I
believe
the
link
to
that
as
eslint.org
chat,
to
be
to
ask
for
an
invitation
or
to
the
exact,
remember
how
that
works,
but
to
be
added
to
that,
and
we
would
really
love
to
see
you
on
github
open
source
projects
like
eslint
only
thrive
when,
when
there's
an
active
community
around
it
and
yeah,
we
would
we
would
love
to
help
you
get
your
first
prn
get
your
30th
pr
in.
Please
please
come
join
us.
C
C
For
example,
if
you
are
new
to
using
eslint
one
of
the
best
things
that
you
can
do
is
say,
hey
this
didn't
make
sense
as
I
was
getting
started
and
that's
whether
that's
as
a
user,
as
maybe
some
of
the
rule,
documentation
isn't
clear
or
maybe
an
even
worse
hike
is
incorrect,
and
you
discover
that
please
send
a
pull
request
that
would
be
wonderful
or
as
a
developer,
you
find
some
maybe
api
docs
that
could
be
improved.
Please
send
a
pull
request,
that's
a
great
way
to
do
it.
C
Another
way
is
sitting
in
the
issue
tracker
and
seeing
what
people
are
talking
about,
and
we
have
some
first
good
first
issue
labels
that
you
might
find
and
on
all
of
those.
If
you
say
hey
I'd
like
to
work
on
this,
you
can
claim
that
and
then
ask
any
questions
from
the
team
and
and
we'll
try
to
help
you
out
with
that.
C
To
point
you
in
the
right
direction
or
another
good
way
is
to
look
at
a
pull
request,
especially
from
somebody
who's
been
around
the
project.
A
while
and
just
ask
why
questions
I
really
like
when
people
ask
why,
on
code
that
I've
written,
because
it's
a
chance
to
confirm
context
or
even
more
frequently
as
I'm,
writing
out,
here's
why
I
did
it
this
way.
C
There
are
another
great
way
and
then,
through
osmosis
of
sorts,
you'll
start
to
become
more
familiar
with
the
code
base
and
where
things
are
and
the
way
things
work
for
eslint,
specifically,
the
core
apis
touch
a
lot
of
things,
but
the
rules
are
at
the
top
level
of
the
stack
and
nothing
else
calls
the
rules.
C
So
you
don't
have
to
worry
about
other
about
a
ton
of
additional
context,
and
so,
if
you
wanted
to
start
by
just
writing
some
rules,
you
don't
even
have
to
do
it
in
core.
If
you
have
a
project-
and
you
say
hey,
I
wish
I
had
a
rule
that
did
this
build
a
rule
and
the
apis
around
what
rules
can
do
are
probably
among
our
most
thoroughly
documented,
and
we
also
have
hundreds
of
examples
of
rules
in
core.
So
you
could
find
something.
That's
similar
and
there's
hundreds
of
examples
of
rules
in
plug-ins.
C
So
if
you
don't
see
something
similar
in
core
there's-
probably
an
example
of
something
related
elsewhere
that
you
could
start
from,
and
that
is
a
great
way
to
get
familiar
with
the
way
eslint
works
with
syntax
trees
and
reports,
warnings
and
all
of
that,
so
that's
a
great
way
to
get
started
contributing
as
well
and,
like
I
said
we
would
love
to
help
you
there's
a
developer's
channel
in
chat
specifically
for
people
working
on
rules
and
plugins
and
on
the
project
itself.
C
I
would
love
to
help
you
get
working
on
that
for
sure.
B
Yeah
awesome:
well,
I
think,
we're
out
of
time
rachel
did
you
have
any
any
last
minute
things
you
wanted
to
cover.
A
Nope,
thank
you
so
much
both
for
for
doing
this
ama,
and
we
really
appreciate
your
time
and
thanks
for.