Describe the bug
The VSCode extension crashes on repositories with multiple tsconfigs.
It seems to try to ngcc the node_modules folder next to every tsconfig.
To Reproduce
app.component.tsExpected behavior
It should not crash.
Logs
[Info - 8:18:20 PM] Angular language server process ID: 91911
[Info - 8:18:20 PM] Using typescript/lib/tsserverlibrary v4.0.5 from /.vscode/extensions/angular.ng-template-0.1101.0-next.1/node_modules/typescript/lib/tsserverlibrary.js
[Info - 8:18:20 PM] Using @angular/language-service/bundles/ivy v11.1.0-next.3 from /.vscode/extensions/angular.ng-template-0.1101.0-next.1/node_modules/@angular/language-service/bundles/ivy.js
[Info - 8:18:20 PM] Log file: /Library/Application Support/Code/logs/20201218T201630/exthost3/Angular.ng-template/nglangsvc.log
[Error - 8:18:25 PM] Cannot read file '/dev/jscutlery/convoyr/dev/jscutlery/convoyr/tsconfig.json'.
No inputs were found in config file '/dev/jscutlery/convoyr/dev/jscutlery/convoyr/apps/sandbox/tsconfig.json'. Specified 'include' paths were '["**/*.ts"]' and 'exclude' paths were '[]'.
Error: ENOENT: no such file or directory, scandir '/dev/jscutlery/convoyr/apps/sandbox/node_modules'
at Object.readdirSync (fs.js:854:3)
at Object.fs.readdirSync (electron/js2c/asar.js:621:39)
at NodeJSFileSystem.readdir (/dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/src/ngtsc/file_system/src/node_js_file_system.js:53:23)
at EntryPointCollector.walkDirectoryForPackages (/dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/ngcc/src/entry_point_finder/entry_point_collector.js:63:56)
at /dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/ngcc/src/entry_point_finder/directory_walker_entry_point_finder.js:62:100
at Object.trackDuration (/dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/ngcc/src/entry_point_finder/utils.js:93:22)
at DirectoryWalkerEntryPointFinder.walkBasePathForPackages (/dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/ngcc/src/entry_point_finder/directory_walker_entry_point_finder.js:62:39)
at DirectoryWalkerEntryPointFinder.findEntryPoints (/dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/ngcc/src/entry_point_finder/directory_walker_entry_point_finder.js:40:30)
at /dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/ngcc/src/execution/analyze_entry_points.js:28:41
at new ClusterMaster (/dev/jscutlery/convoyr/node_modules/@angular/compiler-cli/ngcc/src/execution/cluster/master.js:45:30)
[Error - 8:18:26 PM] Failed to run ngcc for /dev/jscutlery/convoyr/apps/sandbox/tsconfig.json:
ngcc for /dev/jscutlery/convoyr/apps/sandbox/tsconfig.json returned exit code 1, stderr:
Language service will remain disabled.
Thanks for the link to the repo, it's very helpful.
Looks like ngcc does not handle the case where cwd is manually set to the directory of the tsconfig.json, as opposed to the directory where node_modules is.
When I run ngcc from convoyr/apps/sandbox, I saw the same failure as you posted.
When run from the root directory, ngcc works fine.
Also, we should not disable language service permanently if ngcc fails. I've created #1041 to track this.
Happy to help!
Should we open an issue on github.com/angular/angular?
@yjaaidi The issue here is sufficient - no need to open one on angular/angular! We haven't decided yet how/if we want to consolidate language service reports between the two repos so for now we're just keeping an eye on both.
Keen and I paired on this yesterday and were able to track down the root cause for 4 separate issues using the linked repository. We should have fixes merged and ready for the next release in January. Thanks for the report!
That was quick. Great job!
Let me know if I can help.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
@yjaaidi The issue here is sufficient - no need to open one on angular/angular! We haven't decided yet how/if we want to consolidate language service reports between the two repos so for now we're just keeping an eye on both.
Keen and I paired on this yesterday and were able to track down the root cause for 4 separate issues using the linked repository. We should have fixes merged and ready for the next release in January. Thanks for the report!