Vscode-ng-language-service: ngcc crash with monorepo / multi-project config - Ivy Native LS

Created on 18 Dec 2020  路  5Comments  路  Source: angular/vscode-ng-language-service

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

  1. Enable the extension on a repo like this one https://github.com/jscutlery/convoyr
  2. Open the app.component.ts

Expected 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.
bug

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!

All 5 comments

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.

https://github.com/angular/vscode-ng-language-service/blob/132b2051c44de5504bc77776430c066ecc5fa88a/server/src/ngcc.ts#L36-L44

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._

Was this page helpful?
0 / 5 - 0 ratings