feat: remove support for baseFlags

[mdonnalley]

Remove support for baseFlags

Currently, in order for one Command class to inherit flags from another Command class is to use a property called baseFlags (see docs).

This solution assumes that you'll only ever have one layer of abstraction, which is not a safe assumption. So in order for commands to inherit flags from multiple parents you have to use the spread operator

import {Command, Flags} from '@oclif/core'

abstract class BaseCommand1 extends Command {
  static baseFlags = {
    loglevel: Flags.boolean()
  }
}

abstract class BaseCommand2 extends BaseCommand1 {
  static baseFlags = {
    ...BaseCommand1.baseFlags,
    verbose: Flags.boolean()
  }
}

abstract class BaseCommand3 extends BaseCommand2 {
  static baseFlags = {
    ...BaseCommand2.baseFlags,
    silent: Flags.boolean()
  }
}

export default class MyCommand extends BaseCommand3 {
  static flags = {
    username: Flags.string()
  }
}

Because of this, we're removing baseFlags and requiring the spread operator anytime you want flags to be inherited. So the above example would change to this:

import {Command, Flags} from '@oclif/core'

abstract class BaseCommand1 extends Command {
  static flags = {
    loglevel: Flags.boolean()
  }
}

abstract class BaseCommand2 extends BaseCommand1 {
  static flags = {
    ...BaseCommand1.flags,
    verbose: Flags.boolean()
  }
}

abstract class BaseCommand3 extends BaseCommand2 {
  static flags = {
    ...BaseCommand2.flags,
    silent: Flags.boolean()
  }
}

export default class MyCommand extends BaseCommand3 {
  static flags = {
    ...BaseCommand3.flags,
    username: Flags.string()
  }
}

The downside is that it will require an extra line of code for those who are only using a single base Command class but the upside is that there won't be any confusion about the difference between baseFlags and flags and when to use each.

Other Changes

• Use feat: version 4 test#550
• Improve test coverage

@W-15470630@

[WillieRuemmele]

why do this change? @cristiand391 and I struggled to reverse this in jsforce?

[mdonnalley]

@WillieRuemmele I'm not sure what you mean. This change is to use the new major of oclif/test (which I originally wrote as POC inside ../test). Not sure how it relates to jsforce

[WillieRuemmele]

probably clean this at L11 up

[WillieRuemmele]

I don't see a major bump in pjson, or in commit messages - did I miss it?

[mdonnalley]

I don't see a major bump in pjson, or in commit messages - did I miss it?

This is going into the prerelease/beta branch which has the major version bump in it