As discussed on slack, I'd also suggest having a look at whether we can generate typescript types for the extension using something like https://github.com/OneOfOne/struct2ts or https://github.com/tkrajina/typescriptify-golang-structs. This would definitely improve the developer experience while writing scripts, regardless if the user is using typescript or not.

Originally posted by @simskij in #1 (comment)

This goes for all of the functions that take an options object: Should we provide some "sane" defaults in this case if a user omits the options object from the call? Or is the docker client already taking care of that?

Originally posted by @simskij in #1 (comment)

Maybe we should allow the user to configure this by supplying a config object as well and not strictly enforce config through env vars?

I'm thinking that if an object is supplied as the argument to the function, we should treat that as a client config object, if not - default to FromEnv. If we decide to go for this, it could be good if we also cover it with a unit test for each of the paths.

Originally posted by @simskij in #1 (comment)

Is it possible to pull/push images from/to private registries?

I understand it uses Moby Golang SDK and there is an ImagePullOptions parameter used to "basic-auth", but I struggled for the last few hours and all I get are unauthorized messages.

Here is a small snippet:

import images from 'k6/x/docker/images';
import encoding from 'k6/encoding';

export default function () {
  const registryAuth = encoding.b64encode(JSON.stringify({
    username: 'myUsername',
    password: 'myPassword'
  }), "url")

  const imageName = 'privateRegistry/myImage'
  const imagePullOptions = {
    RegistryAuth: registryAuth
  }

  const result = images.pull(imageName, imagePullOptions)

 console.log(`Image pulling result: ${result}`)
}

Is anything missing?

This case turned into a more difficult task as Docker API doesn't have "run" from the box.
So we should:

• Create container with custom command we have from "docker run"
• Start container
  It may be worth to pull the image if we don't have it as docker run does.
  The solution somehow should look like this:

/ RunContainer works as Docker run command
func (d *Containers) RunContainer(ImageName string, options container.Config) error {
	// _, err := d.cli.ImagePull(d.ctx, ImageName, types.ImagePullOptions{})
	// if err != nil {
	// 	panic(err)
	// }

	resp, err := d.cli.ContainerCreate(d.ctx, &options, nil, nil, nil, "")

	if err != nil {
		return err
	}

	if err := d.StartContainer(resp.ID, types.ContainerStartOptions{}); err != nil {
		return err
	}

	statusCh, errCh := d.cli.ContainerWait(d.ctx, resp.ID, container.WaitConditionNotRunning)
	select {
	case err := <-errCh:
		if err != nil {
			return err
		}
	case <-statusCh:
	}
	return nil
}

The xk6-docker extension has fallen a bit behind the minimum requirements for extensions to be listed in the registry:

• needs to be updated to at least v0.41

For Official extensions, we should have automated CI with linting enabled.