refactor(oclif): renaming src/cmds to src/commands

.eslintrc

@@ -33,11 +33,11 @@
     /**
      * This is a small rule to prevent us from using console.log() statements in our commands.
      *
-     * We've had troubles in the past where our test coverage required us to use Jest mocks for
+     * We've had troubles in the past where our test coverage required us to use Vitest mocks for
      * console.log() calls, hurting our ability to write resilient tests and easily debug issues.
      *
      * We should be returning Promise-wrapped values in our main command functions
-     * so we can write robust tests and take advantage of `bin/rdme.js`,
+     * so we can write robust tests and take advantage of `bin/run.js` and `src/baseCommand.ts`,
      * which we use for printing function outputs and returning correct exit codes.
      *
      * Furthermore, we should also be using our custom loggers (see src/lib/logger.js)

.gitignore

@@ -3,3 +3,7 @@ coverage/
 dist/
 exe/
 node_modules/
+tmp/
+
+# required for building with TS
+src/package.json

CONTRIBUTING.md

@@ -2,11 +2,11 @@
 
 ## Running Shell Commands Locally 🐚
 
-To run test commands from within the repository, run the build and then run your commands from the root of the repository and use `./bin/rdme.js` instead of `rdme` so it properly points to the command executable, like so:
+To run test commands from within the repository, run the build and then run your commands from the root of the repository and use `./bin/run.js` instead of `rdme` so it properly points to the command executable, like so:
 
 ```sh
 npm run build
-./bin/rdme.js openapi:validate __tests__/__fixtures__/ref-oas/petstore.json
+./bin/run.js openapi:validate __tests__/__fixtures__/ref-oas/petstore.json
 ```
 
 If you need to debug commands quicker and re-building TS everytime is becoming cumbersome, you can use the debug command, like so:
@@ -70,7 +70,7 @@ act -j simple
 
 ### Usage of `console`
 
-As you'll learn in our commands logic (see [`bin/rdme.js`](bin/rdme.js) and the [`src/cmds`](src/cmds) directory), we wrap our command outputs in resolved/rejected [`Promise` objects](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) and use [`bin/rdme.js`](bin/rdme.js) file to log the results to the console and return the correct status code. This is so we can write more resilient tests, ensure that the proper exit codes are being returned, and make debugging easier.
+As you'll learn in our commands logic (see [`bin/run.js`](bin/run.js) and the [`src/commands`](src/commands) directory), we wrap our command outputs in resolved/rejected [`Promise` objects](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) and use [`bin/run.js`](bin/run.js) file to log the results to the console and return the correct status code. This is so we can write more resilient tests, ensure that the proper exit codes are being returned, and make debugging easier.
 
 When writing command logic, avoid using `console` statements (and correspondingly, avoid mocking `console` statements in tests) when possible.
 

__tests__/bin.test.ts

@@ -7,8 +7,8 @@ describe('bin', () => {
     expect.assertions(1);
 
     await new Promise(resolve => {
-      exec(`node ${__dirname}/../bin/rdme.js`, (error, stdout) => {
-        expect(stdout).toContain('a utility for interacting with ReadMe');
+      exec(`node ${__dirname}/../bin/run.js`, (error, stdout) => {
+        expect(stdout).toContain("ReadMe's official CLI and GitHub Action");
         resolve(true);
       });
     });