Typescript parsing error when EXTEND_ESLINT=true

[ae2438]

Describe the bug

Originally asked on Stackoverflow

Here is a demonstration.

See the above question for more info. Essentially, I get parsing errors when using various Typescript features if I set EXTEND_ESLINT in my .env. Removing this line allows the app to compile just fine, but of course I lose the ability to configure ESLint. The problem occurs in a newly created CRA project that has then had Typescript installed after creation.

I have had some luck by changing index.js -> index.tsx, however, this leads to other ESLint problems that are not really ideal.

Did you try recovering your dependencies?

No need. This happens in a newly created project with very few new dependencies.

Which terms did you search for in User Guide?

The Stackoverflow question lists some of the tutorials/documentation I followed.

Environment

  System:
    OS: Linux 5.2 Manjaro Linux undefined
    CPU: (12) x64 Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
  Binaries:
    Node: 12.9.1 - /usr/bin/node
    Yarn: 1.17.3 - /usr/bin/yarn
    npm: 6.11.2 - /usr/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: 69.0.1
  npmPackages:
    // Note that the example repo was created one week ago using the latest versions
    react: ^16.9.0 => 16.10.2 
    react-dom: ^16.8.4 => 16.10.2 
    react-scripts: 3.1.2 => 3.2.0 
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

1. Clone the example repo and install deps
2. yarn start or
3. yarn vstart to run without customize-cra
4. Compilation fails, parsing error is reported

Expected behavior

The app compiles. ESLint gives appropriate errors/warnings.

Actual behavior

App does not compile. A parsing error is raised by ESLint (?)

Reproducible demo

https://github.com/ae2438/cra-test

[BrianFarnhill]

I'm having what appears to be the same issue - I'm trying to enable some linting rules in an existing CRA app, and as soon as I put the EXTEND_ESLINT param in (through either the .env file, or inline to the start command like EXTEND_ESLINT=true npm run start) I see typescript compilation errors like this:

Failed to compile.

./src/pages/monitoring/Usage.DataLoader.tsx
  Line 161:32:  Parsing error: Unexpected token, expected ";"

  159 |         }
  160 | 
> 161 |         let browserLabels = [] as string[]
      |                                ^
  162 |         let browserData = [] as number[]
  163 |         let osLabels = [] as string[]
  164 |         let osData = [] as number[] 

The same as @ae2438 when I take that out, the application compiles and runs just fine. I've had success adding linting rules in to the package.json file that validate fine when I run npx eslint ./src --ext .tsx but I'm trying to get them included in the errors/warnings that go with the CRA start script (like when I leave unused vars it warns me about it inline there, but doesn't include the extra rules in my config).

[ae2438]

This could be the source of the problem. It seems that a parser is selected at the beginning of the linting and then ignores the overrides section when importing further files (doesn't check if they're .js or .ts/x). The parser chosen depends on the type of the index file (Typescript or Javascript). So, if I have index.tsx and run yarn start, I will get an error relating to Flow syntax in a Javascript file. Conversely, if I run yarn start with index.js, I will get an error in a Typescript file relating to Typescript syntax.

Consider the following .eslintrc.js:

module.exports = {
  plugins: ['react', 'react-hooks', 'flowtype'],
  extends: [
    'eslint:recommended',
    'plugin:react/recommended',
    'react-app',
  ],
  overrides: [
    {
      files: ['**/*.ts', '**/*.tsx'],
      parser: 'asdf',  // <----- invalid parser, will fail
    },
    {
      files: ['**/*.js'],
      parser: 'qwer',  // <----- invalid parser, will fail
    },
  ],
};

where asdf and qwer have replaced @typescript-eslint/parser and babel-eslint, respectively. If I were to run yarn start at this stage, as expected I would get an error from ESLint saying that either the parser asdf or the parser qwer could not be loaded. Things get interesting when I set one parser to a valid value but keep the other one as invalid.

Tests:

|           | -ts & -js | +ts & -js | -ts & +js | +ts & +js |
|-----------|-----------|-----------|-----------|-----------|
| index.js  | qwer nf   | qwer nf   | ts err    | ts err    |
| index.tsx | asdf nf   | flow err  | asdf nf   | flow err  |

Headings:

• index.js: in these tests, the index file was a Javascript file
• index.tsx: in these tests, the index file was a Typescript file
• -ts & -js: in these tests, both parsers were set to the invalid values, asdf (for Typescript) and qwer (for Javascript)
• +ts & -js: in these tests, the parser for Typescript files was set to @typescript-eslint/parser and the parser for Javascript files was set to qwer
• ...and so forth

Results:

• qwer nf: indicates that ESLint raised an error because it could not load module qwer
• asdf nf: indicates that ESLint raised an error because it could not load module asdf
• ts err: parsing error for Typescript syntax (as described in the OP)
• flow err: parsing error for Flowtype syntax

(I hope all that makes sense...)

Conclusion:
It is evident that, when one parser is a valid parser, and the index file's type matches the parser (e.g. @typescript-eslint/parser is used and the index file is index.tsx), ESLint does not even attempt to load the other parser, because no "unable to load parser" error is given. This is further reinforced by the fact the error that is given relates to the syntax of the other language (e.g. when the parser is babel-eslint, a parsing error will be raised on Typescript syntax, and when the parser is @typescript-eslint/parser, a parsing error will be raised on Flow-syntax).

The expected results should be "parser not found" errors in all columns except the last column, where both parsers are valid.

[ae2438]

To clarify, this seems to all be because of #7776

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[christianchown]

Hello, any movement on this? It's the only thing preventing me having really clean ReasonML-TypeScript-JavaScript interop with CRA

[ae2438]

@christianchown check #7776. It says it's in the 3.3 milestone

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.