Vulnerability scan for solution fails if solution has any .esproj (JavaScript Project System, JSPS) projects

[josundt]

Describe the bug

Vulnerability scan for solution fails if solution has any .esproj (JavaScript Project System, JSPS) projects.
dotnet list ./my-solution.sln package --vulnerable

To Reproduce

Create a VS solution with one or more .csproj (C#) projects and one or more .esproj (JSPS) projects.
Try to run the dotnet list [solutionfile] package --vulnerable command.

You will get the following error message:

The project `/home/johndoe/mysolution/myjsproject/myjsproject.esproj` uses package.config for NuGet packages, while the command works only with package reference projects.

Proposal/Feature request

JavaScript Project System (JSPS) (.esproj) projects lets you configure custom clean, build, publish, test and startup commands.
The .NET SDK/MSBuild clean, build, publish, test and startup actions/events will then be wired up with the corresponding JavaScript project's actions. This typically means defining the npm scripts to run for each of these .NET/MSBuild actions/events.

Imagine if JSTS projects also defined a ListVulnerabilitiesCommand for .esproj projects (with the default value of npm audit [options])?

That would have allowed dotnet list ./my-solution.sln package --vulnerable to collect both NuGet vulnerabilities from .NET projects AND npm vulnerabilities from .esproj, and consolidate the results into a single report.

If you like me see the great added value of such a feature, please consider forwarding the proposal to the team working with JSPS projects.

Alternatively

If your are not going for full-blown consolidated NuGet+npm reporting capabilities from dotnet list package --vulnerable with JSTS, JSTS (.esproj) projects should at least be ignored and not break the vulnerability scan when scanning solution files.

[baronfel]

@nkolev92 could the JSPS change their declared package restore type to PackageReference (even if they don't actually ever use PackageReference) and sidestep this issue in the short term?

cc @joj

[dotnet-policy-service]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

[beppemarazzi]

probably NuGet/Home#12817 (comment) may help