You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have schema files in different directories, the generated Kotlin code (and I assume Java) works as expected. So a structure like:
# tree schema
schema
├── common
│ └── header.schema.json
└── messages
└── chat-message.schema.json
With the Gradle plugin pointing at schema directory produces two files com/package/name/common/Header.kt and com/package/name/message/ChatMessage.kt with the latter correctly importing Header with import com.package.name.common.Header. TypeScript classes have the same (correct) layout but with import statements that assume all classes are in the same directory:import { Header} from "./Header". Unfortunately, there doesn't seem to be a magical set of package.json/tsconfig.json options that fixes module resolution.
I doubt my project will ever actually have multiple classes with the same name, so I just moved everything to the same directory/package. It would still be nice to fix this if only so for feature parity between the target languages.
I'm new to TypeScript and I'm not sure what's the best way for the generated files to refer to each other. My inclination is:
Store imports in Target.kt as both a list of fully qualified class name strings and as a list of lists; where each sublist is each package in the fully qualified class (i.e. ["com.package.name.common.Header"] and [["com", "package", "name", "common", "Header"]]).
Add an import prefix configuration setting for TypeScript files. I expect setting a custom import prefix pointing to the base directory of the generated files. Combine this configuration value and the sublist with '/' as the import path.
If set to #schema generate imports as import { Header} from "#schema/common/Header" and would require something like { "imports": { "#schema": { "import": "path/to/where/generated/typescript/lives" } } } in package.json.
Let's also say if unset, the existing import behavior is used. If your schema all live in the same package nothing changes; if in different packages you need to change your configuration.
Alternatively, store the fully qualified path of each target and compute the relative paths between each itself and its imports. That's not a complex algorithm, but it is more complicated than using quasi-absolute paths of 2. However, it would not require any configuration by the user.
The text was updated successfully, but these errors were encountered:
If you have schema files in different directories, the generated Kotlin code (and I assume Java) works as expected. So a structure like:
With the Gradle plugin pointing at schema directory produces two files
com/package/name/common/Header.kt
andcom/package/name/message/ChatMessage.kt
with the latter correctly importing Header withimport com.package.name.common.Header
. TypeScript classes have the same (correct) layout but with import statements that assume all classes are in the same directory:import { Header} from "./Header"
. Unfortunately, there doesn't seem to be a magical set of package.json/tsconfig.json options that fixes module resolution.I doubt my project will ever actually have multiple classes with the same name, so I just moved everything to the same directory/package. It would still be nice to fix this if only so for feature parity between the target languages.
Kotlin's mustache templates use fully resolved imports and TypeScript does not. It looks like the imports list is the fully qualified Java class name so it can't be reused for TypeScript.
I'm new to TypeScript and I'm not sure what's the best way for the generated files to refer to each other. My inclination is:
["com.package.name.common.Header"]
and[["com", "package", "name", "common", "Header"]]
).#schema
generate imports asimport { Header} from "#schema/common/Header"
and would require something like{ "imports": { "#schema": { "import": "path/to/where/generated/typescript/lives" } } }
in package.json.The text was updated successfully, but these errors were encountered: