New Typescript linting overriding user config and causing build failure

[ztolley]

The introduction of #6513 stops my application from compiling as it uses it's own Typescript linting rules instead of the rules I have in .eslintrc.js

Previous to CRA adding Typescript linting I created my own typescript lint config for eslint using @typescript-eslint/eslint-plugin and @typescript-eslint/parser along with airbnb and prettier rules.

Within the project there is typescript file generated by graphql-code-generator that breaks various linting rules, so has been added to a .eslintignore file. When I run eslint the project passes with no errors.

However, when I build the project or run it in dev mode 2 lint errors are raised, relating to the fact that import statements appear half way through the file. Using the .eslintignore file doesn't fix this problem, nor does updating my .eslintrc.js file to exclude the rule.

As a result I cannot build my project with CRA 3 and have had to revert to 2.

[wilcoschoneveld]

I had the same issue but I found a solution: https://graphql-code-generator.com/docs/plugins/add

In your codegen.yml, use the plugin add to insert an /* eslint-disable */ line to the start of the file.

Example:

schema: http://localhost:5000/api/graphql
overwrite: true
generates:
    ./src/generated.tsx:
        documents: ./src/graphql/*.ts
        plugins:
            - add: "/* eslint-disable */"
            - typescript-common
            - typescript-client
            - typescript-react-apollo
        config:
            noNamespaces: true
            enumsAsTypes: true
            withHooks: true
            noHoc: false
            noComponents: false

[jadbox]

I'm having the same issue: tslint.json rules seem to be ignored now in v3 and overwritten by the new defaults. Please send help.

[proluk]

We've also upgraded to the latest react-scripts (3.0.0) in order to get rid of high vulnerabilities, but it broke our tslint configuration. No .eslinttignore or .eslintrc are working and adding comments to every file that disables eslint seems really bad.

[ianschmitz]

Our ESLint configuration is not currently configurable (as has always been the case) and is documented here: https://facebook.github.io/create-react-app/docs/setting-up-your-editor#displaying-lint-output-in-the-editor. Any changes you make to your configuration file will only affect your editor integration but not the Dev server or prod builds.

We haven't ever supported TSLint so I'm not sure how the other comments are related.

[raptor1989]

Ok, but why can't I configure my own rules? To comply with your rules, I would have to rewrite my code. Stupid breaking change... I also came back to revert to 2.

[jadbox]

@ianschmitz I think the confusion was that Typescript folks where using TSLint since the react-scripts had no TS linting support. We have entire projects built using custom rules, but now since TS linting is supported in v3, we are all stuck with pages of warnings and/or broken builds. While the JS community had somewhat the ease of greenfield development using react-scripts' blessed linting rules, the TS community is now coming onboard with custom opinionated rulesets for large existing projects.

Proposals:

1. provide a way to completely disable linting in production and live server (maybe this already exists?)
2. provide a way for custom eslint overriding rules (both JS/TS)

On a community aside, I didn't realize the react-scripts didn't allow JS projects to customize the linting rules. As someone that disagrees with the defaults of most linters (as well as my team), it feels very heavy-handed to including linting by-default without a way to customize. (obviously there's ejection, but it's far from an easy path to own)

[ztolley]

I purposely use eslint as the Typescript team stated that that is their preferred solution and are putting effort into eslint support, though I'm sure some folks here use tslint.

But back to the comment by @ianschmitz . I understand that the linting config, which now supports Typescript, is it's own thing and doesn't use the lint config a developer may add but my issue is that this recent change broken my code, and it seems others too. I know moving to 3 means possible breaking changes but this wasn't in the release notes, probably because no one realised.

The workaround @wilcoschoneveld mentioned will get me out of this for now but as @jadbox says, linting is opinionated and projects have rules in place and probably went through their own pain getting them agreed. I too think that having CRA linting errors stop a build is too heavy handed. I worry that option 2 would be too difficult to do and maybe the quickest short term solution would be to add a config option to allow a build to complete even when there are lint errors and maybe another to allow linting to be disabled so the user can use their own.

[dannycochran]

@ianschmitz is this just a matter of looking to see if a user has provided an .eslintrc file here? if they have one, CRA could load it, otherwise use the existing one as a default?

https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/config/webpack.config.js#L324

[ianschmitz]

@ztolley The baked in linting configuration is how we've always provided CRA, including adding new rules between major versions which is similar to what is being mentioned in this thread. This thread is slightly different in that some (including myself) were using TSLint prior to 3.0. To clarify, we did mention that the added TypeScript linting was in the 3.0 release notes and listed as a breaking change.

I will discuss the possibility of extending the ESLint config with the team which i think would satisfy what most of you are looking for (i know i would use it personally), but i can't promise anything as it's a fairly significant change to how we've been providing CRA for a few years now.

[dmitryxcom]

This is very frustrating.
The fix seemingly solves very few, if any, actual problems people report, while going pretty much against what is purports to fix, i.e. #5641, which very clearly shows interest for a configurable tslint. In addition it enforces rules that are NOT in the list of "things that we want", such as unknown-ref,
in a few examples that I looked, it seems to ignore things defined via definitely typed @types that have something like
declare global {
x: Type;
}
x is being reported as unkonwn.