-
Notifications
You must be signed in to change notification settings - Fork 508
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
Linting should include type checking #352
Comments
i think this is a reasonable suggestion, but has tradeoffs in running that extra step for linting. its easy to do in userland too. will leave it to @jaredpalmer but inclined to do nothing here. maybe document it in the lint section. |
If not too overly complicated, what about an additional flag as an opt-in feature? |
i have no strong opinions here. up to jared |
I don't understand what the intended workflow would be. Normally you get type checking in the files open in an editor and then have either a |
Copying from #529:
I think we'll either add a (Please note the distinction between "command" and "script" in case the terminology is confusing) |
According to Wikipedia:
If we agree on that definition, type-checking should be part of The biggest issue here is that Good news is that I've built tsc-files to handle that case (it's just a tiny wrapper on top of Edit: now I'm not sure type-checking specific files would be actually useful. If a change to foo.ts breaks some type on bar.ts and only foo.ts is checked, then bar.ts' broken types wouldn't be noticed. :/ |
@gustavopch Is there a workaround for this at the moment? |
@gburnett First, upvote microsoft/TypeScript#27379 to show interest in an official solution from the TypeScript maintainers. So, yes, there's a workaround. I started to write it: https://github.com/gustavopch/tsc-files. But, as I mentioned in the "Edit" section of my comment above, type-checking the files that were changed is not enough — we should also type-check all files that depend on the changed ones. Currently, |
Current Behavior
npm run lint
reports no problem with this (which is strange, usually should require a second radix param, but this is not important right now)Desired Behavior
Linting should run
tsc --noEmit
to catch thatArgument of type '8' is not assignable to parameter of type 'string'
errorSuggested Solution
Run
tsc --noEmit
followed byeslint
Who does this impact? Who is this for?
VS Code users (maybe others as well). If file is not open there is no way to get an error report from it, except building
The text was updated successfully, but these errors were encountered: