0.0.19

• Namespaced aliases lost in translation
• Correct escaping for entities in heritage clauses, constraint params
• Any toString method with no parameters is override
• Generic params information is lost for lambdas in types
  Support for generic params with default values pointing to some other generic params

0.0.18

[0.0.18] - 20'September, 2019

Starting from this release generated files names will
match following pattern:

[file_name].[packageName]?.[module_name]?.[additional_postfix]

For instance, let's say we have file foo.d.ts in fooController package,
and following file is generated: foo.helpers.module_fooController.kt.
Then we know that the original file was called foo.d.ts, the file itself
belongs to the package "helpers" and npm module is fooController.

• Module name resolving is based only on existence of package.json and its content (DUKAT-1 and DUKAT-4)
• Losing part of generated files because of the name clash
• Generated entities name clash, case-sensitivity related
• [regression] -r (build report) command-line flag behaviour fixed
• Batch mode removed completely - it was used for dev purposes only and in it's current form proved to be quite inefficient

0.0.17

This release contains mainly idl-related changes. The idl target is considered production-ready, however its support is still experimental.

0.0.14

Just like 0.0.13, this release is dedicated for further idl improvements and preparations for introducing nodejs-backend which will increase significantly the speed of typescript translation.

The only ts-related change is that if there's a default export in the file a global JsModule annotation is added if it wasn't there.

0.0.13

This release includes mainly WebIDL-source translation changes (which is still an early alpha), that is:

• support for translating dictionaries, nullable types, array types and parameter types.
• support "implements" statement.

The other thing worth to mention is that "Unit" return type is not translated anymore (anywhere except lambdas of course), so that you won't be annoyed with "Redundant 'Unit' return type" anymore.

0.0.12

No more target name clashing

Package name (if found) is added as a prefix to the name of the translated entity
This means that you finally can pass multiple files in different npm modules at the same time.

before:

$ dukat  node_modules/left-pad/index.d.ts node_modules/\@types/range-parser/index.d.ts 
index.kt
index.kt  <--- it's a clash!
index.RangeParser.kt

now:

$ dukat  node_modules/left-pad/index.d.ts node_modules/\@types/range-parser/index.d.ts 
left-pad.index.kt
range-parser.index.kt
range-parser.index.RangeParser.kt

Web IDL improvements

Web IDL translation is still in early alpha and incomplete. In this version, however, support for typedefs in inheritance declarations is added

Bugs

#73 - Union type unrolling is broken when it's aliased in a referenced file

0.0.11

This release was dedicated mainly for internal improvements that will make it easier to both introduce new source languages and fix the bugs we are aware of and thoroughly collecting.

As of such new targets - we gradually starting to merge idl-related functionality but a lot of thing to be done to call it even alpha.

Starting from this release the hiatus like one that happened between 0.0.10 and 0.0.11 is no more and we are back to "big" release each Fridays and smaller one each Tuesday.

0.0.10

In this release #56 is fixed - this was a bug that occurs when some entity in subpackage is inheriting from a parent with no package declaration at all - since dukat by default does not add any package to the parent file this was quite common thing to occur.

Since this release only files with *.d.ts extension are processed. After all, it is the way it is supposed to be in a typescript world and there's absolutely no reason to try to parse arbitrary *.ts file.

Other important bug fix is that type aliases are moved out from files with file-level JsQualifier and JsModule annotations (see #41 for more information)

TypeScript dependency updated to 3.5.2
Graal-SDK updated to 19.0.0

0.0.9

In this release there's only two things worth to mention. First, a bug with renaming variables in non-external modules has been fixed, second - definedExternally are removed everywhere where it possible to remove them, so that generated code became way more readable.

0.0.8

This release was dedicated to a single main issue - that is, resolving JsQualifier and JsModule inconsistencies. It became definitely better than it was in both ts2kt and [email protected].

Consider following example:

declare function leftPad(str: string|number, len: number, ch?: string|number): string;
declare namespace leftPad { } 
export = leftPad;

Before this release export annotations were missing so declarations generated were of no use before manual editing. Now one will get just:

@JsModule("left-pad")
external fun leftPad(str: String, len: Number, ch: String? = definedExternally /* null */): String = definedExternally
@JsModule("left-pad")
external fun leftPad(str: String, len: Number, ch: Number? = definedExternally /* null */): String = definedExternally
@JsModule("left-pad")
external fun leftPad(str: Number, len: Number, ch: String? = definedExternally /* null */): String = definedExternally
@JsModule("left-pad")
external fun leftPad(str: Number, len: Number, ch: Number? = definedExternally /* null */): String = definedExternally
@JsModule("left-pad")
external fun leftPad(str: String, len: Number): String = definedExternally
@JsModule("left-pad")
external fun leftPad(str: Number, len: Number): String = definedExternally

Exactly what's expected.
Attentive reader might have have noticed already that the name of module is actually something that we can not derive in this case from the content of the source file (or from the name of the source file to that matter).
Indeed, in order to do so we have to introduce some rules, to simplify - there are actually two thing worth to know about:

• If the source file is in node_modules and is a valid npm package - we'll try to get name from package.json
• If source file is not in node_modules - no annotations would be added unless one will specify new CLI flag -m.

In fact -m can be used to override nodejs resolution as well.

Just like always - enjoy, use, report bugs and make feature requests!