The solution below achieves:
- Does not lint
*.jsfiles (important in my use case) - Avoids the
tseslint.config()wrapper (I will rarely ever edit the configuration file and don't need the IDE help) - Keeps it clean and simple
eslint.config.js
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';
export default [
eslint.configs.recommended,
...tseslint.configs.strict,
{ ignores: ['**/*.js'] },
{
rules: {
'@typescript-eslint/no-non-null-assertion': 'off',
},
},
];
Videos
The solution below achieves:
- Does not lint
*.jsfiles (important in my use case) - Avoids the
tseslint.config()wrapper (I will rarely ever edit the configuration file and don't need the IDE help) - Keeps it clean and simple
eslint.config.js
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';
export default [
eslint.configs.recommended,
...tseslint.configs.strict,
{ ignores: ['**/*.js'] },
{
rules: {
'@typescript-eslint/no-non-null-assertion': 'off',
},
},
];
See https://typescript-eslint.io/packages/typescript-eslint#config, as linked by https://typescript-eslint.io/getting-started:
export default tseslint.config({
files: ['**/*.ts'],
extends: [
eslint.configs.recommended,
tseslint.configs.strict,
],
rules: {
'@typescript-eslint/no-non-null-assertion': 'off',
},
});
ESLint flat configs apply their configuration objects in order. Each config object applies to all files that are currently being linted unless they override that with a property like files. The way the OP has it introduces >=2 objects:
- All of the
tseslint.configs.strictobjects, which apply to all configured files by default - An object that applies only to
files: ['**/*.ts']
What you actually want is to include { files: ['**/*.ts'] } for all the settings. That's what tseslint.config does for you.
» npm install typescript-eslint
--ext allows using custom javascript extensions, you can't force ESLint to work for languages other than JavaScript by passing a different file extension to it.
You can try using typescript-eslint-parser to enable ESLint for Typescript - it allows building a syntax tree from typescript code that can be passed to ESLint for linting.
But I'd suggest using Typescript linters for inspecting TypeScript code. You can try TSLint, for example.
Update: since 2017.1.3, WebStorm supports ESLint + typescript-eslint-parser; you just need to install both typescript plugin and typescript-eslint-parser and modify your ESLint config accordingly:
"parser": "typescript-eslint-parser",
"plugins": ["typescript"]
Try adding this line into your .eslintrc.json
"plugins": ["typescript"]
In my case, I made eslint format my .vue and my .ts files by using this config :
{
"parser": "vue-eslint-parser",
"parserOptions": {
"parser": "typescript-eslint-parser"
},
"extends": [
"eslint:recommended",
"plugin:vue/recommended",
"typescript"
],
"plugins": ["typescript"]
}
I used to use eslint with the plugins it suggested to me to install after executing :
npx eslint --init;
and chooseing the option : I use typescript , but I have found it to produce some akward linting errors recently like not allowing me to put type any on a function parameter.
I have stopped using eslint since then.
If you use eslint then what you use it for?
I was using it just because it was linting errors while I was writing js and so I believed it will also be useful in typescript.
Yeah we use it and it's really useful. Particularly when combined with Prettier.
I'm guessing that you haven't set it up correctly.
What install guide did you use?
You need some things in you .eslintrc. I think this is the minimum:
"plugins": [
"@typescript-eslint"
],
"parser": "@typescript-eslint/parser",And install the packages:
@typescript-eslint/eslint-plugin
@typescript-eslint/parser"But, after removing typescript-eslint, esLint appears to function normally.
When you say it functions normally do you mean functions in your IDE (like vscode) or when you run the eslint command? Because most IDEs come with eslint either built in or available as a package and will lint your code in-editor (using a typescript parser under the hood). Without typescript-eslint eslint can't actually parse your typescript files. Try running eslint without it and see if it lets you.
My understanding is that tsc compiles TypeScript to JavaScript unless --noEmit tag is added. With options like "strict": true, it's possible to configure TypeScript rules to check.
ESLint and tsc do different things.
- Running
tscwill inform you of type errors, something eslint does not do. - Running
eslintwill inform you of linting errors (violations of defined rules) not type errors, somethingtscdoes not do.
ESLint only reports errors from its own linters, it does not report typescript compilation failures. See: https://stackoverflow.com/a/60758789/14073449
The typescript-eslint page explains why it exists pretty well:https://typescript-eslint.io/
ESLint and TypeScript represent code differently internally. ESLint's default JavaScript parser cannot natively read in TypeScript-specific syntax and its rules don't natively have access to TypeScript's type information.
tsc compiles the project and will detect build errors (as the one in your example). ESLint is used for detecting (bad) patterns.
You want to run ESLint on your code, not on the code that is produced as output of the Typescript compiler, as you suggest. Therefore having typescript-eslint is a good idea, when you write Typescript code, since it provides the capability to 'understand' Typescript to ESLint as stated on their homepage:
The tooling that enables ESLint and Prettier to support TypeScript.