---
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 pnpm](https://pnpm.io/):

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

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

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

## Builds

You can run `pnpm run 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 `pnpm run 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 `pnpm run 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 `pnpm run format` in any package or in the root.

### Linting

All code changes must pass ESLint.
You can run `pnpm run 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:

- `pnpm run check-spelling`: [CSpell](https://cspell.org), for all code
- `pnpm run 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 `pnpm run 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 `pnpm run typecheck` in any package or in the root to run `tsc`.

> Run `pnpm run 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:

- `pnpm run generate-configs` from root: to regenerate [shared configs](../users/Shared_Configurations.mdx)
- `pnpm run 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 `pnpm run 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 `pnpm run build` from the root before `pnpm run start`.
