-
Notifications
You must be signed in to change notification settings - Fork 887
Warning: The 'no-unused-variable' rule requires type checking message... #2933
Comments
Please fill out the issue template. What does your tslint.json look like? |
I am home and tried the same project and its working fine. I will leave this open until I get to work on Monday to test again. Might need to just reinstall my node modules. I have also updated to use the issue template. |
Sometime after tslint updated (maybe v4 -> v5), This option hard to use and take long time until print results after updated, but important and most used linting option. is there any way to use this options without upper arguments? |
I am passing in --project with On my home computer I'm not having this issue but on my work computer I am. |
@everedifice there were bugs with the rule implementation, we almost deprecated it (#1481), and ultimately decided to keep it by delegating to the compiler's implementation of no-unused-variable (this addressed most of the bugs). There are lots of discussion threads about it in this repo that I'd encourage you to check out, mostly linked from the PR that made the breaking change (#2235. |
@mastrauckas I can't really help you without more details about the differences between your two different environments. |
@adidahiya I was getting this on a third computer which is a macOS last night too. I am going to try it again on my home computer again to see if it still happens. In general: |
@everedifice I just published a new version of If you're interested, you can find the docs here: https://github.com/ajafff/tslint-consistent-codestyle/blob/master/docs/no-unused.md |
The computer I thought was not having the problem appears to be having the issue after all. Is this a bug? |
Anything new on this issue? |
I'm having the same issue. |
The same issue, but with both 'Warning: The 'no-unused-variable' rule requires type information.' |
Same issue here |
Is this issue resolved or any temporary fix to stop displaying warnings. |
I don’t think it’s fixed. I don’t even think they accepted as an issue. |
Permanent fix, use |
@AnimaMundi well it does provide the same functionality however when running tslint as part of our CI process these needs to be flagged during test, not during build. I disaggree that this should be ignored / removed because the compiler does this at build time. |
@haswalt I don't see any reason why it needs to be flagged during the linting phase rather than the build phase. Anyway, it doesn't matter if you agree with me or not, I've nothing to do with the development of this project. I just seen that someone was looking for a fix and provided them with it. |
Similar to @AnimaMundi's fix, I used |
@AnimaMundi @haswalt @keego the merits of a lint rule vs. a compiler check for unused vars has been discussed extensively in other TSLint threads (#1481 and linked threads); this issue is not really the place for it. |
@adidahiya my comment was merely meant to share a fix for this issue, not provide commentary on the merits of linter rules vs compiler checks. |
Deferring to the compiler doesn't do the same thing: compiler has only one option: FAIL. |
not only can tslint problems be shown as warnings but they can also be ignored on a one off basis, whereas typescript compile errors cannot be |
These points have already all been hashed out (see my last comment and the linked threads). There is nothing stopping you from using @mastrauckas are you still having issues with this rule? The Aside: with TS 2.6, you can use |
@adidahiya i was merely responding to the comments above that claim there's no reason to have this as a lint rule rather than a compiler rule. but you're right i guess the relevant issue is with the vscode extension not tslint itself. tbh there were so many issues on this topic that it took me a while to suss out exactly why it's not working and where. appreciate the tip. i will def switch back to using the compiler setting as soon as we switch to 2.6 |
Another point for those who claim this should not be a lint rule: lint warnings can be fixable, and this is a prime candidate for that. |
I getting the same warning in the latest 1.19 VS Code {
"extends": "tslint:recommended",
"rules": {
"linebreak-style": [true, "LF"],
"quotemark": [true, "single", "avoid-escape", "avoid-template"],
"no-console": false,
"no-unused-expression": false,
"ordered-imports": false,
"member-access": [true, "no-public"],
"object-literal-sort-keys": false,
"curly": [true, "ignore-same-line"],
"semicolon": [true, "never"],
"no-var-requires": false,
"no-unused-variable": true
}
} |
If you look at VSCode 1.19 readme, there is a new feature for trating this and other rules as warnings.
Other rules are left as an exercise for the reader ;-) Note, that the tslint is this extension, while tsconfig is the VSCode built-in behavior. |
I've opted to remove |
I don't understand what VSCode has to do with this. It's not enough to have only VSCode treat these as warnings, I need my webpack dev server watch build not to fail because of them. Is there a replacement for
? |
@pelotom , several people got redirected here from VSCode TSLint extension, e.g. from https://github.com/Microsoft/vscode-tslint/issues/219 Until now, TS was not able to show some issues as warnings (green squiggles), but lints (ESlint, TSLint) were able to. So we were asking why TSlint would not report unused variables as warnings. But as of 1.19, VSCode's TS can make these warnings and we are withdrawing from this issue 😉 |
To be clear, I use VSCode too and would also like to see these warnings highlighted in the editor, but VSCode's settings seem like the wrong layer at which to be configuring the severity of compiler errors, since it doesn't affect the rest of your toolchain. |
I agree with you Tom, and hope the solution will be found where both the editor as well as our build/CI procedures would have the proper support. So far we have seen strong pushback (seemingly justified) and some (incl. me) would take what we can, today, while keeping hope for real solution. |
@rnemec I think you meant to write "release notes" instead of "readme". I was stupid enough to look for the readme. And for anyone arriving here we might as well quote the relevant bit:
|
So this is a temporary solution and would only work when using VSCode. Any other build tool using I don't quite understand how this solves anything. How is displaying these things as warnings useful if the compiler still treats them as errors? And if I understand correctly, the long term solution would be to either add a flag to enforce the same behavior in --- edit --- |
If you want lint checks to have different severity in dev mode vs. CI mode, you can do this with multiple tslint.json configs where one |
@adidahiya what's being discussed is a purported replacement for the |
@pelotom right, I got that -- but I don't think |
@adidahiya yes, that's why it's not a valid replacement currently. And I'd much rather see |
Makes sense. I believe this project aims to do that: https://github.com/angelozerr/tslint-language-service. You can use rules that require type checking with that plugin. |
I spoke too soon. We're blocked on #2649 for that plugin to be useful. Track that issue instead. |
@adidahiya yep, I've been tracking it for quite some time. |
Any news on this? Will it be deprecated or not? |
@philip-firstorder using this fixed the issue for me
|
🤖 Beep boop! 👉 TSLint is deprecated 👈 and you should switch to typescript-eslint! 🤖 🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋 |
Bug Report
with
tslint.json
configuration:What exactly am I doing wrong?
Actual behavior
When running
tslint
with the below parameters:I get the below warning:
Expected behavior
According to the
tslint
documentations to do type checking all I need to do is pass in--type-check --project tsconfig.json
but it does not seem to work.The text was updated successfully, but these errors were encountered: