The options I added support for in the config file were: an input URL, an input file, an output file, toggling streaming, and toggling token usage data.
I also updated the README with information on how to use the config file.
Added an async function parseConfig(configFilePath) to handle parsing the config file.
/** * Parses a TOML config file for options * @param {string} configFilePath Path to .toml config file * @returns {{ url: string | undefined, inputFile: string | undefined, outputFile: string | undefined, tokenUsage: boolean | undefined, stream: boolean | undefined }} An object containing the parsed options */exportasyncfunctionparseConfig(configFilePath){constconfigfileContent=awaitfsP.readFile(configFilePath,{encoding: "utf8",});constconfigOptions=TOML.parse(configfileContent);returnconfigOptions;}
Made validateArgs() an async function so it can call the above function. Added a try/catch around the call which catches parsing errors but lets the program continue if the file doesn't exist.
Modified argument/config parsing flow:
Use URL CLI option if present
if missing, use URL config option if present
if missing, use input file argument if present
if missing, use input file config option if present
if missing, exit
Added comments explaining above flow
Added config section to README
Notes
I used the module fs:promises in order to take advantage of async/await syntax, while the rest of the program uses fs. Let me know if you'd like this changed.
</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/KrinsKumar/Scrappy/pull/9">View on GitHub</a></div>
The hardest part was understanding the control flow for parsing arguments since Krins's program manually handled argument parsing with conditionals as opposed to working with a library like yargs or commander. I wrote it out to help me understand, and added comments explaining it.
Another thing I ran into trouble with was the fs module in Node. I tried using async/await syntax with it because I remembered doing the same for my project, but it wouldn't work. Turns out I was confusing it with the fs/promises module. Although Scrappy already imported fs, I went ahead and imported fs/promises anyway because it's easier to work with, and left a note in the pull request about the new import.
I had a decent idea of what I needed to do because somebody else had already added the feature to my project. For example, since the person contributing to my project used fs/promises too (because my code already used it), I knew what code the error thrown would have if the config file wasn't found.
I also used a JSDoc style comment for the function I added. I saw them in another assignment I've been working on and wanted to learn how they work so I could comment my code better. This enabled me to add a description, and specify parameter and return value types, which would be recognized by VSCode's IntelliSense, making it easier to work with. I think it's super helpful being able to view how a function works by hovering over it in the editor, so adding that capability to code I worked on felt good.
Using git remote
I also received a pull request from my classmate Harshil to add the feature to my project.
This week, I learned how to use git remote add to add the contributor's fork as a remote to my local repository. In the past, when working with other people's forks, I'd always clone them to a separate folder, but when trying this method while reviewing this pull request, I realized doing it this way was much faster and fairly straightforward. I'll definitely be using this method in the future - it should help save quite a bit of time.
Uday Rana
