-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeScript linting works only partially #1283
Comments
just ran into this too |
Just run into this as well. |
+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? |
Actually, the suggestion in #1007 would resolve this. |
Any news here? This would make life much easier... |
Any updates? I thought I could just add this to my standard config but I get "parser": "@typescript-eslint/parser",
"plugins": [
"@typescript-eslint/eslint-plugin"
] I know we can use |
I'd like to have solve this in a future version of
"rules": {
"no-unused-vars": "off",
"@typescript-eslint/no-unused-vars": "error"
} |
@feross Thanks for the reply That was plan B, but it wasn't possible because |
@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. |
Refer to Can I use a JavaScript language variant, like Flow or TypeScript?, I don't see I'm asking the above questions because I believe the problem here will be fixed if StandardJS allows me to |
I think this issue is very important because It affects almost all Typescript users and requires configuration changes 😅. I understand that 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 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::
|
Just wanted to put this package out there |
This is because the current Typescript setup would incorrectly emit unused-variable errors (e.g: when you import interfaces):sweat_smile:. Related to standard#1283
Just made a PR with a working Typescript setup in the readme and hope it can close this issue:sweat_smile:. |
Thanks! But, well, if we plan to go
|
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 {
"extends": [
"tslint:recommended",
"tslint-config-standard"
]
} Then you can just call For the VSCode support be careful to use I can make a PR for the doc if you guys want it, just ping me 😄 |
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. |
Any update? |
@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
]
} |
Standard has rules for TypeScript, as well. And that repository has instructions on set up, as well: |
Hi, all; what is the latest recommendation re TypeScript?
FYI, if it's (2), then any new users are blocked by this outstanding issue. Thanks! |
@JeffSpies my personal recommendation is |
|
Opened an issue for this here: #1590 |
|
Since |
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
but that doesn't looks like convinient at all.
The text was updated successfully, but these errors were encountered: