Parser is looking in the wrong place for the tsconfig file #2814
Comments
|
Thanks so much! Feel free to deprioritize this for the time being... it is a holiday week after all! I pushed the changes recommended in those docs and still seem to have three locations where it isn't registering the update. It seems like these are changes that may need to be propagated over to nx, which I will definitely do once things are resolved. Also, is this a place where following these directions for monorepos would be valuable? It feels like I'm right on the line to me. |
|
Our tooling essentially does this fs.readFileSync(
path.join(
parserOptions.tsconfigRootDir ?? process.cwd(),
parserOptions.project,
),
);So if you are finding it's not finding the tsconfigs, then likely there's likely something else getting in the way. I do notice that you haven't set |
|
I updated the non-overridden base config and am still seeing the behavior. The fact that it's essentially doing a # this is the path of the file being parsed
/Users/.../galvanize/apps/g-ent-desktop/src/environments/environment.ts
# this is the path of the eslint config file
/Users/.../galvanize/apps/g-ent-desktop/.eslintrc.json
# this is the path of the config file it extends
/Users/.../galvanize/.eslintrc.js
# this is the path of the tslint file that reads
/Users/.../galvanize/tsconfig.base.json
# this is the path from the error about not being able to read the file
/Users/.../galvanize/node_modules/tsconfig.base.json' |
|
So I keep digging, but I can't figure out exactly what's happening - I can't figure out exactly where So why is a nrwl module tsconfig being included? This is a regression introduced in #2418. When I switched the codebase to Which means that your globs are matching aaaallll of these tsconfigs: So what's the fix? Also you can simplify your eslint config a bit (changes including the fix): Tbhesswebber/typescript-eslint-debug#1 |
|
Thanks for digging into this and for updating my config! Did you discover any changes that I should be requesting within Narwhal Extensions in conjunction with the fix that you identified? I think that Happy Thanksgiving!! |
|
no changes to narwhal. |
…olderIgnoreList` and deduplicate resolved projects In #2418 I introduced a regression - I forgot to add in the default value for `projectFolderIgnoreList`. This means that globs have been matching `node_modules` since the v4.0 release! Oops :( This PR fixes that. It also hoists the tsconfig path canonicalisation up so that we can deduplicate early. Previously if you provided a config like `projects: ['./tsconfig.json', './**/tsconfig.json']`, then we would resolve this to `./tsconfig.json` and `tsconfig.json`, then later canonicalise them. This meant we'd check that same tsconfig twice! By hoisting the canonicalisation, we can deduplicate this early. Fixes #2814
…olderIgnoreList` and deduplicate resolved projects (#2819) In #2418 I introduced a regression - I forgot to add in the default value for `projectFolderIgnoreList`. This means that globs have been matching `node_modules` since the v4.0 release! Oops :( This PR fixes that. It also hoists the tsconfig path canonicalisation up so that we can deduplicate early. Previously if you provided a config like `projects: ['./tsconfig.json', './**/tsconfig.json']`, then we would resolve this to `./tsconfig.json` and `tsconfig.json`, then later canonicalise them. This meant we'd check that same tsconfig twice! By hoisting the canonicalisation, we can deduplicate this early. Fixes #2814
Repro
I apologize for the size of this repro - I am in a weird spot where I am using (Narwhal Extensions)[nx.dev] with nx-electron and somehow the whole shebang has managed to cause the parser to lose track of the base tsconfig in some circumstances.
To run linting on every piece of the project, you have to run
nx run-many --target lint --all --parallel(the parallel flag just speeds it all up).This is a super greenfield POC that just got started, so it's essentially empty, but I'd be happy to jump into a chat to better understand/explain the problem in order to file a better issue with whomever the real culprit is if it's not the parser.
Running with typescript-eslint in debug mode hasn't seemed to provide any clarity.
Expected Result
I expected the parser to look at the root of the workspace for
tsconfig.base.jsonActual Result
A number of files are causing parsing errors at line 0 column 0 because the parser is looking for
./node_modules/tsconfig.base.jsonrather than./tsconfig.base.json. This does not happen with all of the files.Additional Info
There are a couple hundred more lines of output from running
DEBUG=typescript-eslint:* nx run-many --target lint --all --parallel, but none seem to be concerning.Versions
@typescript-eslint/parser4.3.0TypeScript4.0.3ESLint7.10.0node(system)12.16.3electron7.1.0The text was updated successfully, but these errors were encountered: