Hi All, I'm taking on a project to convert an app to using coldbox. I'm searching for docs and/or solutions regarding how you handle coldbox with your repo. Do you include your coldbox engine files into your repo or keep them outside in order for coldbox to be updated on each server environment separately? I was thinking that maybe we use commandbox to update cbox on each server or that maybe somehow CI does this in some controlled way. What are your recommendations? As I'm thinking, probably the box.json is meant for this to help in the updating for each environment as the box.json gets sent from one environment to another and auto-updated somehow, maybe by CI or is there a way commandbox watches for box.json on each environment? Searching for this on the web as well...

There are two ways to do it. The 'Commandbox way' says that you don't include either Coldbox or you rmodules in repo and just use

box.json

and then as part of your build process, you run

box install

and it just zaps all the modules and coldbox into place. We do not do this for a variety of little reasons: 1. You can't make a change to any of your modules (unless you fork it and store it on Forgebox such that you can

box install

your custom version - we have very few of these nowadays but it still happens that we need 'some module plus our changes' 2. It adds the dependency of Forgebox to your build process (not a big deal, it's pretty reliable) 3. It adds time to your build process while it installs everything, whether or not anything changed. So our modules and our coldbox dir are part of our repo. If we had a lot of little apps rather than one or two big ones we might do it differently. We might do it differently anyway down the road. But this works for us.

Thanks for your feedback, @sknowlton! That makes sense. For us, I can't imagine that we will need to modify any "plugin" modules and this app is rather small at the moment and am leaning toward using the commandbox approach. However, I am going to keep your thoughts in mind as this project progresses and if it gets to a point that we do have to do any customization, then I won't have a problem to easily include the cbox engine into the repo.

I include it in the repo too

I also find that

box install

will do nesting dependencies in what looks like a weird way but probably makes sense to people who aren't me, e.g. I get multiple copies of the same versions of the same modules, just nested under different module parents. The way we do it, we can blow away duplicate

str

or

qb

libraires and just have one of everything we need

oh wow. I wonder if there is a flag to turn nesting off?

I don't think so. I suspect it's something that can happen if your

box.json

version and the module's

box.json

version aren't exactly alike - even if you have what might, right now, be a good version, if I change my app's box.json, the module still needs the older version and I just broke it because I was making the module use my version and not its own version. This never happens to us in practice so we opt for manually handling the dependencies once a quarter or so when we review all this stuff.

That's happening alongside of having all of this in a repo?

No. That happens if you run

box install

. If you're keeping it all in a repo, the only time it happens is when you install a new module from commandbox

ah ok

It could happen with any module if the box.json versions don't match. We use almost entirely Ortus modules but a lot of them. Quick, qb, cbstorages, cfmigrations, hyper, cbvalidation, cbstreams, cbswagger, cbmailservices, sentry, str. A couple non-ortrus ones, like wkhtmltopdf (author is a jerk though) and stripecfml

hahah -> wkhtmltopdf

I can't wait for any html -> PDF enhancements. Didn't realize they were doing that. Hopefully a big improvement

Once we went to wkhtmltopdf we never looked back. I don't ever want a PDF engine integrated with my app engine again

I never quite got the hang of it. Guess I should have spent some more time on it. It would have let me switch to Lucee more easily, that's for sure. I have so many auto generated PDFs scattered between systems.

Yeah, we have a lot too. Fortunately they were all 'take this HTML and send it somewhere' so refactoring to use a wkhtmltopdf webservice versus the internal Lucee engine(s) was pretty mild

As I recall you'd have to call wkhtmltopdf via cfexecute? Only runs on the command line? Maybe I'll give it another look at some point

yeah, PDF Reactor uses all of the modern tech, including CSS3, HTML5, etc.

We run a tiny docker container that exposes it as a webservice and then use the wkhtmltopdf library (which is really just a fancy wrapper for hyper or cfhttp)

All of the alignments are operating as they should. Apparently, the old PDF engine was sometimes messing up the alignments and stacking text over each other.

@sknowlton Is the library wrapper webservice stuff on https://wkhtmltopdf.org/index.html? I must be missing that. Or is that something custom you did in house?

https://forgebox.io/view/wkhtmltopdf links to the docker webservice we use

right. ok. i'd wrap the calls in a CFC or something.

@sknowlton we have just been looking at html to pdf and not found much that is still maintained, seems the wkhtmltopdf project hasn’t seen much action for a long time. Been looking at using playwright as a service to produce pdf’s which works quite well (unless you have massive documents)

Interesting - we had to update the underlying libs for our web service not long ago so I wonder who was maintaining the docker image, because you're right, the github hasn't been updated since 2020. My Coldbox module could easily be adapted to be 'convert any stuff to pdf via a web service', it's not really unique to wkhtmltopdf since it just wraps your html in a request object and then returns a result from a webservice