This is not related to pages.
Also there is no point calling the file utils/pageUtils.js. If it's in utils, it should be obvious enough with utils/page.js that this is an util.

In any case you should really think twice before creating a util/ directory. It's a smell of a bad design, 99% of the time you can find a better place for the code. Like, score.js ? Next to scoringCriteria.js ? And why not making it a single file so it's self contained and can be tested easily ?

kinda confusing description

'should leave input array unchanged if length is divisible by 3'

would be nice to know this only runs on app build and not on page load

1. Should have some comments about what this function is doing, when it runs, etc

2. this function should also be unit tested. it's not clear that the error will be thrown on an API failure. What comes from the API when it's down?

For this unit test, you will want to mock fetch , i.e. one test case where you mock expected responses, another where you mock error responses and show that the error is thrown

if this is only used in this function, just hardcode it into the function or define it at the top of the function

defining it outside here creates an unecessary global variable

what does responses look like here in the event of an error?

We have a unit test which is passing, but this is still a weird way to handle it. more robust would be

let responses;
try {
responses = await Promise.all([..])
} catch (err) {
throw new Error(`Failed to fetch scorecard API response`);
}

getScores requires the data to be a very specific shape, e.g. have a .criteria key etc.

No error handling for this

Possible for the API server DB to fail and return an empty array or object

Should have some kind of validation and throw an error if the data is not the shape you need

this isn't the approach we want to take here. While this would work on the very specific possible responses of an empty array or empty object, what we want to show is that an error is thrown on any response that is not of the required shape.

It doesn't need to be too complicated to get through this, though.

instead of return props: {exchanges: makeDivisibleByThree(getScores..}

just use the same try...catch block you already have to wrap the API call

try {

// Make API calls
const responses = apiCallsMadeSuccessfully

// Try to determine props from the api result
const props = {
            exchanges: makeDivisibleByThree(
                getScores(responses[0], exchangeScoringCriteria),
            ),
            instantExchanges: makeDivisibleByThree(
                getScores(responses[1], instantExchangeScoringCriteria),
            ),
            services: makeDivisibleByThree(
                getScores(responses[2], servicesScoringCriteria),
            ),
        }
} catch (err) {
throw err;
}

description should not be identical to the one above

If they really are the same test, can move the logic of this one into the above one

ditto

I suppose it's generated ? If so please add a comment with instructions to regenerate and add a @generated mark

The header is missing, but I think this is the case for most if not all the files in the repo.
@bytesofman can you please look at adding linter support for the repo and make sure we don't lose time reviewing this kind of stuff ?

Use proper doxygen layout:

/**
 * My wonderful comment.
 * Could very well span on multiple lines.
 */

Remove or the doc won't link to the function

dito, please go over the whole file