refactor: Update calls to prettier functions to account for latest async API

[jdalrymple]

What: Due to the prettier update, the API has changed - now exposing async functions

Why: API changes with latest dep version no longer support sync functions

How: Went through each related function and updated them accordingly

Checklist:

• Documentation
• Tests
• Ready to be merged
• Added myself to contributors table

Related to #375

[JoshuaKGoldberg]

[Praise] Nice catch 😄

[jdalrymple]

I try to keep my clean up scope creeps to a minimum, but somethings i just hadddd to fix haha

[jdalrymple]

Once this is in, ill look at the next blocked PR 🫡

[lwasser]

@jdalrymple thank you for this refactor! I have a few questions!

With these refactors we are moving towards ES modules (yay!) ✨

But when i build the package, link/install and run this locally i get an error:

❯ all-contributors init
file:///Users/lblablabla/allcontributors/cli/dist/cli.js:4
const path = require('path');
             ^
ReferenceError: require is not defined in ES module scope, you can use import instead
This file is being treated as an ES module because it has a '.js' file extension and '[/[[Users/lblablabla](file:///Users/lblablabla/)](file:///Users/lblablabla/)](file:///Users/lblablabla/allcontributors/cli/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
    at file:///[Users/lblablabla](file:///Users/lblablabla/)/allcontributors/cli/dist/cli.js:4:14
    at ModuleJob.run (node:internal/modules/esm/module_job:343:25)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:665:26)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:117:5)

1. As we refactor, do we need to add "type": "module" to support this in our package.json ? But if we add that then how do we manage the older syntax? neither work for me locally when i run all-contributors init . (adding it or not adding it) but it seems like something is off. If this is a larger dependency issue then maybe we do have to merge as is
2. If not, am i doing something wrong when i build and install locally:

npm run build
npm link

We could also merge this and just add that in a separate pr (if needed) bare with me!
I ask this seeing that tests pass. And i'm fine with smaller quicker iterations

and if this is what others see, we probably need to add a test or two to catch it. but please let's start with making sure you can see the same issue that I see locally! THANK YOU!!

[lwasser]

Ok so when i don't add type:module (maybe the build system standardizes things? i haven't looked yet... i get a TYPEERROR related to yargs

TypeError: yargs.scriptName is not a function
    at getArgs (/Users/leahawasser/Documents/GitHub/allcontributors/cli/dist/cli.js:16:16)
    at run (/Users/leahawasser/Documents/GitHub/allcontributors/cli/dist/cli.js:99:18)
    at Object.<anonymous> (/Users/leahawasser/Documents/GitHub/allcontributors/cli/dist/cli.js:119:1)
    at Module._compile (node:internal/modules/cjs/loader:1706:14)
    at Object..js (node:internal/modules/cjs/loader:1839:10)
    at Module.load (node:internal/modules/cjs/loader:1441:32)
    at Function._load (node:internal/modules/cjs/loader:1263:12)
    at TracingChannel.traceSync (node:diagnostics_channel:328:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
    at Function.e

I think this might be a yargs version error . I looked at the tests when i merged pr's but i didn't test the CLI each time assuming test coverage.

[lwasser]

Ok it was bugging me - the fix is actually pinning yargs back to "yargs": "17.7.2". This is indeed a dependency issue. And the api was already broken and i missed it. thank goodness it's not deploying. I propose that we merge this. And we will have a larger set of fixes as we upgrade dependencies.

[lwasser]

opening a quick pr to modify yargs