You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A great idea presented by Mtuchi, which I really like, is to be able to use @openfn/cli to get help about adaptor functions.
Something like this:
openfn -a language-http -h get
Details
This is basically modelled on iex -h which reports help information about elixir functions.
An ideal solution would be to:
Print a one-sentence description of the function, the signature and an example
Also print a hyperlink to online documentation
Implementation notes
We need to work out the format of the help question. You have to input the adaptor name and a function - so is that @openfn/language-http.get or language-http/get or even -a language-http -h get.
That last one is the most consistent, because it uses a standard command to input an adaptor (which can accept an inline path to a local package), and a simple help command which takes a function name and nothing more.
When we move all the adaptors into the monorepo, we'll be streamlining all the help docs and making sure they'er in one place with predictable URLs. So generating a printing a URL to the help docs is pretty easy.
What about the help itself? The CLI needs to intelligence to look in the adaptor's package, read the type definition for the required function (either straight from the dts or from the ast.json), and massage it into a nice, standard format for the CLI.
Because we want to optmise the formatting for the CLI we want to read fairly low level data and generate output, rather than just dumping an existing string (or even HTML string)
The text was updated successfully, but these errors were encountered:
User story
A great idea presented by Mtuchi, which I really like, is to be able to use
@openfn/cli
to get help about adaptor functions.Something like this:
Details
This is basically modelled on
iex -h
which reports help information about elixir functions.An ideal solution would be to:
Implementation notes
We need to work out the format of the help question. You have to input the adaptor name and a function - so is that
@openfn/language-http.get
orlanguage-http/get
or even-a language-http -h get
.That last one is the most consistent, because it uses a standard command to input an adaptor (which can accept an inline path to a local package), and a simple help command which takes a function name and nothing more.
When we move all the adaptors into the monorepo, we'll be streamlining all the help docs and making sure they'er in one place with predictable URLs. So generating a printing a URL to the help docs is pretty easy.
What about the help itself? The CLI needs to intelligence to look in the adaptor's package, read the type definition for the required function (either straight from the dts or from the ast.json), and massage it into a nice, standard format for the CLI.
Because we want to optmise the formatting for the CLI we want to read fairly low level data and generate output, rather than just dumping an existing string (or even HTML string)
The text was updated successfully, but these errors were encountered: