Customize asset bundling execution

[eladb]

We should offer a way for users to customize how docker is executed during asset bundling at the app level in order to allow users that can’t use docker to leverage bundling.

Use Case

Asset bundling relies on docker to offer a ubiquitous experience for library consumers (see “why we use docker” below). However, running docker in some environments is a major barrier or even not allowed.

As an escape hatch, we should allow users at the application level to override the way docker is executed so they can still use asset bundling in their systems.

Proposed Solution

Introduce some inversion of control when executing the various docker commands during bundling.

This is something that should be done (only?) at the app level since it’s about the specific synthesis environment and it should not be possible for libraries to override this behavior given their don’t know what the synthesis environment will be.

I wonder if it is sufficient to simply say “docker is in PATH and you are welcome to simply provide your own docker command that does whatever you want as long as it respects the contract.”

Another alternative is to defer to an environment variable such as CDK_DOCKER if it is defined.

Why we use Docker?

Consider the use case in which an app consumes a third-party library which leverages asset bundling (like NodeJsFunction) under the hood (or even multi-level deep).

This app doesn’t even know that somewhere in their dependency graph, someone wants to bundle a Nodejs library with Parcel, let alone interested in setting up their dev and build environments to include these tools.

Docker offers a way to abstract this completely. Granted - this app will need docker available during synthesis, which I could be a barrier in some environments, but once they have docker, they can use any construct library.

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[eladb]

@jogold what do you think?

[jogold]

I wonder if it is sufficient to simply say “docker is in PATH and you are welcome to simply provide your own docker command that does whatever you want as long as it respects the contract.”

Do you expect docker not to be available in PATH or the bin to have a different name? Do you have examples of "docker compatible" CLIs?

[eladb]

Do you expect docker not to be available in PATH or the bin to have a different name? Do you have examples of "docker compatible" CLIs?

The idea is not to replace docker as docker but rather to work around the fact that docker is missing. For example, if I know I want to use the lambda Parcel bundler, I can directly install parcel in my build environment and instead of running the docker command inside a container, I can just run it as is.

[jogold]

OK got it!

The naive approach is to skip docker build (if any) and simply run the command of docker run in the current shell (doesn't work if the command is defined in the container)? How would users "discover" what dependencies they need for this to work outside docker?

[eladb]

How would users "discover" what dependencies they need for this to work outside docker?

They will just tailor their shim based on the use case. For example, they can explore the source of the docker image in Docker Hub and install those dependencies in their environments. Case by case.

[eladb]

@jogold I am going to make this change. I'll send a PR for a review.