CFC size seems to be a problem with lucee and apart from splitting the file into a series of includes, are there any other practices or advice that would result in this being less of a problem ?

This is probably most likely a design issue. Rather that split it into multiple includes, assess how much of the code in the CFC actually belongs together. I bet ya ten quid it's not adhering to the Single Responsibility Principle.

Thanks, but not helpful

Come again? You specifically asked "are there any other practices or advice that would result in this being less of a problem". The practice of following industry-standard design principles is precisely a solution to your problem. It's kinda why they exist. Its kinda why Java can figure "it's OK for us to have this ceiling on our class sizes, because it's more than likely anything going over this (pretty generous ~) threshold could probably benefit from a bit of refactoring". There is no answer that is "pass this setting to the compiler to get you off the hook", if that's what you are after. Your code has become too big. Make it more manageable.

Thanks, I'll keep that in mind

I dunno of any other approach. Like say "use CFML construct x instead of CFML construct y because that compiles to less byte code", I doubt there'll be much gain here even if you could work it out. And it doesn't sound like a great approach even if it was the case.

Lucee mentions something about not being able to split the CFC, like it's tried and failed for some reason, thought maybe there was a way to allow lucee to successfully split the CFC, like not using CFC variables or something

Maybe. It's probably the coupling between the methds. If there were some methods that didn't call each other, they could probably be separated into separate [things] under the hood. That's a total guess though, I've never seen that error so never had to troubleshoot it.

It's weird, because I have a script that puts every function into an include and then rewrites a copy of the original CFC to use those includes, and it all works fine, but it's a tough workflow to setup

Yeah includes are discretely compiled. It's really not a great design strategy compared with using separate CFCs though I'm afraid. It only addresses things from a LOC perspective rather than a concept (and LOC) perspective. I've not looked for ages but CF used to compile every function separately (so each function had the class-size threshold), and I can remember Lucee (or poss Railo) poopooing that idea.

How many lines are you hitting this issue at? I'm just curious.