Couldn't generate the package-lock.json file for certain projects

[jadoonf]

Describe the bug

Facing the below error when scanning certain project repos (e.g. tier and n8n)

Error: couldn't generate the package-lock.json file for certain projects

Steps to reproduce the behavior

1. Clone the project repo
2. Run lstn in inside the project root
3. View the output Error: couldn't generate the package-lock.json file

Environment

• lstn version: 807cfc9.20230209
• go version: go1.19.4 darwin/arm64
• macOS Monterey 12.0.1

Expected vs actual behavior

Currently, if you run lstn to tier --json it works.
Running lstn in for a project's package.json should return the same output as using lstn to <package>.

[didof]

Thanks for reporting, @jadoonf!

Bug replicated. Working on it.

[didof]

Let's analyze one repo at a time.

n8n

In this repo, there is a block-npm-install.js registered on the preinstall hook.

This leaves the npmPackageLockOnly.Run() hanging. One could argue the script actually process.exit(1)s, thus the error should be returned into go.

Still, we can see how the program fails because of reaching the deadline (1 minute at the time of writing).

My first guess is that the preinstall runs the script on another thread (unsupported by facts at this time), so the exit code 1 is not picked up by the thread that spawned npm install --package-lock-only --no-audit. However, it is not properly closed and hangs until the timeout chimes.

I will investigate if my conjecture is right.

My proposal

Assuming my analysis is correct, here is how I would approach a solution.

1. looks for all possible ways by which it is possible to intercept npm install (let's assume is only preinstall - it may be for what I currently know)
2. If one of the found in point 1 is present in the package.json, replicate a tmp version of it without those, temporarily changing the name of the original package.json
3. catch up with the flow: hence lstn will internally run npm i --package-lock-only --no-audit
4. remove tmp package.json, and restore the name of the original

I recognize this approach to be very naïve and I am sure it can be improved by bringing it to the attention of @leodido.

[didof]

Let's move to the other repo

node-sdk

Similarly to preinstall in the previous case, here we have instead prepare. If I am not mistaken, it assumes that tsc is installed globally (otherwise it would be npx tsc).

Hence the cli fails.

My proposal

Same as the previous comment, replacing prepare other than preinstall

[leodido]

This is not a lstn bug.

It's not even an npm bug.

This is what I get by npm installing tier: error. So how could possibly lstn do it? :)

[leodido]

For lstn (and npm) to work the package.json file MUST be both syntactically and semantically valid.

If it assumes that a tool is installed globally and then it runs it via a preinstall (or whatever) script, then it's semantically broken, and even npm breaks (correctly).

[leodido]

Same thing for n8n

Closing.