fix: quirks with version commands and config retrieval

[erunion]

🧰 Changes

While tinkering around with Typescript here I discovered a few quirks:

• versions:delete would never properly alert you if your deletion failed, and our tests to check for this weren't actually testing it.
  • I've slightly refactored a few tests in this suite so they now always assert either a command resolution or rejection.
• When retrieving config data out of the config Typescript didn't like how we're doing config.host so I've updated all config.* retrievals to use the preferrable .get() accessor.

🧬 QA & Testing

• Tests pass?

[erunion]

Added {removed: true} because that's what we return in our API and the handleRes handler was failing without this because .reply(200) by itself doesn't return JSON for res.json().

We should probably actually return a 204 No Content instead for these delete calls but 🤷

[kanadgupta]

Looking good, just a few test bed suggestions below!

[kanadgupta]

I'm a little lukewarm on using toThrow when we can use toBe(new Error('msg')) since toThrow only checks for substrings in error messages (see docs)... but we can leave that as out-of-scope for this PR!

[erunion]

I've always had the worst trouble with toBe(new Error('msg')):

  ● rdme login › should error if no project provided

    expect(received).rejects.toBe(expected) // Object.is equality

    If it should pass with deep equality, replace "toBe" with "toStrictEqual"

    Expected: [Error: No project subdomain provided. Please use `--project`.]
    Received: serializes to the same string

      17 |
      18 |   it('should error if no project provided', () => {
    > 19 |     return expect(cmd.run({})).rejects.toBe(new Error('No project subdomain provided. Please use `--project`.'));
         |                                        ^
      20 |   });
      21 |
      22 |   it('should error if email is invalid', () => {

      at Object.toBe (node_modules/expect/build/index.js:285:22)
      at Object.<anonymous> (__tests__/cmds/login.test.js:19:40)

[kanadgupta]

oh whooops sorry it definitely should be toStrictEqual, but I think that's the only issue there?

[erunion]

@kanadgupta I pushed up a bunch of changes if you want to give this another look

[kanadgupta]

Sorry, I saw a few more places where we could be using toStrictEqual (assuming it works properly) and just noticed a few areas where we could enhance our tests... but other than that, LGTM!