I think for your second point, it would be great to have an example of ESLint rules for typescript, written in typescript. Happy to help out with this however is most helpful.

To me it seems like the most important things for this are:

1. Documenting the types exposed by the parser, and how to access these in a type-safe way. At https://github.com/bradzacher/eslint-plugin-typescript/issues/278, its mentioned that this is done with context.parserServices.esTreeNodeToTSNodeMap.get(node) - but I can't see any esTreeNodeToTSNodeMap key in the parserServices map when running locally - perhaps I'm missing something here?

2. A replacement (or improvement to) tsutils which supports ESTree types - previously TSLint rules have been able to use these typeguards (for example isLiteralType) - and I think that if people were to be writing ESLint rules using typescript - whether or not theyre running against typescript - these typeguards would still be possible.

I realise all these projects are still in their infancy - but certainly interested in learning more and helping out.

The parserServices are currently waiting on #37.

@johnwiseheart Regarding the esTreeNodeToTSNodeMap, assuming you're using a version of the parser that includes #37, the map is only provided when semantic rules are enabled, i.e. a tsconfig.json is provided in the config. I can certainly see moving that map to always be provided, but at least as a first cut the intent was to limit any perf impact the changes might cause for existing scenarios.

Ahh sweet, will give it a try now that #37 has been merged. How do you folks feel about the typeguard note - would that be something you think should live in this monorepo too, or better off just being an external thing? Understand if you're more concerned about writing rules for typescript rather than in typescript. Can also make a separate issue to track this if you think that makes sense.

I think providing guidance in the repo for writing custom rules is definitely desired 👍

So how does one configure .eslintrc in order to lint *.ts files using this project?

@qwelias simplest use case will be: https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin#usage

// .eslintrc
{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"]
}

and from cli you have to run:

eslint --ext .ts src

Things I'd probably like to see in our documentation:
what rules lint what language features.

I.e. if I'm a user looking to lint the non-null operator, which rules can I look to?

This sort of documentation would make it easier for us to organise our rules, as we can look to rolling settings into rules based on related lint behaviour instead of based on language features.

As an example: #202 relates to the non-null operator.
Does that mean it should be grouped into a renamed rule with existing no-non-null-assertion? Or because it relates to type casting, does it belong in the existing rule no-object-literal-type-assertion?

If we had documentation saying "non-null operator linting is touched on in these rules X, Y Z", then we could go either way without worrying too much about it.

Hi, fascinating project. I'm mostly in (2)... Is the idea to replace tslint completely? Because with a simple minimal configuration (below) tslint and prettier fight back and forth about double vs single quotes...

.eslint.json:

{
  "extends": [
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended"
  ],
  "rules": {
    "@typescript-eslint/indent": ["error", 2]
  }
}

tslint.json:

{
  "extends": [
    "tslint:latest",
    "tslint-angular"
  ],
  "rules": {
    "directive-selector": [true, "attribute", "foo", "camelCase"],
    "component-selector": [true, "element", "foo", "kebab-case"]
  }
}

yes, the idea is to replace tslint completely. have a look at our ROADMAP for alternates to tslint rules that you can use.

There's also our @typescript-eslint/eslint-plugin-tslint which you can use to help migrate yourself.

Make sure you configure prettier if you want it to set a specific quote style.

Thanks @bradzacher , I'm much smarter now. For anyone reading, my new .eslint.json:

{
  "extends": [
    "airbnb-base",
    "plugin:@typescript-eslint/recommended",
    "plugin:import/recommended",
    "plugin:import/typescript",
    "plugin:prettier/recommended"
  ],
  "rules": {
    "quotes": [
      "error",
      "single",
      { "avoidEscape": true, "allowTemplateLiterals": false }
    ],
    "@typescript-eslint/indent": ["error", 2]
  },
  "settings": {
    "import/parsers": {
      "@typescript-eslint/parser": [
        ".ts",
        ".tsx"
      ]
    }
  }
}

tslint.json is empty, and .prettierrc sets "singleQuote": true. No conflicting rules, excited to be using it!

I try to setup eslint for Typescript for one project. This project uses webpack with a webpack.config.js, having the line

const HtmlWebpackPlugin = require('html-webpack-plugin');

Running eslint --ext .ts,.js . gives me the error:

Require statement not part of import statement  @typescript-eslint/no-var-requires

AFIK I can not change this in the file a import.

Is there an way to set a eslint config to work with Typescript and JavaScript or do I need two config files and lint them separately?

@StefanSchoof you can either disable the rule for that file with a disable comment, or you can use eslint overrides to control the rules for the different types of files in your project.

Do you plan sharing some info about using Webpack and eslint-loader? I've setup my eslintrc file according to the docs and have this error

Module build failed (from ../node_modules/eslint-loader/index.js):
Error: Failed to load plugin @typescript-eslint: Cannot find module 'eslint-plugin-@typescript-eslint'

I assume this is not the place to get help with this issue but in general it'd be helpful to have some note for Webpack users, quite a large crowd. Also not sure where to open a separate issue, wether in this repo or in eslint-loader. Any guidance will be much appreciated.

UPDATE: looks like an issue with my version of eslint (e.g. PLUGIN_NAME_PREFIX), still question holds regarding Webpack

it's not an issue with webpack, scoped plugins in eslint are supported since version 5

and if you are using >=5.0.0 you can simply setup this like this: (tested and its working)

      {
        test: /\.(js|ts)$/,
        loader: 'eslint-loader',
        enforce: 'pre',
        include: [path.resolve('./src')]
      },

Thanks.

I ended up with:

module.exports = {
    "parser": "@typescript-eslint/parser",
    "plugins": ["@typescript-eslint"],
    "extends": ["plugin:@typescript-eslint/recommended"],
    "rules": {
        "@typescript-eslint/no-explicit-any": "off"
    },
    "overrides": [
        {
            "files": "*.js",
            "rules": {
                "@typescript-eslint/no-var-requires": "off"}
        }
    ]
};

I other thing, that take me some time, where the missing lightbulbs in vs code, see microsoft/vscode-eslint#609

If anyone is wondering why the ESLint VSCode plugin auto-fix doesn't work, you're missing this setting:

"eslint.validate": [
    "javascript",
    { "language": "typescript", "autoFix": true }
  ],

It basically tells the plugin that ESLint also works for typescript files.

Hi. I am looking into getting started with Typescript, and currently use the ESLint pluign in vscode and airbnb rules modified to work with Prettier (I manually removed rules that the supplied CLI util said were conflicting)

Right now I would say that the state of documentation for how to get going with linting typescript using ESLint with Prettier and a supplied set of rules is awful. All the applications are fragmented and in a total state of flux. I would say that most developers wanting to switch to typescript would be VERY likely to:

a. being using vscode
b. using the vscode ESLint plugin
c. already using prettier
d. using a supplied ruleset such as airbnb

I know this is not everyone, but if it were me I would have no idea where to start. Having to plough through endless out of date blog articles is a waste of time and effort.

As a normal user I would first go to the eslint home page:

https://eslint.org/

no mention of typescript there, so I use the search and this is the only thing that turns up:

https://eslint.org/blog/2019/01/future-typescript-eslint#the-future-of-typescript-on-eslint

OK, so I learn that typescript support is new and is going to get better. I click the link to the main home of TypeScript linting:

https://github.com/typescript-eslint/typescript-eslint

What do I do? How do I make it work with VS Code? How do I add my ESlint rules? How do I make it work with Prettier?

May I propose you guys contact the ESLint people and first get their web page changed from:

ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. Its goal is to provide a pluggable linting utility for JavaScript.

to

ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. Its goal is to provide a pluggable linting utility for JavaScript and TypeScript.

and make the word TypeScript be a link to this Github.

Now write some docs explaining in easy to understand language how to achive the a, b, c and d points listed above in the .README docs. All the info hidden in this thread needs to be on the front page. Cheers!

You shouldn’t need to modify the Airbnb config. eslint-config-prettier will override it to disable the relevant rules. Just make sure prettier is at the end of your extends list.

@David-Else - we work very closely with the eslint team. That being said, we aren't affiliated with them as an "org".
Note that we took ownership of typescript-eslint-parser from them for a number of reasons, one of which being that they didn't have the time (or want) to maintain something outside the scope of the core eslint project.
Typescript is not the business of eslint core, and whilst amending their docs to say it is might help people, it's not up to them to do so; it's up to us to make it easier to find us.

At the time of writing, googling for typescript eslint returns our repo as the second link, and googling for eslint typescript returns us as the fifth. As more people click the links, SEO will improve.

Documentation is on our todo list. But we are but a few devs doing this in what free time we can find around our work and life. A large portion of the open source time I specifically allocate myself is just triaging issues + reviewing prs (so much so my other projects have fallen into disrepair).

Be the change you want to see - if you think the documentation on here is awful, we are 100% open to PRs improving it.
We have no clear idea right now how we want documentation to look, or how we want it to be structured; just a number of ideas documented here and in threads like this one, #40, #63 and #168.

If that's not something you're interested in, that's perfectly acceptable - we'll get around to it when we have time.
If you had to jump through some hoops to add it to your project, open an issue and let us know, so we know what to document.

@bradzacher I hope I didn't come off as negative, I was just trying to give the point of view of a total new comer to TypeScript and show the issues I am finding in the user journey.

I did not know that this project was all volunteer, I assumed that as TypeScript is created and actively promoted by MicroSoft they would be volunteering some manpower into such an important project. Maybe they can be persuaded? They spend a lot of resources promoting TypeScript, they have a huge vested interest in this working well.

Unfortunately I am a total beginner at TypeScript and was only just Googling about seeing how to set it up! When I get up and running I will be in a much better position to contribute, and would love to help. I think linting is very important for code quality, and that is very important for everyone.

I am sure the SEO will continue to go well. If I can help in the future I will, and thanks for all the time you and the other devs have put into this!

Sorry, I wasn't trying to have a go. Probably came off a bit strong, sorry.

Was just highlighting that we're happy to have as many contributors as we can, for code and for documentation.
For me at least it's much easier to spend 15-30 mins reviewing a pr than it is to spend 3+hrs coding a feature/writing the docs :)

There are a number of Microsoft folks pitching in; you'll see them submitting PRs to add missing tslint rules and helping with the parser layer, but AFAIK there's no "concentrated" effort.

We're still a new repo, it was only about 2 months ago that we merged the 4 projects together. We'll get there eventually :)

I found some mentions about extends in overrides. Just information; I believe that ESLint 6 will support extends in overrides. It has been implemented in this huge rewrite and will be exposed in eslint/eslint#11554.

Kind of frustrating getting Prettier running with an airbnb config at the moment. You will have to read through eslint-config-prettier to come to the conclusion that a lot of autofixes and most of formatting is not supported. Single Quotes, Multi spaces, Max-Lines all sort of "most beneficial" auto formatting rules will not work.

Maybe this lib is ready for daily usage, but defenitly not for an easy kickstart..

EDIT

Got somewhere acceptable with this:

module.exports = {
  extends: [
    "airbnb-base",
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended",
    "prettier/@typescript-eslint"
  ],
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint"],
  parserOptions: {
    project: "./tsconfig.json"
  },
  settings: {
    "import/resolver": {
      node: {
        extensions: [".js", ".jsx", ".ts", ".tsx", ".d.ts"]
      }
    }
  },
  rules: {
    "prettier/prettier": ["error", { singleQuote: true }],
    quotes: [
      "error",
      "single",
      { avoidEscape: true, allowTemplateLiterals: false }
    ]
  }
};

Last thing I would like to adjust ist the "new-line-on-chaining-methods" to allow 3 method calls to be inline.

@NikoMontana
We do know that the experience with airbnb is subpar, but the experience with prettier should be fine?

Using eslint-config-prettier will disable every single rule that is covered by prettier's formatting.
This is done on purpose, because otherwise prettier would format your code, and then eslint would complain that the formatted code is wrong.

Of you want to instead use the style imposed by eslint, you can either:

• change your format command to instead be something like prettier --write && eslint --fix
• Use a tool like prettier-eslint instead of just prettier

I would hazard against the second one for now, as their library is broken and won't work with this plugin out of the box; it requires some manual patching (see the PRs on their repo for more info).

On many of my projects I've had it working perfectly by doing the first option. It also works fine in vscode if you use the prettier extension for formatting and then turn on the eslint extension's autlfix on save.

Could you please expand upon what was frustrating about the setup experience? I'm not quite sure I understand your frustrations with this plugin or its interaction with other config.

@bradzacher Thank you for the explaination, this was a step further for understanding all things combined. My codebase looks like this now:

.eslintrc.js

module.exports = {
  extends: [
    "airbnb-base",
    "plugin:@typescript-eslint/recommended",
    "plugin:prettier/recommended",
    "prettier/@typescript-eslint"
  ],
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint"],
  parserOptions: {
    project: "./tsconfig.json"
  },
  settings: {
    "import/resolver": {
      node: {
        extensions: [".js", ".jsx", ".ts", ".tsx", ".d.ts"]
      }
    }
  },
  rules: {
    "prettier/prettier": ["error", { singleQuote: true }],
    quotes: [
      "error",
      "single",
      { avoidEscape: true, allowTemplateLiterals: false }
    ]
  }
};

.vscode/settings.json

{
  "eslint.enable": true,
  "eslint.validate": [
    { "language": "javascript", "autoFix": true },
    { "language": "javascriptreact", "autoFix": true },
    { "language": "typescript", "autoFix": true },
    { "language": "typescriptreact", "autoFix": true }
  ],
  "eslint.run": "onType",
  "eslint.packageManager": "npm",
  "eslint.alwaysShowStatus": true,
  "eslint.autoFixOnSave": true,
}

package.json

  "devDependencies": {
    "@types/node": "^12.0.0",
    "@typescript-eslint/eslint-plugin": "^1.8.0",
    "@typescript-eslint/parser": "^1.8.0",
    "eslint": "^5.3.0",
    "eslint-config-airbnb-base": "^13.1.0",
    "eslint-config-prettier": "^4.2.0",   // Still confused if I am using this or not..
    "eslint-plugin-import": "^2.17.2",
    "ts-node": "^8.1.0",
    "typescript": "^3.4.5"
  }

And this works for me like expected! Besides the formatting of the method chaining - but for now I can live with that. This config seems to trigger the whole formating process twice though, because by saving the changes, the code will jump into false formating and jump right back.

Sure, I will give my best to explain what I didnt understand - still dont understand.

• Figured out that I have to use eslint-plugin
• Extended with "airbnb-base" & "plugin:@typescript-eslint/recommended"

At this point the linting worked very well and like expected. Last but not least I wanted to format on save by the given linting rules with prettier. So I read the Note, installed eslint-config-prettier and did this:

{
  "extends": [
    "airbnb-base"
    "plugin:@typescript-eslint/recommended",
    "prettier", // after removing this it started formating 
    "prettier/@typescript-eslint"
  ]
}

This config formated the code but in a unsatisfying way (ofc opinionated) because there was no "universal" style. For example I could line-break method chains like I wanted without triggering the formatter. One line could have 3 line breaks and the next one could be single lined.

So I created an issue. Because I was so dumb that I didnt understood that "prettier" in the extends section will overwrite ALL rules - my fault!

So finally I got here and tried this configuration where I realized that "plugin:prettier/recommended" was missing. Now I have the desired formating rules, but feel I cannot change some props like already mentioned - method chaining line breaks.

Hope that helps you!

This config seems to trigger the whole formating process twice though, because by saving the changes, the code will jump into false formating and jump right back.

Yeah I know it sucks, not much you can do about it for now. The vscode prettier extension has prettier-eslint integration, but because the base prettier-eslint package is broken right now, that integration is broken too (see prettier/prettier-eslint#197).

Turning on eslint's autofixer in the extension is a hacky compromise for now.

There are configuration options for prettier btw
They don't have many options (on purpose, to keep things simple), but you can tweak the line length, and quote types and things like that. But prettier still has its own rules for some things (it won't break a comment automatically, certain statements won't be broken to adhere to the max line length, it'll prefer " ' " over ' \' ', etc).

The only downside to prettier is that it's entirely opinionated. For me I've found it took a bit of getting used to (I used to work at a startup where I had complete control over the code style, now I work at facebook where prettier is on by default, and enforced). Once I let go and accepted I couldn't control it, I found that it wasn't that bad, and the time and effort it saves you in formatting is actually amazing. In addition that is the fact that it is pretty strict, so everyone's code looks the same, meaning you spend less (or usually zero) time nitpicking formatting choices.
I now love it so much so that I've added it to every project I work on, and actually get annoyed when I work on a project that doesn't use it.

Awesome, so it looks like in the end, it wasn't a problem with the config of this project, but the config of the eslint ecosystem as a whole.
I understand that it can be a bit rocky to get used to, and esp when using extends as it can be difficult to reason about exactly what rules are turned on. The ESLint team is working on improving the config situation, but it's a big breaking change, so it'll be a little while before that is ready and released.

Do you think there's anything we could have documented better within this project?

@JamesHenry @bradzacher I want to contribute to the project so where should I start?

@moulikcipherX - this is a decent filter for the list of issues that need working on

I've generally been pretty quick with handling bugs, so the vast majority are enhancements.

It would probably be better to start with an issue tagged with enhancement: plugin rule option, so you can get a feel for working with the AST with related example code, and without having to setup all of the boilerplate for a new rule.

@JamesHenry @bradzacher I am currently working as a GSoC Intern in Salesforce and I am creating an eslint-plugin for them. Should I proceed with the existing Creating ESlInt Plugin method?

@moulikcipherX It depends.
Do you want to use typescript to write the plugin?
Do they write typescript at salesforce? (i.e. will you need our parser?)

If the answer is no to both of those questions, then sure, follow the article you linked. You don't need the tooling we've created.

If the answer is yes to either (or both) of those questions, then you can create a new plugin as easy as this (I should probably write some docs for this).

1. Add a LICENCE file https://choosealicense.com/
2. Add a README.md with some content
3. Create a package.json as per below.
4. yarn add -D eslint typescript
5. yarn add @typescript-eslint/experimental-utils
6. add a tsconfig.json as per below.
7. create src/index.ts as per below.
8. create src/util/index.ts as per below.
9. create src/rules/index.ts as per below.
10. create src/rules/your-rule-here.ts as per below.
11. create docs/rules/your-rule-here.md documenting your rule.

{
  "name": "eslint-plugin-whatever or @scope/eslint-plugin or @scope/eslitn-plugin-whatever",
  "description": "A plugin for my company",
  "version": "0.0.1",
  "license": "SAME LICENCE YOU CHOSE FOR YOUR LICENCE FILE",
  "main": "dist/index.js",
  "keywords": [
    "eslint",
    "eslintplugin",
    "eslint-plugin",
    "typescript"
  ],
  "files": [
    "dist",
    "docs",
    "package.json",
    "README.md",
    "LICENSE"
  ],
  "repository": {
    "type": "git",
    "url": "https://github.com/<your-org>/<repo-name>.git"
  },
  "bugs": {
    "url": "https://github.com/<your-org>/<repo-name>/issues"
  },
  "peerDependencies": {
    "@typescript-eslint/parser": "^1.9.0", /// ONLY ADD THIS LINE IF YOUR USERS WILL BE USING TYPESCRIPT
    "eslint": "^5.0.0"
  }
}

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "declaration": false,
    "declarationMap": false,
    "esModuleInterop": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "noImplicitReturns": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "outDir": "./dist",
    "pretty": true,
    "resolveJsonModule": true,
    "sourceMap": true,
    "strict": true,
    "target": "es2017",
    "lib": ["es2017"]
  },
  "include": [
    "src",
    "typings"
  ]
}

import rules from './rules';

export = {
  rules,
}

import yourRuleHere from './your-rule-here';

export = {
  'your-rule-here': yourRuleHere,
}

import { ESLintUtils } from '@typescript-eslint/experimental-utils';

export const createRule = ESLintUtils.RuleCreator(
  name =>
    `https://github.com/<your-org>/<repo-name>/blob/master/docs/rules/${name}.md`,
);

import { createRule } from '../util';

export default createRule({
  name: 'your-rule-here',
  meta: {
    // fill out the rule metadata
  },
  defaultOptions: [
    // fill our your rule's default options here
  ],
  create(context, defaultOptions) {
    // rule implementation here
  },
});

@bradzacher our users use both typescript and javascript.

@bradzacher I think typescript is good to use instead of javascript.

Hello @bradzacher, I have created my plugin as per the instructions so, should I run tsc to build in dist/ folder before publishing.

I am having a problem after I build using tsc and there are js files in every folder.

Have a play with the typescript config so that you get the desired result.
https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

I think the option you’re looking for is outDir.

Hello @bradzacher
I am having a problem while creating my build of my eslint-plugin.

For now, just yarn add -D @types/json-schema

@moulikcipherX @j-f1 Is there a more appropriate place to discuss this? Either in a new issue, or in some other support channel? I don't think this should be the place to discuss general rule creation issues.

I think that this issue has gone off the rails all over the place.
I'm going to lock it to maintainers, as it's only intention is as a tracking issue for improving the documentation - people are coming to this issue because it's pinned.

@moulikcipherX Feel free to open a new issue if you’re still having trouble.

I'm going to close and unpin this.

We are so much further along than we were when I opened this, with 1000s of developers successfully using the documentation we have to use the project effectively.

If there are specific weaknesses/areas for improvement they can be addresses in a more focused way