Refactor NPM package updater

[eranturgeman]

• All tests passed. If this feature is not already covered by the tests, I added new tests.
• This pull request is on the dev branch.
• I used gofmt for formatting the code before submitting the pull request.
• Update documentation about new features / new supported technologies

---

This PR changes the NPM package handler to test-based fixes instead of cli command fixes.
As past of the change we ease the installation after a fix is performed to only regenerate the lock file, hence reducing the strict build process we used to have and make the process less error prone

Missing testcase:
We need to add a new integration test test case to TestScanRepositoryCmd_Run that verifies we do not regenerate a lock file if it doesnt exists in remote. since the TestScanRepositoryCmd_Run is not passing right now and we need to fix it I added it to the overall test plan for future addition

[eyalk007]

please provide a link to a fix pr

[eyalk007]

reviewed most of files
please tell me you are done so i can rereveiw

[eranturgeman]

please provide a link to a fix pr

https://github.com/eranturgeman/npm-small/pull/14

[github-actions]

---

🐸 JFrog Frogbot

[orto17]

lets not merge this pr until the bug will be fixed and we'll be able to remove this workaround and test it properly

[eyalk007]

you can do somehting simpler,
you can check if the file is untracked
this will eliminate the need for brnahc name

so you wont need to pass it all around
you can do something like this:

func IsFileTrackedByGit(filePath string) (bool, error) {
    repo, err := git.PlainOpen(".")
    if err != nil {
        return false, err
    }
    worktree, err := repo.Worktree()
    if err != nil {
        return false, err
    }
    status, err := worktree.Status()
    if err != nil {
        return false, err
    }
    fileStatus := status.File(filePath)
    // Untracked = file exists but not in git
    // Ignored = file matches .gitignore pattern
    // Anything else (Unmodified, Modified, etc.) = tracked
    return fileStatus.Worktree != git.Untracked && fileStatus.Worktree != git.Ignored, nil
}

you can do other approches for finding out if its tracked, but hte bottom line is it will be simpler than checking remote, adn will ansdwer our use case of lockfile check

[eranturgeman]

I considered this approach but I think it can lead to false action in one particular edge case - if the customer is generating the lock file in the ci and for some reason adds it (which is not likely to happen be still..) we will get a wrong response from the method you suggested.
Im not sure if this small ease in complexity worth risking it and performing less clear action. but I will consider this change, thank you.
Any way this reminded my one case we should handle and I missed here - to delete the lock file after all the fixes before we push the new PR as it is not suppose to be in the PR (regenerated or not)