updated code with all suggestions, I guess this feature should be mentioned in the docs, unless those are generated automatically...

by the way, I added this in during the constructor:

    assert(frontLayerBoxShadow == null || frontLayerBoxShadow!.isNotEmpty),

because this is your guy's project but I just gotta mention I disagree with the premise. This means the user cannot specify an empty list. but why not? Perhaps the shadow is variable dependent and therefore could result in an empty list during runtime. With this check the user must handle the empty list case and explicitly convert it to null.

Why is that more beneficial? Shouldn't the acceptance of the variable be as robust as possible to make things as easy as possible on the user of the library?

I'm just a mid level programmer so perhaps there's a best practice principle I'm missing out on here. But I figure if it adds no complexity why not make it robust?

@lastmeta valid point.
I think the frontLayerBoxShadow!.isNotEmpty was only taken over into the constructor because you previously had it inside the if-clause.

Probably it would suffice to only add assert(frontLayerBoxShadow == null) to the constructor. If the user sets a box shadow with an empty list, the front layer would be wrapped with the box shadow which wouldn't cause any UI change, right? Or does BoxShadow throw an error if the list is empty?

Or does BoxShadow throw an error if the list is empty?

it does not, so that would work, is that a change you'd like to see?

@lastmeta I just checked the code for BoxDecoration in flutter, it handles the null and empty case by it self. Therefore this checks on our end are unnecessary. I assumed you added this checks before BoxDecoration would not handle it.

Therefore, I would now suggest removing this checks - both from constructor and in _buildFrontPanel