Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: typed output of commands #95

Closed
LarsKumbier opened this issue Sep 25, 2019 · 1 comment · Fixed by #143
Closed

Enhancement: typed output of commands #95

LarsKumbier opened this issue Sep 25, 2019 · 1 comment · Fixed by #143

Comments

@LarsKumbier
Copy link
Contributor

The current implementation exposes very low-level information on the result of a command with the interface

export interface IDockerComposeResult {
  exitCode: number | null;
  out: string;
  err: string;
}

This has the disadvantage of leaving the interpretation of the output to the user, leading in a lot of boilerplate code that all users of docker-compose have to write. Instead it would be better to provide more introspective into the result by typing it:

export interface IDockerComposeResult<T> {
  exitCode: number | null;
  out: string;
  err: string;
  result: T | null;
}

This should be given for every mapped subcommand of docker-compose. An example for the port subcommand:

interface IDockerComposePortResult {
  address: string;
  port: number;
}

If an error occurs, the result should be null, since the error output will already be present in the err key.

We should use github's project to track, which subcommands have already been enhanced.

Originally posted by @stefanmeschke in #52 (comment)

@AlexZeitler
Copy link
Contributor

@LarsKumbier

We should use github's project to track, which subcommands have already been enhanced.

Would you use notes for each subcommand or use this issue and add a todo list to it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

2 participants