TypeScript linting works only partially

[ArmorDarks]

What version of standard?

v12.0.1

What operating system, Node.js, and npm version?

Window 10
Node v10.15.3
NPM v6.9.0

What did you expect to happen?

Expected to have ability use TypeScript linting

What actually happened?

Following #1278, provided docs are insufficient to make TypeScript linting fully work, since while it will become enabled, due to lack of the TypeScript plugin rules extensions, rules actually won't work (see #1278 (comment)).

More of it, since there is no way to disable no-unused-vars, Standard will always fail on imports of the types.

For now there is no way to make it fully work. False-unsued vars can be fixed by providing within each file

/* eslint no-unused-vars: "off" */
/* eslint @typescript-eslint/no-unused-vars: "error" */

but that doesn't looks like convinient at all.

[shavyg2]

just ran into this too

[eladchen]

Just run into this as well.

[despian]

+1 also having problems with this

Another issue I came across is the indentation rules will break under certain circumstances.

You can fix this by adding:

/* eslint indent: off */
/* eslint @typescript-eslint/indent: [error, 2] */

I'm sure there are probably also many other weird edge-case issues.

typescript-eslint does provide a set of sane rules recommended.json but it's not possible to enable these when using standard.

Also, some of these rules aren't really compatible with the standard rules. E.g.

    "@typescript-eslint/indent": "error"  // defaults to 4 space

It would be nice if typescript had proper "no config needed" support in standard.

Maybe the standard project could include their own set of sane defaults for typescript which are compatible with the normal js rules and apply them if the typescript plugin is loaded.

If I were to submit a PR along these lines is it likely it would be accepted?

[despian]

Actually, the suggestion in #1007 would resolve this.

[bjufre]

Any news here? This would make life much easier...

[Pandawan]

Any updates?

I thought I could just add this to my standard config but I get no-unused-vars.

"parser": "@typescript-eslint/parser",
"plugins": [
  "@typescript-eslint/eslint-plugin"
]

I know we can use eslint-config-standard-with-typescript but I think it'd be nice if it was supported by default in standard. I guess we have to wait for #1007 and/or #1321

[feross]

I'd like to have solve this in a future version of standard. In the meantime, you can use standardx:

1. npm install standardx
2. Rename the "standard" field in your package.json to "standardx"
3. Add a new "rules": [] section with the following rules:

"rules": {
  "no-unused-vars": "off",
  "@typescript-eslint/no-unused-vars": "error"
}

[ArmorDarks]

@feross Thanks for the reply

That was plan B, but it wasn't possible because standardx didn't work with VS Code extension. Now since you've merged standard/vscode-standard#71 that should become possible after release.

[ndom91]

@feross would it make sense to open an issue on Typescript support in general and maybe even pin it? People can weigh in on what the best path forward would be (out of the box support, plugin, etc.), which rules to include, etc. etc.

EDIT: Sorry just saw your new issue 'Making standard easier to use' which covers a lot of the typescript stuff.

[ThisIsManta]

Refer to Can I use a JavaScript language variant, like Flow or TypeScript?, I don't see "extends": ["plugin:@typescript-eslint/recommended"]. How do the rules offered by @typescript-eslint/eslint-plugin work? As far as I know, Standard does not allow us to specify rules or extends field, right?

I'm asking the above questions because I believe the problem here will be fixed if StandardJS allows me to extends or enable the rule @typescript-eslint/no-unused-vars (Do not be confused with the original rule no-unused-vars from ESLint)

[ahimta]

I think this issue is very important because It affects almost all Typescript users and requires configuration changes 😅.

I understand that standard is mostly focused on pure Javascript and its ESLint & standardx siblings are intended to be more flexible and handle some edge-cases like this.

Let's assume only a dozen of developers are affected by this and spent 15 minutes (focused on finding a solution and confused by the behavior) each to mitigate it. Then the total time would be 12 * 15 = 180minutes = 3hours.

In addition, the maintainers are spending focused time reading, understanding, and replying to this.

IMHO, a maintainer should save everyones' time and first imagine that this is the only issue in the issue-tracker, allocate 10 minutes to think of fixes/mitigations, 10 minutes to choose one of them, and 30+ minutes to implement the fix/mitigation.

TLDR; 👇

From the 30 seconds I skimmed this issue I think there are two fixes/mitigations:sweat_smile::

1. Document @feross standardx mitigation/workaround in the FAQ (the FAQ item maybe added as the last comment before closing the issue).
2. Implement an actual fix for Typescript.

[toddbluhm]

Just wanted to put this package out there ts-standard for anyone wanting to try it out. It uses the eslint-config-standard-with-typescript rules and the standard-engine under the hood with minimal configuration required. I have used this in some of my other packages and so far it is working well.

[ahimta]

Just made a PR with a working Typescript setup in the readme and hope it can close this issue:sweat_smile:.

[ArmorDarks]

Thanks! But, well, if we plan to go standardx-way, there are few issues at stake:

1. Add support for standardx, and potentially more standard-engine based linters vscode-standard#71 has been merged, but not released. That means VS Code users won't be able to use it at all. I believe other popular editors might be affected by the same issue.

2. Even if standard.engine option will be released, it still requires additional configuration. That is, another developer will open the project with standardx and won't have any clue why VS Code doesn't show any errors. Proposal: Feature request: detect engine vscode-standard#93

   Turns out mentioned PR already incorporates engine detection. My bad, sorry.

[sheerlox]

For Typescript I find it better to use TSLint with the tslint-config-standard plugin.

It's really easy to setup:

yarn add tslint tslint-config-standard --dev

Create a tslint.json file with the following content:

{
  "extends": [
    "tslint:recommended",
    "tslint-config-standard"
  ]
}

Then you can just call tslint from your CLI / package.json scripts to validate the syntax.

For the VSCode support be careful to use TSLint (deprecated) by egamma, because the one by Microsoft doesn't support autofix 😅

I can make a PR for the doc if you guys want it, just ping me 😄

[Pandawan]

Although much easier, I don't think it's the best idea to promote TSLint when it has been deprecated. The TSLint team are currently porting all of the TypeScript rules and logic over to typescript-eslint to make one unified linter for both JS and TS.

[david-szabo97]

Any update?

[sheerlox]

@david-szabo97 as @pandawanfr said, typescript-eslint is the way to go. It works very well and allows to use any ESLint rule in addition to the Typescript specific rules.

Here's my configuration for anyone who wonder (be aware that I customized some rules on the last block of "rules" in eslintrc.json).

eslintrc.json

{
    "env": {
        "es6": true,
        "node": true
    },
    "extends": [
        "standard"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2018,
        "project": "tsconfig.eslint.json"
    },
    "plugins": [
        "@typescript-eslint"
    ],
    "rules": {
      "no-unused-vars": "off",
      "@typescript-eslint/no-unused-vars": ["error", { "argsIgnorePattern": "^_" }],
      "camelcase": "off",
      "@typescript-eslint/camelcase": ["error", { "properties": "never" }],
      "semi": "off",
      "@typescript-eslint/semi": ["error", "never"],

      "@typescript-eslint/await-thenable": "error",

      "no-multiple-empty-lines": ["error", { "max": 1, "maxBOF": 0 }],
      "comma-dangle": ["error", "always-multiline"],
      "quote-props": ["error", "as-needed", { "numbers": true }],
      "operator-linebreak": ["error", "before"]
    }
}

tsconfig.eslint.json

{
  "compilerOptions": {
    "strict": true
  },
  "include": [
    "code/**/*.ts", <-- PATH TO YOUR CODE
  ]
}

[mightyiam]

Standard has rules for TypeScript, as well. And that repository has instructions on set up, as well:
https://github.com/standard/eslint-config-standard-with-typescript.

[JeffSpies]

Hi, all; what is the latest recommendation re TypeScript?

1. https://github.com/standard/eslint-config-standard-with-typescript as @mightyiam recommends above
2. StandardX as recommended on the README by @ahimta

FYI, if it's (2), then any new users are blocked by this outstanding issue.

Thanks!

[LinusU]

@JeffSpies my personal recommendation is ts-standard, which will probably be transfered to the Standard org. in a not so distant future ☺️

[theoludwig]

ts-standard is awesome! We should update the README.md, that everyone using TypeScript should use ts-standard.

[feross]

ts-standard is awesome! We should update the README.md, that everyone using TypeScript should use ts-standard.

Opened an issue for this here: #1590

[toddbluhm]

ts-standard is now officially part of the standard github organization.

https://github.com/standard/ts-standard

[feross]

Since ts-standard is now the official recommendation, I'll close this issue.

https://github.com/standard/ts-standard