NPM error code ELSPROBLEMS

[oheger-bosch]

In commit 03560a5, there have been major changes in the implementation of NPM. Specifically, a new npm list command is now executed instead of scanning the node_modules folder.

It seems that this approach can sometimes fail with error messages like the following:

NPM failed to resolve dependencies for path 'package.json': IOException: Running 'npm list --depth Infinity --json --long' in '/tmp/ort-AnalyzerDownloader-analyzer-worker4409112913667343033' failed with exit code 1:
npm error code ELSPROBLEMS
npm error invalid: @angular-devkit/[email protected] /tmp/ort-AnalyzerDownloader-analyzer-worker4409112913667343033/node_modules/@angular-devkit/build-angular
npm error invalid: @angular/[email protected] /tmp/ort-AnalyzerDownloader-analyzer-worker4409112913667343033/node_modules/@angular/compiler-cli
...

After upgrading to an ORT version containing this fix, some of our projects which were successful before suddenly have this issue. For them no dependencies are found. Unfortunately, these are internal projects which cannot be shared, and I do not know an easy way to reproduce the problem.

However, from what I see from the output of the npm list command executed locally, still a valid JSON structure is returned containing information about the modules. It just has an additional "error" property with the error messages shown above. So, maybe, ORT could be more lenient here and still process the JSON structure, even if the command returns an exit code indicating an error? It could still generate an issue (maybe of type WARN) if the "error" property is found.

[fviernau]

Maybe it's similar to [1]
Would [2] fix the issue?

[1] angular/angular-cli#28647
[2] angular/angular-cli#28629 (comment)

[sschuberth]

Independently of whether the project's setup can be fixed or not, it's probably a good idea to change listModules() to take a mutable list of issues and populate it with any messages parsed from error output.

As a side note, I'll probably do some CommandLineTool refactoring that makes this easier.

[oheger-bosch]

Maybe it's similar to [1] Would [2] fix the issue?

[1] angular/angular-cli#28647 [2] angular/angular-cli#28629 (comment)

I cannot tell. The error we receive has a different code (ELSPROBLEMS), no packages are reported as MISSING, and there also other packages marked as INVALID.

[oheger-bosch]

Independently of whether the project's setup can be fixed or not, it's probably a good idea to change listModules() to take a mutable list of issues and populate it with any messages parsed from error output.

As a side note, I'll probably do some CommandLineTool refactoring that makes this easier.

IIUC, the dependency analysis fails completely because the execution of the npm list command seems to return a non-success exit code. This causes the run function to throw an exception, since it calls requireSuccess. So, it may be necessary to allow the processing of command output even if the command did not terminate successfully.

[fviernau]

IIUC, the dependency analysis fails completely because the execution of the npm list command seems to return a non-success exit code. This causes the run function to throw an exception, since it calls requireSuccess. So, it may be necessary to allow the processing of command output even if the command did not terminate successfully.

Have you investigate outside of ORT whether this can be fixed, e.g. by the steps I linked above?
(On the first glance, this seems to me to be an issue with the project setup or NPM, e.g. outside of ORT)

[oheger-bosch]

Have you investigate outside of ORT whether this can be fixed, e.g. by the steps I linked above? (On the first glance, this seems to me to be an issue with the project setup or NPM, e.g. outside of ORT)

I have tried this fix, but it did not help - the npm list command prints the same error as before. By the way, the customers have no issues with their build; so it will be hard to convince them that the problem is on their side.

[hanna-modica]

Also, we have two independent users who encounter this issue, so it is for that reason also unlikely, that is on the end-user side.

[fviernau]

Also, we have two independent users who encounter this issue, so it is for that reason also unlikely, that is on the end-user side.

Not sure how you define "on the end user side". The error comes from the npm list command. So, it is for sure outside of ort. It's either a bug with npm or some issue with the project setup, or am I missing something?

[fviernau]

Another idea which one could try out as a work-around is to see whether any of the different install stratigies works:
e.g. use npm install --install-strategy=...

[fviernau]

@oheger-bosch can you tell whether @angular-devkit/[email protected] is actually present under any descendant of node_modules ?

[oheger-bosch]

Also, we have two independent users who encounter this issue, so it is for that reason also unlikely, that is on the end-user side.

Not sure how you define "on the end user side". The error comes from the npm list command. So, it is for sure outside of ort. It's either a bug with npm or some issue with the project setup, or am I missing something?

But wouldn't you see this as a regression, since the same project could be analyzed with ORT before without any issues? Facts are:

• For the users the project setup works fine; they can build successfully.
• A plain npm list command (without --depth Infinity) does not report any error. (So maybe, there is some problem in transitive dependencies which the users cannot influence directly?)
• The npm list command issued by ORT returns useful information, but its output is ignored because of the exit code.

[fviernau]

But wouldn't you see this as a regression

Yes, but what's the point?

[oheger-bosch]

@oheger-bosch can you tell whether @angular-devkit/[email protected] is actually present under any descendant of node_modules ?

@fviernau Yes, I found it directly in the top-level node_modules folder.

[fviernau]

From [1] it would be nice to see output of npm list @angular-devkit/build-angular

@oheger-bosch can you run this and share output?

[1] https://stackoverflow.com/questions/78832352/react-test-error-referenceerror-global-is-not-defined

[mnonnenmacher]

I agree that the implementation should be lenient and if the response from npm list contains usable data and errors, the data should be used and the errors reported as issues instead of failing completely, like we do for other package managers.

But wouldn't you see this as a regression

Yes, but what's the point?

@fviernau I believe the point is that you focus on potential issues in the analyzed projects which gives the impressions that you are against the proposed lenient implementation.

Independently of whether the project's setup can be fixed or not, it's probably a good idea to change listModules() to take a mutable list of issues and populate it with any messages parsed from error output.

@sschuberth I'd rather change the functions return type to include the issues than to add side-effects to the function.

[fviernau]

@fviernau I believe the point is that you focus on potential issues in the analyzed projects

Not only, I just want to extend the view to also consider if the issue is 1) in the project setup or 2) in npm itself

which gives the impressions that you are against the proposed lenient implementation.

I'm not against this per se. I'm trying to help find the root cause.

Note: Before making the implementation lenient I believe it would be good to try to understand that. Looking at other package managers, I believe this is not completely something out of the ordinary, to require the underlying tool to successfully list its dependencies. For example, ./gradlew dependencies IIRC normally needed to succeed?!

[oheger-bosch]

npm list @angular-devkit/build-angular

$ npm list @angular-devkit/build-angular
[email protected] /home/heo1wa3/temp/ort/PKCV-WebUI
├─┬ @angular-builders/[email protected]
│ ├── @angular-devkit/[email protected] deduped invalid: "^16.0.0" from node_modules/@angular-builders/jest
│ └─┬ [email protected]
│   └── @angular-devkit/[email protected] deduped invalid: "^16.0.0" from node_modules/@angular-builders/jest, ">=13.0.0 <17.0.0" from node_modules/@angular-builders/jest/node_modules/jest-preset-angular
├── @angular-devkit/[email protected] invalid: "^16.0.0" from node_modules/@angular-builders/jest
├─┬ @nrwl/[email protected]
│ └─┬ @nx/[email protected]
│   └── @angular-devkit/[email protected] deduped invalid: "^16.0.0" from node_modules/@angular-builders/jest, ">=13.0.0 <17.0.0" from node_modules/@angular-builders/jest/node_modules/jest-preset-angular
└─┬ [email protected]
  └── @angular-devkit/[email protected] deduped invalid: "^16.0.0" from node_modules/@angular-builders/jest

npm error code ELSPROBLEMS
npm error invalid: @angular-devkit/[email protected] /home/heo1wa3/temp/ort/PKCV-WebUI/node_modules/@angular-devkit/build-angular
npm error A complete log of this run can be found in: /home/heo1wa3/.npm/_logs/2024-12-06T13_01_55_077Z-debug-0.log

[sschuberth]

After upgrading to an ORT version containing this fix, some of our projects which were successful before suddenly have this issue.

@oheger-bosch when you say "issue" here, do you mean there is an ORT Issue contained in a created analyzer result, or do you mean that the analyzer result is not created at all?

[sschuberth]

In any case, I'd like to point out #9383 that I created recently. In the context of that, I believe we should collect as much information as possible about analyzer problems, including to forward any problems reported by underlying CLI tools as ORT Issues.

[oheger-bosch]

After upgrading to an ORT version containing this fix, some of our projects which were successful before suddenly have this issue.

@oheger-bosch when you say "issue" here, do you mean there is an ORT Issue contained in a created analyzer result, or do you mean that the analyzer result is not created at all?

Sorry, bad wording on my side. What happens is that an Issue of type Error is generated, and other than that the Analyzer result is empty - no dependencies are listed.

[biffgaut]

I am seeing a similar behavior from what appears to be the same (or at least related) issue. When I run npm list --depth Infinity --json --long at the top level of my app, it successfully scans my dependency tree. When I run ort --info analyze -i . -o results -f jSON it fails, saying:

16:45:15.678 [DefaultDispatcher-worker-1] ERROR org.ossreviewtoolkit.analyzer.PackageManager - NPM failed to resolve dependencies for path 'package.json': IOException: Running 'npm list --depth Infinity --json --long' in '/Users/biffgaut/Documents/Active/AWS/Constructs/throwaway/TempClean' failed with exit code 1:
npm error code ELSPROBLEMS
npm error missing: @aws-sdk/client-kms@^3.478.0, required by @aws-solutions-constructs/[email protected]
npm error missing: @aws-sdk/client-s3@^3.478.0, required by @aws-solutions-constructs/[email protected]
npm error missing: aws-sdk-client-mock@^3.0.0, required by @aws-solutions-constructs/[email protected]

Which seems odd, because the command that supposedly fails works fine when I run it. I originally saw this in v40, and also when upgrading to 42.1.0.

After seeing this post I went back and tried older versions - ORT worked successfully up through v39.0.0, then breaks with v40.0.0

[fviernau]

maybe interresting: npm/cli#6856 (comment)