VSCode shows erroneous red squigglies (compile errors) on Typescript React front-end code #175
Comments
|
I've been researching this issue and have a few notes so far:
The actual problem as stated in the issue is that index.ts is showing a red squiggly for an es-lint error when in fact this file is TypeScript and should be parsed as such. I suspect that a fix for this issue will not really address # 1 and # 2 above but will involve convincing VSCode that this file is infact Typescript and should be linted as TS and not ES. |
|
After more research, I have found a SO with someone having the exact same problem and configuration as our project. https://stackoverflow.com/questions/66672131/typescript-record-is-not-defined Still researching what to do to fix it. |
megahirt
added
developer task
While trying to fix issue #175 where VSCode was showing a red squiggly for value TypeScript, I discovered that we have two eslintrc.json files, where in fact we should only need one. Removing this eslintrc file which specified a babel parser, exposes actual TS lint errors which could not be seen before. Those errors will be resolved in a future commit.
While trying to fix issue #175 where VSCode was showing a red squiggly for value TypeScript, I discovered that we have two eslintrc.json files, where in fact we should only need one. Removing this eslintrc file which specified a babel parser, exposes actual TS lint errors which could not be seen before. Those errors will be resolved in a future commit.
* fix 'lint' npm script and add as CI step The 'lint' npm script as originally written wasn't working because a path was never specified. (a file or folder path is required). Additionally, it was not linting typescript files because .ts and .tsx are not checked by default. This enables those extensions as well. Finally, I added a lint step to the GA build * remove extra eslintrc.json file While trying to fix issue #175 where VSCode was showing a red squiggly for value TypeScript, I discovered that we have two eslintrc.json files, where in fact we should only need one. Removing this eslintrc file which specified a babel parser, exposes actual TS lint errors which could not be seen before. Those errors will be resolved in a future commit. * Auto fix ESLint errors on save in VSCode Change the VSCode workspace settings to fix ESLint errors that can be automatically fixed. * specify eslint env as browser for react As it turns out, we do need a separate eslintrc.json for the react, and this environment setting seems to be the only thing needed at this point. See https://stackoverflow.com/questions/41858052/solving-linter-error-no-undef-for-document for more information * eslint: rename IAnalyticsContext interface * eslint typescript auto fix errors The following changes were automatically fixed using eslint --fix * don't auto fix in npm lint script I decided against auto fixing linter errors in the npm script as this step is run in GA CI, which is not the place to automatically fix anything. In VSCode at least, auto fixing linter errors should happen automatically on file save. * Fix failing CI lint Co-authored-by: Ira Hopkinson <ira_hopkinson@sil.org>
It is well-documented (see 1-6 below) that VSCode doesn't support setups like ours, where multiple tsconfig files coexist in a single directory. Strangely, though, it is only recently that this has become a problem, with VSCode at random intervals forgetting that it's ever heard of `expect` or `describe` (because it's not seeing `tsconfig.test.json`, but taking a while to realize it). There is an open issue[7] tracking the addition of support for this, but it's been open for a long time, with little movement. In the meantime, this solves the problem by adding placeholder `test/tsconfig.json` files to each package, each pointing to its corresponding `tsconfig.test.ts` file. I went with this approach over simply moving and renaming the existing test tsconfigs because this allows us to stay consistent in having all flavors of tsconfig for a package live at the package root level, and provides an easy way to reverse this workaround, should VSCode ever fix the underlying problem. [1] angular/angular-cli#5175 [2] microsoft/TypeScript#49210 [3] microsoft/vscode#107750 [4] microsoft/vscode#12463 [5] sillsdev/bible-karaoke#175 [6] microsoft/TypeScript#8435 [7] microsoft/TypeScript#33094
It is well-documented (see 1-6 below) that VSCode doesn't support setups like ours, where multiple tsconfig files coexist in a single directory. Strangely, though, it is only recently that this has become a problem, with VSCode at random intervals forgetting that it's ever heard of `expect` or `describe` (because it's not seeing `tsconfig.test.json`, but taking a while to realize it). There is an open issue[7] tracking the addition of support for this, but it's been open for a long time, with little movement. In the meantime, this solves the problem by adding placeholder `test/tsconfig.json` files to each package, each pointing to its corresponding `tsconfig.test.ts` file. I went with this approach over simply moving and renaming the existing test tsconfigs because this allows us to stay consistent in having all flavors of tsconfig for a package live at the package root level, and provides an easy way to reverse this workaround, should VSCode ever fix the underlying problem. [1] angular/angular-cli#5175 [2] microsoft/TypeScript#49210 [3] microsoft/vscode#107750 [4] microsoft/vscode#12463 [5] sillsdev/bible-karaoke#175 [6] microsoft/TypeScript#8435 [7] microsoft/TypeScript#33094
Our front-end code was recently converted from JS to TS and so we are using TSC to compile the Typescript before handing off to rescripts. There are a few "red squiggles" that VSCode shows for certain files in our project, and they seem to be related to non-Typescript errors, since tsc compiles fine and does not show any warnings.
An example of an erroneous red squiggly is in index.ts
The text was updated successfully, but these errors were encountered: