Redundant provider registered subcommands

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

Currently setup sub commands like followed by an example.

@SubCommand({
  ...
})
export class Sub {
  ...
}

@Command({
  subCommands: [SubCommand]
})
export class Main {
  ...
}

import { Main } from './main.command'
import { Sub } from './sub.command'

@Module({
  providers: [Main, Sub]
}) 

If we multiple nested some commands, every time must add them as providers to top module, and it looks redundant.

I always hack with spread operators

export const subcommands = [SubCommand]

@Command({
  subCommands: subcommands
})
export class Main {
  ...
}

import { Main, subcommands } from './main.command'

@Module({
  providers: [Main,  ...subcommands]
}) 
export class AppModule {
}

but, even if using these manner, nested commands tough to manage by this.

Describe the solution you’d like

I suggest static register method in Command class and SubCommand class. This return [selfClass, …subcomand.regsiter()] which recursive register subcommand register method results. Then set module’s provider like that.

@SubCommand({
  ...
})
export class Sub {
  ...
}

@Command({
  subCommands:  [SubCommand]
})
export class Main {
  ...
}

import { Main } from './main.command'

@Module({
  providers: Main.registerCommands() or [...Main.registerCommands()]
})
export class AppModule {
}

Teachability, documentation, adoption, migration strategy

This is not breaking changes because we can choice whether we use this method.

What is the motivation / use case for changing the behavior?

For effective reducing codes.

[jmcdo29]

I know I originally said that I probably wouldn’t add this in, but looking at the simplicity of the implementation and how it can be helpful, so long as it’s clear what the method does and it’s well documented, I think it would be fine to allow this. I’ve left a few comments on your PR.

[tkow]

@jmcdo29 Oh, sorry, I implemented this before I checked your reply.

I often use structure nested directory and not flat like

   --user/(barrel)index.ts,command.1.ts,command.2.ts 
   --post/(barrel)index.ts,command.1.ts,command.2.ts 
   --review/(barrel)index.ts,command.1.ts,command.2.ts

and they sometimes make me nervous if we use more nested commands in nested directories about how we know to export which commands though it can reduce complexity with barrel files. Though it doesn’t match your philosophy, but it can opt in and not influence other codebase. the usage is as hatch. In addition I couldn’t imagine the case we want to exclude subcommands set in metadata from providers.

I don’t think it’s something I want to add to the library

If you do so, it’s okey for me, I’ll inherit your CommandRunner Class as you say. Thank you and sorry for spending your time.