The README explains relative to the pdf_generator sources.

Though I’m not sure how that would help you when using it as a dependency.

Perhaps it is enough to just add those npm packages to your asset pipeline, but I’m not sure…

Perhaps open a ticket at the repository and ask there.

Thing with the <app>/assets directory is that this won’t get compiled into an erlang release using mix release. To get stuff in there you have to put it in the <app>/priv dir.

This is also what happens to your webpack builds (css and js). The assenbled/compiled result will end up in the /priv/static folder of your app. Take a look at _build/prod/lib/<your-app>_web/priv/static/ after running MIX_ENV=prod mix.compile && mix phx.digest - you’ll see js/app.js, csss/app.css and more.

The whole idea behind putting the chromium binary into priv as opposed to just assets is that the latter acts as the source for js/css compilation results. So it’s usually fine to have <app>/assets/node_modules in there as they will be compiled into priv/js/app.js after concatenation, tree-shaking, transpiling, scss-to-css conversion and whatnot.

But I need the binary as well.

And why all this?

I usually create releases with mix release and copy the resulting build from _build/prod/rel/<release-name>/ to the execution enviroinment, usually a docker container to be run in a Kubernetes cluster. Unfortunately/intendedly, stuff in <app>/assets won’t end up in there so on either has to install chromium there (the the CircleCI config) of package everything in the release (my idea).

But well, nothing stops you from just running MIX_ENV=prod iex -S mix phx.server on Heroku, or some VPS.

My current idea is to revert to a standard config and use Elixir’s release-assembling feature to copy the required binary over. Unfortunately this binary depends upon a gazillion of other thing ins node_modules which is why I ended up putting the whole node_modules dir there in the first place.