feat: packages tracker ux logic

[fntlnz]

Fixes #170

How to test this version of the CLI?

To install it:

go install github.com/listendev/lstn/cmd/lstn@better-request-tracking

What happens?

A single request is made for every dependency instead of bulking them

The reason behind this is that by making a single request we can

• avoid hitting the API timeout of 6 seconds (there is no dependency request that will take more than 200/300 ms round trip)
• provide fine-grained progress tracking (this leads to better UX, the user can see things going on instead of waiting minutes for something to happen)
• show specific errors when a dependency had an error (which is not one of our pre-defined Problems)

A progress tracker is shown

Now that one of the benefits of doing a single request is to be able to do fine-grained progress tracking, that's what happens!

Screenshots

here are some screenshots of how it looks like

lstn scan

A request is made for every version mentioned in the package.json

lstn to react

This is the most basic use case, only the available versions are requested

lstn to react *`

A request is made for every possible version on npm, the progress is shown like this. You will notice that the semver constraint is used to specify what we are processing

lstn in

lstn in is not included in this. I did the code to actually include it but in is still very unstable for me at the moment until we do #132 . Once this gets merged I'll open an issue to do it.

• I have read the contributing guidelines
• I have followed the coding guidelines
• I have written unit tests
• I have made sure that the pull request is of reasonable size and can be easily reviewed

TODO after merge:

• once this gets merged, open an issue to support lstn in

[jadoonf]

LGTM

[leodido]

Thanks for prototyping this @fntlnz!

As discussed privately, we need to revamp this and decide which issue we want to solve. Either:

1. giving the CLI a progress indicator
2. better handling of the deadline (timeout) errors in the case of "bulk" package requests

Info at #170 (comment)

[fntlnz]

closing this since this is not the approach we want to take now