Error missing semicolon semi

Working on this. It’s quite the bear. In the meantime, this is my interpretation of the spec, broken down by the productions of ExportDeclaration:

export * FromClause ;

Semicolon belongs to ExportDeclaration.

export ExportClause FromClause ;

Semicolon belongs to ExportDeclaration.

export { foo } from 'foo';

export ExportClause ;

Semicolon belongs to ExportDeclaration.

export VariableStatement

Semicolon belongs to VariableStatement.

export Declaration

Declaration : HoistableDeclaration

No semicolon.

export function foo () { }
export function* foo () { }

Declaration : ClassDeclaration

No semicolon.

Declaration : LexicalDeclaration

Semicolon belongs to LexicalDeclaration.

export let foo;
export const foo = 42;

export default HoistableDeclaration

No semicolon.

export default function () { }
export default function* foo() { }

export default ClassDeclaration

No semicolon.

export default AssignmentExpression ;

Semicolon belongs to ExportDeclaration.

export default foo || bar;
export default (foo) => foo.bar();
export default foo = 42;
export default foo += 42;

tl;dr:

• ExportAllDeclaration may have a semicolon.
• ExportNamedDeclaration whose declaration is null may have a semicolon.
• ExportNamedDeclaration with a child declaration does not have a semicolon, though its child may.
• ExportDefaultDeclaration may have a semicolon only if its declaration is an expression.

(end tl;dr)

I find this interesting, from ESTree:

interface ExportNamedDeclaration <: Node {
    type: "ExportNamedDeclaration";
    declaration: Declaration | null;
    specifiers: [ ExportSpecifier ];
    source: Literal | null;
}

Note: Having declaration populated with non-empty specifiers or non-null source results in an invalid state.

If declaration and (specifiers, source) are mutually exclusive, why are they the same node?

Edit: ExportDefaultDeclaration may have a semicolon if its child is an expression.

Error missing semicolon semi

Require or disallow semicolons instead of ASI

Some problems reported by this rule are automatically fixable by the —fix command line option

JavaScript doesn’t require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:

On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.

In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn’t exist and always include semicolons manually. The rationale is that it’s easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.

However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:

This may look like a return statement that returns an object literal, however, the JavaScript engine will interpret this code as:

Effectively, a semicolon is inserted after the return statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the no-unreachable rule will protect your code from such cases.

On the other side of the argument are those who say that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don’t use semicolons. For example, consider this code:

In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it’s a function). The no-unexpected-multiline rule can protect your code from such cases.

Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a n character always ends a statement (just like a semicolon) unless one of the following is true:

1. The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with . or , .)
2. The line is — or ++ (in which case it will decrement/increment the next token.)
3. It is a for() , while() , do , if() , or else , and there is no <
4. The next line starts with [ , ( , + , * , / , — , , , . , or some other binary operator that can only be found between two tokens in a single expression.

Rule Details

This rule enforces consistent use of semicolons.

Options

This rule has two options, a string option and an object option.

• «always» (default) requires semicolons at the end of statements
• «never» disallows semicolons as the end of statements (except to disambiguate statements beginning with [ , ( , / , + , or — )

Object option (when «always» ):

• «omitLastInOneLineBlock»: true ignores the last semicolon in a block in which its braces (and therefore the content of the block) are in the same line

Object option (when «never» ):

• «beforeStatementContinuationChars»: «any» (default) ignores semicolons (or lacking semicolon) at the end of statements if the next line starts with [ , ( , / , + , or — .
• «beforeStatementContinuationChars»: «always» requires semicolons at the end of statements if the next line starts with [ , ( , / , + , or — .
• «beforeStatementContinuationChars»: «never» disallows semicolons as the end of statements if it doesn’t make ASI hazard even if the next line starts with [ , ( , / , + , or — .

Note: beforeStatementContinuationChars does not apply to class fields because class fields are not statements.

always

Examples of incorrect code for this rule with the default «always» option:

Examples of correct code for this rule with the default «always» option:

never

Examples of incorrect code for this rule with the «never» option:

Examples of correct code for this rule with the «never» option:

omitLastInOneLineBlock

Examples of additional correct code for this rule with the «always», < «omitLastInOneLineBlock»: true >options:

beforeStatementContinuationChars

Examples of additional incorrect code for this rule with the «never», < «beforeStatementContinuationChars»: «always» >options:

Examples of additional incorrect code for this rule with the «never», < «beforeStatementContinuationChars»: «never» >options:

When Not To Use It

If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.

Источник

ESLint: Missing semicolon.(semi) adding multiple semicolons after curly braces #13480

Tell us about your environment

• ESLint Version: 7.4.0
• Node Version: 10.16.3
• npm Version: 6.14.5

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration:

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

What did you expect to happen?

One semi colon to be added at the end of the file (after last curly brace).

What actually happened? Please include the actual, raw output from ESLint.

ESLint rule semi expects semicolon after curly brace:

After executing ESLint fix command, too many semicolons are added at the end of the file:

If unnecessary semicolons are removed, ESLint suggests adding missing semicolons again, so we encounter infinite loop.

Are you willing to submit a pull request to fix this bug?

The text was updated successfully, but these errors were encountered:

Источник

semi reports missing semicolon on export default class #2194

Looks like similar cases were addressed in #2178 and this one was missed.

The text was updated successfully, but these errors were encountered:

Imports/exports have so many variations, it’s crazy. 🙂

I have a problem with export as well.
My problem is the following:

and I get error Missing semicolon semi

if I add the semicolon, returns:

Do you know how fix it?
Thanks,

Working on this. It’s quite the bear. In the meantime, this is my interpretation of the spec, broken down by the productions of ExportDeclaration :

export * FromClause ;

Semicolon belongs to ExportDeclaration .

export ExportClause FromClause ;

Semicolon belongs to ExportDeclaration .

export ExportClause ;

Semicolon belongs to ExportDeclaration .

export VariableStatement

Semicolon belongs to VariableStatement .

export Declaration

Declaration : HoistableDeclaration

Declaration : ClassDeclaration

Declaration : LexicalDeclaration

Semicolon belongs to LexicalDeclaration.

export default HoistableDeclaration

export default ClassDeclaration

export default AssignmentExpression ;

Semicolon belongs to ExportDeclaration.

tl;dr:

• ExportAllDeclaration may have a semicolon.
• ExportNamedDeclaration whose declaration is null may have a semicolon.
• ExportNamedDeclaration with a child declaration does not have a semicolon, though its child may.
• ExportDefaultDeclaration may have a semicolon only if its declaration is an expression.

I find this interesting, from ESTree:

Note: Having declaration populated with non-empty specifiers or non-null source results in an invalid state.

If declaration and ( specifiers , source ) are mutually exclusive, why are they the same node?

Edit: ExportDefaultDeclaration may have a semicolon if its child is an expression.

Источник

semi and no-extra-semi rules are conflicting with each other in TypeScript interfaces (vue-cli app) #11585

Tell us about your environment

• ESLint Version: v5.16.0
• Node Version: v8.15.1
• npm Version: 6.4.1
• typescript Version: 3.4.1

What parser (default, Babel-ESLint, etc.) are you using?
@typescript-eslint/parser

Please show your full configuration:

First of all, I’m not sure if this is correct repository to submit this issue — I’m using eslint in a Vue application with typescript support that was created via vue-cli .

Since this bug happens with bundled eslint rules, I decided to submit it here.

The semi and no-extra-semi rules are seems to be conflicting with each other when eslint tries to run them on TypeScript interfaces.

Running eslint on given interface will trigger both Missing semicolon (semi) and Unnecessary semicolon (no-extra-semi) errors pointing to the same character (4:2).

Also, if you add ‘no-extra-semi’: ‘off’, to the rules config, eslint will add 10 semicolons and trigger Missing semicolon (semi) error.

But if we have some TypeScript class, eslint will run without errors:

In this case eslint will remove ending semicolon and will not produce any errors.

I have demo repository that shows this behaviour — https://github.com/tzurbaev/vue-ts-eslint-semi. This is default Vue app that was created via vue create command.

What did you expect to happen?
Running eslint on the given interface example will remove semicolon just like running on given class example without errors.

What actually happened? Please include the actual, raw output from ESLint.
eslint triggers both semi and no-extra-semi errors pointing to the same position.

Are you willing to submit a pull request to fix this bug?
Not sure how to fix it (and how to debug what package is actually bugged — eslint itself or Vue’s eslint plugin or even something else).

The text was updated successfully, but these errors were encountered:

Источник

About Missing semicolon . #9399

Tell us about your environment

• ESLint Version: 4.8.0
• Node Version: 8.6.0
• npm Version: 5.5.0

What parser (default, Babel-ESLint, etc.) are you using?
esprima

Please show your full configuration:

What did you do? Please include the actual source code causing the issue.

I make a repo to show this issue. You could clone it and install dependencies. Then run npm test you’ll see this:

But there is a semi for sure. And i have tried eslint autofix which will add one more semi there and this error is still there.

Here’s what in code.js:

What did you expect to happen?

What actually happened? Please include the actual, raw output from ESLint.

See screenshot above.

Need some help. Thanks.

The text was updated successfully, but these errors were encountered:

thanks for reporting, I can repro this!

emm. probably it’s related to the parser: esprima , when using the default parser, the error was gone.

Thanks. I have tried espree which works well. 👍
So. what should i deal with this issue? Goes to esprima repo?

This is a tough one. esprima probably won’t fix an issue just because «ESLint doesn’t work»; on the other hand, if we can figure out why esprima isn’t working correctly here and we can prove that the issue is with their parse output, then we could create an issue that they would accept and fix.

One possible way to do this is to parse the code example with both espree and esprima and maybe do a diff of their JSON.stringify ‘d outputs. Maybe somewhere in there, we might see that their output data (such as node or token locations) is different, possibly wrong.

I’m going to close this issue because there’s no change for ESLint, but please feel free to keep using this space to document any findings. I for one will be interested to see what you find!

Источник

 status: finished → Check your code. Linter failed.

 /usr/src/app/babel.config.js
   3:6  error  Strings must use singlequote                               quotes
   9:2  error  Missing semicolon                                          semi
  10:1  error  Too many blank lines at the end of file. Max of 0 allowed  no-multiple-empty-lines

4


0

I am configuring ESLint (as TSLint is soon-to-be-deprecated) to work with my .ts files. I have this very little file:

export default interface Departure {
  line: string;
  direction: string;
  time: Date;
};

in the last time, where semicolon is, ESLint in my VSCode signals two errors: one about missing semicolon eslint(semi) and another one about unnecessary semicolon eslint(no-extra-semi).

Below is my .eslintrc.js:

module.exports = {
    "env": {
        "browser": true,
        "commonjs": true,
        "es6": true,
        "node": true
    },
    "extends": [
        "plugin:@typescript-eslint/recommended",
        "airbnb"
    ],
    "globals": {
        "Atomics": "readonly",
        "SharedArrayBuffer": "readonly"
    },
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 2018
    },
    "plugins": [
        "react",
        "@typescript-eslint"
    ],
    "settings": {
        "import/resolver": {
            "node": {
                "extensions": [".js", ".jsx", ".ts", ".tsx"]
            }
        }
    },
    "rules": {
    }
};

how can I get rid of this bizarre situation? None of the errors should be there.

Cover image from peforce.com

I decided to write this article to sum up a struggle of mine. We’ve started a new project in the company, Prettier was set up, ESLint was set up and at some point, we added Typescript. By the end, Typescript was also set up. CI was linting, commit hooks were also linting, VSCode was fixing the code, and so on (that is what I thought).
At some point I was playing with the project and realized that some files were being warned by my editor but not when running the linter (npm run lint in my case). I got triggered. I have a hard time accepting that something works but I can’t understand unless it is an external tool that I didn’t have to set up myself but that was not the case here.

In this article, I will summarize some understandings that I’ve about integrating all the tools above. The main focus is how to set up Prettier, how to set up ESLint, how to integrate both, and by the end how to add Typescript to it.

Prettier

The first tool I want to explore is Prettier. I would leave it to you to read more about what it is but, in short, it is a code formatter. What does it mean? It means that it will keep your codebase consistent (in terms of coding style). Do you use ;? If yes, it will ensure that all your files have it, for example. I like it for two reasons: we barely have to discuss code formatting and it is easy to onboard new members to the team.

At the time of this writing, Prettier is in version 2.4.1, so keep in mind things might change (especially formatting) in future versions.

How to set up Prettier?

I will consider you have a project set up already so in short, you need to install it:

npm i prettier #--save-dev and --save-exact are recommended

Right now you can start using Prettier. You don’t need any configuration (if you don’t want it). You can run it against your codebase with:

npx prettier .

The . at the end means to run across your whole codebase. You can run for a specific file or pattern if you want.
This command will print the files formatted, nothing special. A more useful command happens when you add --write flag. Instead of printing the formatted code, it will write to the origin file.

Let’s create a file called index.js with the following code:

// index.js
const a = 1

If we run npx prettier index.js, the output will be:

const a = 1;

It automatically adds the ; for us but it is not saved in the file. If we run npx prettier index.js --write though, the file will change and the ; will be added to it.

Cool, that is the simplest setup we can have with Prettier. The default rules are documented on their website and can be customized (a bit). We will take a look into it next but before I want to mention another flag: --check.

The --check flag, npx prettier index.js --check, is useful if you just want to check if a file (or the codebase with .) is Prettier compliant. It is useful for CIs and git hooks, for example, if you just want to warn the user (you can also enable --write in these scenarios).

If we consider the following code again:

// index.js
const a = 1

And run npx prettier index.js --check, we get the following output:

Checking formatting...
[warn] index.js
[warn] Code style issues found in the above file(s). Forgot to run Prettier?

Prettier configuration

You can configure Prettier to some extend. You can do it via the CLI or via a configuration file, which is more adequate. The configuration file could be in a variety of formats so you can choose the one that fits you best.

Add the configuration file to the root of your project (you can have configurations/folder but I would leave it up to you to explore this path) and start adding rules to it:

// .prettierrc
{
  "semi": false
}

With this configuration file and the following code, again, the --check run will succeed:

// index.js
const a = 1

npx prettier index.js --check:

Checking formatting...
All matched files use Prettier code style!

On top of that, you can also extend configuration and set up a few other things. Check their configuration documentation for more details.

ESLint

ESLint has been around for a while. In short, it does a bit more than Prettier as it analyzes your code to find problems (or patterns that you don’t want, like variables that are not used should be removed). Again, I invite you to read ESLint documentation if you want to go deeper into the topic. I like ESLint for the simple reason it helps me to find problems and configure some patterns in the project (it might be useful when onboarding new people). It is extremely extensible as well in case you’re interested.

At the time of this writing, ESLint is in version 7.32.0, so keep in mind things might change (especially formatting) in future versions. Version 8 is in beta at the moment.

How to set up ESLint?

In short, quite similar to Prettier but you need the configuration file. I will consider you have a project set up already so, in short, you need to install it:

npm i eslint #--save-dev is recommended

You need a configuration file. You can create one by yourself or you can run the command below that bootstraps one for you (it can add a lot of presets already):

npx eslint --init

Let’s start with an empty configuration file though, it is enough to run ESLint:

// .eslintrc.js
module.exports = {
};

We can now run it, similar to Prettier:

npx eslint .

One thing to note here: ESLint runs only on .js files (by default).

Let’s consider the same example as before:

// index.js
const a = 1

npx eslint index.js and we get:

1:1  error  Parsing error: The keyword 'const' is reserved
✖ 1 problem (1 error, 0 warnings)

This is simply the issue with a default ESLint configuration. It considers ES5 by default, so const is not allowed yet, and some older setup might make sense to your project but not in general.

We can spend hours configuring ESLint but in general, we get a default from a style guide (AirBnB for example) and apply it to our project. If you use the init command you can do so.

Let’s install Airbnb ESLint configuration, it also requires eslint-plugin-import to be installed (following their documentation) so:

npm i eslint-config-airbnb-base eslint-plugin-import # --save-dev is recommended

Then we extend it in our configuration, so it will look like:

module.exports = {
  extends: [
    'eslint-config-airbnb-base', // or `airbnb-base`, you can omit `eslint-config-`
  ]
};

Running npx eslint index.js again we get:

1:7   error  'a' is assigned a value but never used  no-unused-vars
1:12  error  Missing semicolon                       semi

✖ 2 problems (2 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Cool! Now we get errors defined by the AirBnB guide. We can use the --fix option, which works similar to --write from Prettier, in case we want to fix the errors when possible.

ESLint allows you to extensively configure it if you want. It goes beyond the scope here and I will leave it up to you to explore and play with it: https://eslint.org/docs/user-guide/configuring/

Prettier + ESLint

There are a lot of tutorials online on how to connect both. I want to take a different approach and try to reason about each tool and how they connect.

I will assume that we have the following Prettier configuration:

// .prettierrc
{
  "semi": false
}

I will assume that we have the following ESLint configuration:

// .eslintrc.js
module.exports = {
  extends: [
    'eslint-config-airbnb-base',
  ]
};

I will assume the following script to run both tools:

// index.js
const a = 1

module.exports = { a }

If we run Prettier check, we get:

Checking formatting...
All matched files use Prettier code style!

Cool! If we run ESLint, we get:

1:12  error  Missing semicolon  semi
3:23  error  Missing semicolon  semi

✖ 2 problems (2 errors, 0 warnings)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

Not so cool! Running ESLint with --fix will fix these issues. Now if we run Prettier again we get:

Checking formatting...
[warn] index.js
[warn] Code style issues found in the above file(s). Forgot to run Prettier?

If we run Prettier with --write it will fix but then ESLint will fail again. It will be like this forever. If the goal were just formatting, I would say pick one of the tools and ignore the other, but we want the power of both tools, especially as ESLint is more than just formatting your code.

Prettier provides two packages that integrate with ESLint.

• eslint-config-prettier: turns off rules that might conflict with Prettier.
• eslint-plugin-prettier: adds Prettier rules to ESLint.

Let’s go step by step. First let’s go and install eslint-config-prettier:

npm i eslint-config-prettier # --save-dev recommended

Our new .eslintrc.js will look like:

module.exports = {
  extends: [
    'eslint-config-airbnb-base',
    'eslint-config-prettier',
  ]
};

Considering the file below, again:

const a = 1

module.exports = { a }

It was a valid file for Prettier but invalid for ESLint. Using the new configuration, it becomes valid as the conflicting rule semi has been disabled.
It is fine if we want to ignore the rules from Prettier but in general, we want Prettier rules to override ESLint rules.
In case we delete the Prettier configuration file and use its defaults (which requires ;), running Prettier check will result in:

Checking formatting...
[warn] index.js
[warn] Code style issues found in the above file(s). Forgot to run Prettier?

The file is not valid anymore as it is missing the ; but the ESLint run won’t fail, as the Prettier rules have been disabled when running ESLint.

One important thing to note here: the order used by extends, in the ESLint configuration, matters. If we use the following order we will get an error as AirBnB rules will override Prettier disabled rules when running ESLint:

module.exports = {
  extends: [
    'eslint-config-prettier',
    'eslint-config-airbnb-base',
  ]
};

Running npx eslint index.js:

1:12  error  Missing semicolon  semi
3:23  error  Missing semicolon  semi

✖ 2 problems (2 errors, 0 warnings)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

To mitigate this issue let’s install the plugin:

npm i eslint-plugin-prettier # --save-dev recommended

We can then update our .eslintrc.js file to:

module.exports = {
  extends: [
    'eslint-config-airbnb-base',
    'plugin:prettier/recommended',
  ]
};

We replaced eslint-config-prettier with plugin:prettier/recommended. Check ESLint docs about extending a plugin: https://eslint.org/docs/user-guide/configuring/configuration-files#using-a-configuration-from-a-plugin
I also recommend you to check what eslint-plugin-prettier is doing with our ESLint configuration: https://github.com/prettier/eslint-plugin-prettier/blob/a3d6a2259cbda7b2b4a843b6d641b298f03de5ad/eslint-plugin-prettier.js#L66-L75

Running ESLint again we will get:

1:12  error  Insert `;`  prettier/prettier
3:23  error  Insert `;`  prettier/prettier

✖ 2 problems (2 errors, 0 warnings)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

Two things to note here:

1. We are getting ; errors again, that have been disabled earlier with eslint-config-prettier;
2. The error is coming from the rule prettier/prettier, which is added by the plugin. All prettier validations will be reported as prettier/prettier rules.

Typescript

Let’s start from the very basic: running ESLint against TS files.
Right now, running ESLint against your codebase would be npx eslint .. That is fine until you want to run it against files that are not ending with .js.

Let’s have these two files in our code base:

// index.js
const a = 1

// index.ts
const a = 1

Running npx eslint . we get:

1:7   error  'a' is assigned a value but never used  no-unused-vars
1:12  error  Insert `;`                              prettier/prettier

✖ 2 problems (2 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

It runs against our JS file but not our TS file. To run against TS files you need to add --ext .js,.ts to the ESLint command. By default, ESLint will only check for .js files.

Running npx eslint . --ext .js,.ts

/index.js
1:7   error  'a' is assigned a value but never used  no-unused-vars
1:12  error  Insert `;`                              prettier/prettier

/index.ts
1:7   error  'a' is assigned a value but never used  no-unused-vars
1:12  error  Insert `;`                              prettier/prettier

✖ 4 problems (4 errors, 0 warnings)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

Working like a charm so far. Let’s add some real TS code and run it again. The TS file will look like this:

const a: number = 1

Running ESLint only against the .ts file:

1:8  error  Parsing error: Unexpected token :

✖ 1 problem (1 error, 0 warnings)

ESLint doesn’t know, by default, how to parse Typescript files. It is a similar problem we faced when running ESLint for the first time with ES5 defaults.
ESLint has a configuration in which you can specify the parser you want to use. There is also a package, as you could imagine, that handles this parsing for us. It is called @typescript-eslint/parser.

Let’s install it:

npm i @typescript-eslint/parser # --save-dev recommended

Now let’s configure ESLint to use the new parser:

module.exports = {
  parser: "@typescript-eslint/parser",
  extends: [
    'eslint-config-airbnb-base',
    'plugin:prettier/recommended',
  ]
};

Running ESLint again (npx eslint index.ts):

1:7   error  'a' is assigned a value but never used  no-unused-vars
1:20  error  Insert `;`                              prettier/prettier

✖ 2 problems (2 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Cool! Now we can run ESLint on TS files. Nonetheless, we don’t have any rules being used so we need to configure or use some styleguide, like the one we used by AirBnB before.
There is @typescript-eslint/eslint-plugin that offers us some defaults. Let’s go with it for now:

npm i @typescript-eslint/eslint-plugin # --save-dev recommended

Adding it to our configuration:

module.exports = {
  parser: "@typescript-eslint/parser",
  extends: [
    'eslint-config-airbnb-base',
    'plugin:@typescript-eslint/recommended',
    'plugin:prettier/recommended',
  ]
};

Now running npx eslint index.ts:

1:7   error    Type number trivially inferred from a number literal, remove type annotation  @typescript-eslint/no-inferrable-types
1:7   warning  'a' is assigned a value but never used                                        @typescript-eslint/no-unused-vars
1:20  error    Insert `;`                                                                    prettier/prettier

✖ 3 problems (2 errors, 1 warning)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

Cool! Now we have also proper linting in our Typescript file. We can also see that the Prettier rule still applies as expected.

Bear in mind that typescript-eslint is overriding eslint-config-airbnb-base in this case. It means that some rules won’t work in TS files that are still valid on JS files. Let’s have the files below to see it in action:

// index.js and index.ts
const a = 1;
a = 2;

Both files are identical. Running npx eslint . --ext .js,.ts we get:

/index.js
  2:1  error    'a' is constant                         no-const-assign
  2:1  warning  'a' is assigned a value but never used  @typescript-eslint/no-unused-vars

/index.ts
  2:1  warning  'a' is assigned a value but never used  @typescript-eslint/no-unused-vars

✖ 3 problems (1 error, 2 warnings)

The no-const-assign rule is overwritten by typescript-eslint for .ts files so we don’t get the same error for both files.
To overcome it, we need to change the order of the extended configurations, typescript-eslint comes first and eslint-config-airbnb-base next. If we do so:

module.exports = {
  parser: "@typescript-eslint/parser",
  extends: [
    "plugin:@typescript-eslint/recommended",
    "eslint-config-airbnb-base",
    "plugin:prettier/recommended"
  ]
};

Running npx eslint . --ext .js,.ts:

/index.js
  2:1  error    'a' is constant                         no-const-assign
  2:1  error    'a' is assigned a value but never used  no-unused-vars
  2:1  warning  'a' is assigned a value but never used  @typescript-eslint/no-unused-vars

/index.ts
  2:1  error    'a' is constant                         no-const-assign
  2:1  error    'a' is assigned a value but never used  no-unused-vars
  2:1  warning  'a' is assigned a value but never used  @typescript-eslint/no-unused-vars

✖ 6 problems (4 errors, 2 warnings)

Cool! Now we get the same error for both files.

One side note: In this example, I have a codebase with JS/TS, it might not be your case and you might also use another style guide where conflicts won’t happen.

That’s all folks!

I hope this article helped you to learn or clarify some concepts behind ESLint, Prettier, and Typescript playing together.

In short, you’ve to understand which files ESLint will analyze and the order of the configurations you want. Image adding now this into a Vue project, for example, you need to add .vue to --ext .js,.ts,.vue and add (or configure) some style guide which will add some rules to your project.

Most boilerplates will already have some lint set up and you will mostly disable some rules but in case you want to customize it or update packages (especially major bumps), it is important to understand how to perform the changes and the impacts it might have in your project.

That’s is all! Happy linting!