feat(core,common): add helpers messages to REPL built-in functions #9692
Conversation
| @@ -12,6 +53,7 @@ export async function repl(module: Type) { | |||
| }); | |||
| await app.init(); | |||
|
|
|||
| const ReplContext = CoreReplContext; | |||
There was a problem hiding this comment.
now we can parametrize this ReplContext variable (so users could write their own 'native functions'), falling back to CoreReplContext
I didn't implement that feature in this PR because I think it would be better to wait for requests instead of implementing something that no one will use. Also because the interface of ReplContext might not be well defined yet
Pull Request Test Coverage Report for Build 3a4ee23c-cb6b-4f16-aef0-5c9ab7d3cc4c
💛 - Coveralls |
| return this.app.select(token); | ||
| } | ||
|
|
||
| debug(moduleCls?: Type | string) { | ||
| @ReplFn(makeReplFnOpt('', '(moduleCls?: ClassRef | string) => void')) |
There was a problem hiding this comment.
@kamilmysliwiec please help me on writting a description for the debug function
There was a problem hiding this comment.
@micalevisk, an idea but take it as a "draft":
Allows you to process the identification of the problem in stages, isolating the source of the problem and then correcting the problem or determining a way to solve it.
micalevisk
changed the title
micalevisk
force-pushed
the
feat/repl-improvements
branch
2 times, most recently
from
1150706
to
9484d3a
Compare
|
I'm not 100% sure on the interface I've implemented to register those built-in global functions, tho. I mean, feels like |
micalevisk
force-pushed
the
feat/repl-improvements
branch
from
9484d3a
to
103bad9
Compare
|
I think the approach proposed here #9695 is somewhat cleaner |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
No built-in helpers on current version of REPL feature (that will be added on #9684).
No way to find out what are the functions available to use for the NestJS app
What is the new behavior?
Users can call
help()to view all the available 'native functions' (in an alphabetical order). I call them functions because commands are those displayed when we type.help(and registed byreplServer.defineCommand)Users can type
<function>.help(eg:methods.help) if they want to find out what a 'native function' could do (their description and function's signature, which follows the TS function type expression)Note that aliases should appear after the original function due to how
@ReplFn()is evaluated. Supporting the out-of-order definition for function aliases looks trickier but it's feasiable.Demo:
demo.mp4
(up-to-date version of
help()output:)Also,
delete <function>.helpor<function>.help = () => {}won't take any effect on the originalhelpgetter.Does this PR introduce a breaking change?
Other
The only issue with in-repl docs is that the typings could be vague (for instance,
ClassRefisn't a valid type from@nestjsbut I feel it's better thanTypefor those who don't knowType). But at same time, having then right on in the REPL will improve DXWe can call
<function>.help()but we would get anUncaught TypeErrorbecausehelpis not a function. I don't know how to prevent that error while allowing both.helpand.help()usages.