We're exposing the parameters in our DiagramOptions directly.

A curious decision given that skinparams are only applicable to PlantUML diagram exports. You will need to deprecate this anyway because PlantUML has itself deprecated skinparams.

Do you think there's a way to get skin parameters to work on 5.0 at all?

I don't. Paste the following diagram source into PlantUML and you'll see that the skinparam has no effect given the rest of the diagram definition uses the new CSS-like styles mechanism.

@startuml
title <size:24>System Landscape View</size>
set separator none
top to bottom direction
hide stereotype
skinparam RectangleBackgroundColor red
<style>
 root {
 BackgroundColor: #ffffff;
 FontColor: #444444;
 }
 // Element,A
 .Element-RWxlbWVudCxB {
 BackgroundColor: #ffffff;
 LineColor: #f88728;
 LineStyle: 0;
 LineThickness: 7;
 RoundCorner: 20;
 FontColor: #f88728;
 FontSize: 24;
 HorizontalAlignment: center;
 Shadowing: 0;
 MaximumWidth: 450;
 }
</style>
rectangle "==A\n<size:16>[Software System]</size>" <<Element-RWxlbWVudCxB>> as A
@enduml

Remove the <style> block and you'll see the element background is set to red. I have found a few skinparams that still work (e.g. skinparam monochome true), but there's really no use case for them any more because the styles take precedence over skinparams.

A curious decision given that skinparams are only applicable to PlantUML diagram exports. You will need to deprecate this anyway because PlantUML has itself deprecated skinparams.

I am totally fine with that. It's just that with the current state of affairs, I can't do that, as on 4, the new approach doesn't exist yet, and on 5, the old approach doesn't exist anymore.

Just to make sure we're not talking past each other: what I am looking for is being able to ship a version in which I can say, "skin params are deprecated; please move to the new approach," but skin params are still being applied as before, unless folks move to the new style approach, in which case, of course, skin parameters would not get applied anymore. I.e. I do not expect both configurations to work at the same time. I only want to give developers the ability to upgrade to a version that does not immediately break their project.

Looking at AbstractPlantUMLExporter in 5, it looks like I should be able to overwrite writeHeader(...) and re-introduce the skin parameters in my extension as they existed in 4. I could also log a deprecation warning and handle them in an if-else way so that the approaches are not used at the same time. Let me give this a try and report back my findings.

Looking at AbstractPlantUMLExporter in 5, it looks like I should be able to overwrite writeHeader(...) and re-introduce the skin parameters in my extension as they existed in 4.

You should be able to do this, yes, but you'll likely find that any skinparams specified won't do anything (see my example in the previous comment). I don't think there's a middle ground unfortunately - you can have PlantUML with skinparams (structurizr-export v4) or PlantUML with styles (structurizr-export v5), but both don't seem to be able to co-exist ... AFAIK with my limited knowledge of PlantUML.

I will ask my previous question though - do you have any examples of how the additional skinparams are being used by your users?

Yeah, I don't think that's a too bad idea. I have a local fix on my side that simply adds back the skin params post the writeHeader(...) implementations of their respective base classes. That allows me to ship 2.0 today and still upgrade to Structrizr 5 for that and take of the time pressure from your side. I guess we'll have to continue to monitor the PlantUML space regarding how they plan to move certain skin parameters over going forward.

Thanks for your time! 🙇

You're welcome - that's done and is releasing now.