Export dockerCompose type so consumers can store it in a variable and call Down

[mdelapenya]

No description provided.

[jasonyunicorn]

@mdelapenya I'd like to volunteer to pick this up.

[mdelapenya]

@jasonyunicorn please do it 🙏 If you don't know where to start, please open the initial PR in draft and we can iterate/discuss around it.

Thanks for volunteering!

[jasonyunicorn]

I created a PR which exports the DockerCompose type, but @stevenh has brought to my attention that this isn't necessary, since the exported methods on dockerCompose can still be accessed.

Should this Issue (and PR) be closed?

[KenjiTakahashi]

I'm not a maintainer, but a user interested in this.
I'd say if the API exposes a function that returns the type (in this case NewDockerCompose* return *dockerCompose), this type should also be exposed.
Otherwise it is not possible to pass returned instances to other functions or store them in structs. Generally use them in places where specifying the type is necessary.
[Another way of handling this would be to create an interface and expose/return that instead, if it is not desirable to expose the struct directly. Don't think it is necessary here, but up to you.]

Edit: This is even considered a "warning" in the revive linter: https://github.com/mgechev/revive/blob/master/RULES_DESCRIPTIONS.md#unexported-return.

[xbc5]

@KenjiTakahashi @mdelapenya @jasonyunicorn

dockerCompose satisfies the ComposeStack interface.

func New() (tc.ComposeStack, error) {
	return tc.NewDockerCompose("...")
}

[stevenh]

@KenjiTakahashi is right, returning private types is a code smell.

If we update the reason for the PR to address that instead of the current reason, happy to accept that.