feat(core,common): add help messages to REPL built-in functions

[micalevisk]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

same as PR #9692 but with other interface regarding REPL built-in functions

demo.mp4

What is the differences between them?

1. ReplContext is much cleaner. It doesn't have to deal with those built-in functions
2. no decorators (ie., no reflection)
3. Every built-in function will live in their own class and aren't aware (directly) of the others functions
4. To define our own 'built-in functions' we just need to implement classes that extends ReplFunction, and then we could pass a list of those class references to the main repl function (if we implement such feature in the feature). As of now, they will live along the native ones (help, debug, etc)

for instance, the get native function looks like this:

class GetReplFn extends ReplFunction {
  // metadata that describes the function itself
  public fnDefinition: ReplFnDefinition = {
    name: 'get',
    signature: '(token: InjectionToken) => any',
    description: 'Retrieves an instance of either injectable or controller, otherwise, throws exception.',
    // Optional list of aliases
    aliases: ['$'],
  };

  // The function to execute under the name `get`
  action(token: string | symbol | Function | Type<any>): any {
    this.ctx.app.get(token);
    // ^^^^^ ReplContext
  }
}

pros

• ReplContext got easier to maintain
• from nestjs user POV, I feel this API is much easier to follow and extend as there's no much magic happing. Users could write functions factories to build their classes easily

cons

• we could have naming collision (that I didn't handle in this PR)
• as the name is just an string, users could write invalid function names

Does this PR introduce a breaking change?

• Yes
• No

[micalevisk]

I didn't change the test suite because I don't know if this proposal we be taken 😃

[kamilmysliwiec]

Great work @micalevisk! Feel free to update tests, I'd love to merge this in :)

[micalevisk]

idk how to fix those failing assertions

[kamilmysliwiec]

As for the unit tests that are failing, I suppose there's a tabs/spaces/new lines mismatch between expected vs actual.

[micalevisk]

yeah, I didn't notice those trailing spaces. Also, I've moved the nested function under printCollection to a private method instead so it won't recreate a new one every time we use the debug function

[coveralls]

Pull Request Test Coverage Report for Build c33f096f-7875-4e22-ba67-59ad23501b92

• 87 of 92 (94.57%) changed or added relevant lines in 10 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.03%) to 94.122%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/common/utils/cli-colors.util.ts	0	1	0.0%
packages/core/repl/native-functions/debug-repl-fn.ts	22	23	95.65%
packages/core/repl/repl-function.ts	4	7	57.14%

Totals
Change from base Build a9d09da6-b7e1-45b9-8303-f0266c9e006a:	0.03%
Covered Lines:	5893
Relevant Lines:	6261

---

💛 - Coveralls

[micalevisk]

all done. I tried my best to write this in a way that it won't affect the bootstrapping time (without complicating the overall logic)

[kamilmysliwiec]

Fantastic contribution @micalevisk! 🙌