Paweł Niedzielski

@makasim can you look at #30 and, if there are no issues with it, merge it so we can work on it enqueue-dev?

> Than a serializer is bound to transport, and if you switch from one to another the code will break. I'd say it's user's responsibility to select and attach correct...

In my opinion, since this is an interface only, there should be nothing about how `Producer` handles `Message`s. How serializer is attached (or if it event relies on it) should...

What is the state of this PR? @Sevavietl will you continue on it, or you don't have the time?

As shown by the tests, this will break `docker-compose` 1.x usage. We will need to decide on an approach for this. Probably a configuration option? I don't really feel we...

It's not a PR though :) At this point it doesn't seem to differ too much. Looking forward to it. Just a note: since we're still "supporting" NodeJS 6 (which...

@KenEucker you can see it being tested here: https://github.com/PDMLab/docker-compose/blob/dd4fe76eab0eddb273f5f4dc9981408588166095/test/index.test.ts#L194-L202 In most cases if your promise is not executed, it's because the calling code was not adjusted for async execution. For...

@KenEucker to be honest, I have no idea. If you look into the source code all we do is wrap the process of `docker-compose` and wait for it to exit:...

> I am not making any calls to process.exit, this code executes upon SIGINT. The 'exit' event code that you linked is also never reached when calling .down. Does the...

> @Steveb-p the process doesn't hang, it just "exits" that async method, almost as if the promise resolved, and continues executing the lines after "bringItDown" is called. This for me...