lstn scan not failing without any output

[jadoonf]

Describe the bug

Running lstn scan with this package.json fails without any output locally.
However, the same project works fine with the listendev/action@scan action (logs)

Please include:

• lstn version 0.3.1
• macOS ventura 13.0

Steps to reproduce the behavior

1. Clone https://github.com/garnet-org/demos.git
2. Run lstn scan .
3. View output

Expected vs actual behavior

Instead of returning verdicts, it fails without any output in the local terminal.

[fntlnz]

This is likely caused by connection issues to the npm registry, maybe a timeout issue or something like that.

I'll investigate further.

Another thing I remember is that we didn't experience this in easylstn (the prototype before scan). I noticed that this problem exists in to as well when you do things like this.

lstn to --endpoint https://npm-staging.listen.dev react '*'

So I suspect that also doing the dependencies one at time (as opposed to doing them in bulk) will also be beneficial.

Additionally, doing them one at time allows us to have the nice progress output (like we showcased in easylstn) and in case of any failure we only skip the dependencies with an actual problem vs all of them.

[fntlnz]

This happens because of the --timeout flag which is setup at 60 seconds by default.

NPM registry connections are strictly related to this since most of the time that connection is the slowest part of the process. The previous statement is proven by the fact that this happens locally but not on the action. Most of the times 60 seconds are more than enough on the action but not locally.

To improve this, I propose to have a better "progress tracker" that prints the errors and shows "where we are" while processing the request.

[jadoonf]

@fntlnz the proposed solution in #187 was tested for the earlier case, and it is working now! so this solution would solve our issue for now.

[leodido]

@jadoonf the one in #187 is not a solution to this problem, even if it gives you the perception of solving it...

The problem here is that the default --timeout (60 seconds) MAY be too little and the CLI doesn't have a progress indicator that lets users understand that.

I see 2 separate topics here:

1. giving commands a progress indicator (that has nothing to do with the fact that the requests happen in parallel or not) (see Progress indicator #190)
2. always communicating we are exiting because of a short timeout (by always propagating deadline errors up the chain)

So, as a recap: this issue is easily solved without code changes just by raising the timeout (eg., --timeout 3000).

[leodido]

To prove this is a problem regarding the timeout (and it's also a flaky problem): see my output.

I run lstn scan ciao1/ where ciao1/ directory contains the package.json file of the demos repository.