Cooperation with plantuml-parser?

[Enteee]

I am the maintainer of tplant ^ -1 or in other words plantuml-parser 😃 . I do think it would be very beneficial for users if we could somehow make our two projects compatible with each other. Meaning if code could be transpired to a diagram using tsplant and then back to code using plantuml-parser.

In this issue i would just like to check if you'd see value in a collaboration. And maybe discuss possible next steps.

[bafolts]

The generated plantuml should work fine as input to any tool. What would have to be change for plantuml-parser?

[Enteee]

Well I currently don't generate any TypeScript from plantuml, but before I start implementing this (Enteee/plantuml-parser#36) we should maybe establish and agree a few rules. On top of my head, there are more things:

• how do you express:
  • inheritance --|> ?
  • implementation --> ?
• What do you do with composition links and how do they look like?
• how do you identify types and strings map to what type?
• what do you do with comments, do you create notes?

...

and I bet there are many more things. As a starting point I'd say it would make sense to implement a unit test in both projects which does code -> diagram -> code and then runs a few basic tests on the finial code. Just to ensure compatibility.

[bafolts]

I have another project which I think is similar to yours:

https://github.com/bafolts/plantuml-code-generator

Shouldn't the grammar of plantuml-parser support any inheritance format? This would avoid having to restrict this tool from generating a certain inheritance format.

[Enteee]

Shouldn't the grammar of plantuml-parser support any inheritance format? This would avoid having to restrict this tool from generating a certain inheritance format.

I don't understand what you mean with any inheritance format. Does you mean with this that no matter what arrow body every arrow with a |> must express inheritance? So what should the following do then:

A <|--|> B

or even worse:

interface A
A -|> B 

I had a look at the grammar of your other project and you only support a small subset of what plantuml is actually capable of. Which makes sense. But also means in order to maintain compatibility we would need to agree on the same subset.

[bafolts]

By any inheritance format I mean any valid plantuml that can be used to represent inheritance. Whatever format tplant is using today wont change. If you use the format it is generating today that should work fine.

[paduc]

@Enteee I'm also interested in plantuml => typescript => plantuml generation/parsing.

My use-case is reduced in scope as I want to create / update the boilerplate for a DDD design system.

I think it would be appropriate to create a new project/repo, which would use both tplant and plantuml-parser and create the glue to handle the sync.

I'm ready to contribute if you do so.

[Enteee]

@paduc I think writing a plantuml formatter is probably the most robust thing to do to get plantuml => typescript. @bafolts has an other project which does plantuml => typescript already. But I don't know if @bafolts 's two projects supports the full plantuml => typescript => plantuml story.

[paduc]

@Enteee after putting more thoughts into my goal, I believe I'm going to need something more complex than plantuml => typescript => plantuml as I need to include generation rules that fit my desired project format. I need to sync a PlantUML model with several classes located in several files in several directories (including import statements, etc.).
This would be outside of the scope of generic generators/parsers like tplant and plantuml-parser.

FYI I'm considering using angular-devkit schematics to handle that logic.