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
Add compatible TSConfig base #1020
Comments
Thank you for caring enough to report this. I'm not sure that this is worth the user's effort during setup. How do you feel? |
@mightyiam I think the smallest useful implementation of this feature is an added section to the README that documents the tsconfig options that are duplicated or conflicting here. I agree this is not needed to get setup, but without this information provided by this project, the user will need to go though each tsconfig option one at a time and test which options must be set in order to avoid the described problems. Related TSConfig optionsThe following TSConfig compiler options are handled by this ESLint config and may be safely disabled to avoid double reporting by TypeScript: {
"compilerOptions": {
"allowUnreachableCode": true,
"allowUnusedLabels": true,
"noFallthroughCasesInSwitch": false,
"noUnusedLocals": false
}
} |
Regarding point number 1, we can't think of such an example. Can you?
The example Please confirm. |
@mightyiam I think you are right, the current
Yea, this should be the case, and my initial motivation for finding the overlapping cases. |
@razor-x do you feel it's worth it considering these? |
I have no way of knowing or evaluating this. I can only speak from my experience.
I agree it may not belong inline with the setup instructions, however having this information available, assuming it stays up to date, can only help those who look for it.
Yes, that is an unfortunate limitation. More likely then, a user would integrate the existing options into their own config and be responsible for updating them when they update these rules. It seems likely that any change to these rules that affected the existing compatibility with TSConfig would be breaking, so that is not an unreasonable ask from the user in my opinion.
This is the most compelling point: having outdated documentation is often worse than no documentation. Having a way to test the compatibility in CI is a good prerequisite for adding this. I don't have a solution at the moment, but open to thinking about it, or implementing any suggestions. |
@razor-x, would you enjoy joining us in one of these sessions to think about this, or possibly help us decide on the next rules? |
Sorry for disappearing on this. Thanks for the invite, I can try to join a session, but the timing is difficult for me. About this comment:
TypeScript 5.0.is out and has an update that resolves this constraint! https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#supporting-multiple-configuration-files-in-extends I'm wondering if this project could adopt opinions on some of the other TypeScript "style" options to further follow the path of Standard's "No configuration / no bikeshedding". So this package is "eslint rules + compatible TypeScript rules" So this module would provide a base config like this: {
"compilerOptions": {
// enables a lot of checks, but maybe out of scope for this?
"strict": true,
// Effects output only, maybe out of scope?
"newLine": "lf",
// New option, recommend but maybe out of scope?
"verbatimModuleSyntax": true,
// Recommend checks to enable by TypeScript docs
"exactOptionalPropertyTypes": true,
"noImplicitOverride": true,
"noImplicitReturns": true,
"noPropertyAccessFromIndexSignature": true,
"noUncheckedIndexedAccess": true,
"noUnusedParameters": true,
"forceConsistentCasingInFileNames": true,
// Inverse of these are recommend by TypeScript docs, but already handled by eslint-config-standard-with-typescript
"allowUnreachableCode": true,
"allowUnusedLabels": true,
"noFallthroughCasesInSwitch": false,
"noUnusedLocals": false
} |
Thank you. We'll take a look at this. Highest priority is currently #1149. |
What version of this package are you using?
What problem do you want to solve?
When using TypeScipt with Standard, some linting rules configured here can conflict with checks defined in
tsconfig.json
.What do you think is the correct solution to this problem?
This base file disable the TS checks that are already handled by Standard.
Are you willing to submit a pull request to implement this change?
Yes.
The text was updated successfully, but these errors were encountered: