Skip to main content

Local Development

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

See Contributing and Issues for details on our general contribution flows.

Setup​

After forking the repo from GitHub and installing Yarn:

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 for more information on pull requests.

Formatting​

We use Prettier 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, for all code
  • yarn lint-markdown: 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.

VS Code launch tasks tasks are provided that allow visual debugging tests.

Code Coverage​

We aim for 100% code coverage in all PRs when possible, except in the website/ package. Coverage reports are be generated locally whenever yarn test is run.

The codecov bot should also comment on your PR with the percentage, as well as links to the line-by-line coverage of each file touched by your PR.

Granular Unit Tests​

Most tests in most packages are set up as small, self-contained unit tests. We generally prefer that to keep tests and their failure reports granular.

For rule tests we recommend, when reasonable:

  • Including both valid and invalid code changes in most PRs that affect rule behavior
  • Limiting to one error per invalid case

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.

Website Development​

Our interactive documentation website is built with Docusaurus. 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.