Open jcurtis-cc opened 1 year ago
Hm Interfaces / Classes can be in arbitrary named files not linked to the class name itself
Working Example: https://github.com/demike/TsUML2/blob/28c56177bf692fd5baf1c56970dec2b087fd62ca/src/demo/interfaces.ts
The error you see is related to the link creation for the svg elements. Is the target svg outside of the project tree?
Because this would result in an error when creating a relative path. This feature is ment for documentation purpose where the resulting svg is part of your docs (inside the project/repo)
@jcurtis-cc can you post the full error string? So that I can see the id of the class/interface that produces the error?
In my case the problem was when I use alias (as) to resolve name conflict, besides of that I got "out.svg" on my root folder.
Ok I can check the 'as' problem but I am not shure about the out.svg on root folder problem
@demike Hello, I am sorry about writng here, but is there any way to chat you privately (some questions)? It is related with node-opcua, websocket support, and your PR.
In my case the problem was when I use alias (as) to resolve name conflict, besides of that I got "out.svg" on my root folder.
@lesimoes where did you use the alias. For a base class
class SomeClass extends Alias {}
or
class SomeClass implements Alias {}
or as an attribute ( this should work tried it in the examples):
class SomeClass {
a: Alias
}
or ...
in my case there were only enums without export directly but using export default with a different name. Can i help somehow? Great Lib btw, I appreciate your effort in doing it.
@TheoOliveira it would be great if you could provide an example that reproduces this behaviour. Debugging the problem should be easy then.
I can confirm this occurs when not exporting an interface within a file that consumes it. Exporting that interface, even if I don't consume it anywhere else, "fixes" the issue. Setting typeLinks to false also removes the error.
@circlenaut thanks for explaining the error. I think I have fixed your specific issue in version 0.12.1. Would be great if you could try the new version.
@TheoOliveira does version 0.12.1 improve / fix your scenario?
Seems that classes and interface definitions are expected to be in single source files named by
id
. While this is good practice - this is not always the case, could this logic be expanded to link to the parsed source file - irrespective of whether it matches theid
?https://github.com/demike/TsUML2/blob/master/src/core/model.ts#L65