feat: Retrieving translations from scanner and CLI

[fabnguess]

I'm doing this to get your feedback and also share a problem I encountered during implementation.

The issue suggests using the GitHub package to retrieve the target projects. The problem is that when I use downloadAndExtract to retrieve the scanner and cli packages, an error appears. I tested on quite a few of our packages and the problem recurred on some.

To be able to continue working, I used some packages where there were no problems, including utils and ossf-scorecard-sdk.

[PierreDemailly]

@fabnguess I bet your error is due to default branch.
Both cli & scanner have master as default while @nodesecure/github use main: const kDefaultBranch = "main";.

You need to add dlOptions (which are the github.downloadAndExtract options).
So we can use the master branch:

await fetchTranslations(["cli"], { branch: "master" });

Edit:
So we'll need to take care of the api because we wanna be allowing to pass the branch for any repo, i see 2 options:

await fetchTranslations([{ repo: "cli", branch: "master" }, { repo: "scanner", branch: "master" }]);

Or the chaining API as we discussed already

await i18n
  .repository("cli", { branch: "master" })
  .repository("scanner", { branch: "master" })
  .fetch()

[PierreDemailly]

@fraxken FYI when we pass the wrong branch the error is weird

It's because we keep doing createWriteStream even if the request fails, since the file is xx.tar.gz, it throws this error because he's waiting for gzip format
I'm not sure what we can do to prevent this

[fabnguess]

@PierreDemailly, Indeed, the problem was due to the branch

[fraxken]

This code is not intended to be shipped in the package. Everything is devDep and must be run as separated script.

[fraxken]

@fabnguess think to handle my review (you resolved some threads but the code didn't change, did you forget to push?)

[fabnguess]

I'll do it by tonight

[fabnguess]

Hi @fraxken ,
In our discussion with @PierreDemailly , we agreed to merge the contents of the language files from the target packages into the local language files rather than using the extendFromSystemPath API. I'm currently working on this aspect, but I can already submit my changes for your consideration.