# TypeScript ESLint Documentation
# Source: https://raw.githubusercontent.com/typescript-eslint/typescript-eslint/main/docs/contributing/Local_Development.mdx
# Path: docs/contributing/Local_Development.mdx

---
id: local-development
title: Local Development
---

Thank you for your interest in developing on typescript-eslint! ❤️‍🔥

> See [Contributing](../Contributing.mdx) and [Issues](./Issues.mdx) for details on our general contribution flows.

## Setup

After [forking the repo from GitHub](https://help.github.com/articles/fork-a-repo) and [installing Yarn](https://yarnpkg.com):

```shell
git clone https://github.com/<your-name-here>/typescript-eslint
cd typescript-eslint
yarn
```

You can see which version of `yarn` we use by checking the `packageManager` field in the root `package.json`.

Postinstall scripts will then fully build your repository locally with (`yarn build`).
At this point, you're ready to develop! 🚀

## Builds

You can run `yarn build` in the root to build all packages, or in any package to build just that package.

Keep in mind that packages generally depend on each other's built outputs, and you'll need to `yarn build` dependents for their consumers to receive any new local changes.
For example, if you make a change within `scope-manager` and want to use it in `eslint-plugin`, you'll need to `yarn build` either from the root or within `packages/scope-manager`.

## Validating Changes

The following checks are all run on pull requests automatically.
You can also perform them locally.

> See [Contributing > Pull Requests](./Pull_Requests.mdx) for more information on pull requests.

### Formatting

We use [Prettier](https://prettier.io) to auto-format code.
A Git pre-commit hook should apply it to all committed changes.
Alternately, you can run `yarn format` in any package or in the root.

### Linting

All code changes must pass ESLint.
You can run `yarn lint` in any package or in the root.

### Proofreading

Changes must pass two linters for documentation and naming, the commands for which may be run from the root:

- `yarn check-spelling`: [CSpell](https://cspell.org), for all code
- `yarn lint-markdown`: [Markdownlint](https://github.com/DavidAnson/markdownlint), for Markdown documentation

### Tests

All code changes should ideally be unit tested if possible.
You can run `yarn test` in any package to run its tests.

Oftentimes, you will only want to run one specific test related to the bug you are fixing or the feature you are implementing. To do this, you can add `only: true` to the test object definition. (Doing this will cause a new lint error for `eslint-plugin/no-only-tests`, but just ignore it while you work. The lint rule is only there so that you remember to delete the `only: true` once it comes time to make a pull request.)

> The repository has [Visual Studio Code launch tasks](https://code.visualstudio.com/docs/editor/tasks) that allow for [visually debugging tests](https://code.visualstudio.com/docs/editor/debugging).

### Type Checking

All code should pass TypeScript type checking.
You can run `yarn typecheck` in any package or in the root to run `tsc`.

> Run `yarn typecheck -w` to start `tsc` in watch mode.

## Rule Development

Some portions of this repository are generated by manually running scripts that read from rule files.
If you modify rules, you may need to run either or both of:

- `yarn generate-configs` from root: to regenerate [shared configs](../users/Shared_Configurations.mdx)
- `yarn test docs -u` from `packages/eslint-plugin`: to regenerate snapshots based on rule docs and options

## Website Development

Our interactive documentation website is built with [Docusaurus](https://docusaurus.io).
Running `yarn start` from either the root or `packages/website` will start a local dev server on `localhost:3000`.

> The `website` package relies on other packages being built.
> We recommend running `yarn build` from the root before `yarn start`.