dzuvic / jtsgen Goto Github PK

the name space of the generated types could be shortened, e.g. by mapping a specific top level package to a shorter one or even to the root name space. The priority of this feature depends on usability of the IDE regarding imports.

Example:
`
declare module "exampleApi" {
export interface Order {
items: Array;
customer: Person;
}

}
`

and in package.json: instead typings use main

The easiest way for importing is to generate the output directly into the the client. Example:

import {Person} from "./api_types/exampleapi/example-api";

Note: this needs support for excluding a type by it's package, also. It's important because of the com.sun.misc.* Types

When using Kotlin and jtsgen classes with boolean members will not convert properly. Minimal example:

// Kotlin input
@TypeScript
class Foo(val bar: Boolean)

// Output
export interface Foo{}

Kotlin generates for bar the getter getBar(). A workaround is to provide a function isBar() as getter. Then the output is generated right.

// Kotlin input
@TypeScript
class Foo(val bar: Boolean) { isBar() = bar }

//Output
export interface Foo {
  bar: boolean
}

The name of this type misleading. It should be renamed to something like TypeMapInfo. It also represents a kind of type, but not a used one. During: #46

Private members with is-Getter are not generated in output file.

private boolean registered;
public boolean isRegistered() {
        return registered;
    }

• standalone cli executing javac and discarding the class files
• available in npm

Is it possible to add a "NO_MODULE" output type to the generator?

Inheritance is not working atm, could you please support it?

Only public types should be exported.

class attributes are exported as follows:

• if attribute is public
• OR: if public getter/setter are available

Getting jtsgen in a usable state user defined conversion has to be made possible:

• Some kind of plug-in: The user defines a class that the processor calls for conversion: that smells a bit over engineered
• additional parameter at the TypeScript annotation: easiest way to implement, but the user has to type this conversion every time
• add the conversion as annotation parameter:
• using a new annotation for defining a typescript module at package

since version 0.0.2 readonly values are supported. But i think it's done in a weird way, for instance: take a bean with finals and a constructor: currently all members are declared read only, but that is not correct in any way, because it depends on how the instance is created. I am not sure if it could be possible to extract that information without type annotations, which are not supported by the regular annotation processing api. Therefore the user should be able to override read only types.

There a several use cases having classes instead of interfaces:

• creating objects adhering a generated interface is a bit cumbersome (either using partial or filling up all values)
• sometimes it might be useful exposing constants
• the type guard should be a member of a class
• possibility to generate type specific default values

The mapping DSL has to be changed reflecting the default values of a type. The Default value should be changed by an TSOption Annotation

Since we are working with plain objects in JavaScript and not with class-instances we can't do typeof checks. TypeScript has a feature called Type Guards that can help you with that.

Example:

class Person {
  name: string;
  age: number;
  mail: string;
  optionalVal?: any;
}

const person: Person = {
  name: 'Can',
  age: 6,
  mail: '[email protected]'
};

const notAPerson =  {
  name: 'Can',
  mail: '[email protected]'
};
console.log(typeof person, typeof person === typeof Person); // --> 'object', false :(



// with a  'typeguard' function 
function instanceOfPerson(object: any): object is Person {
  return 'name' in object
      && 'age' in object
      && 'mail' in object;
}

// usage:
console.log(typeof person, instanceOfPerson(person)); // --> 'object', true :)
console.log(typeof person, instanceOfPerson(notAPerson)); // --> 'object', false :)

https://codepen.io/anon/pen/weJbEr

So it'd be nice to have a setting || annotation to enable the generation for instanceOfX functions.

User-Defined Type Guards - TypeScript Docs

TypeScript Deep Dive

The javadoc string should be included in the TypeScript output

It seems, that declaring a type conversion from java.lang.Number -> number is ignored for it's sub types, e.g. BigDecimal.

Input:

public class Test<T> {
private List<T> someList = new ArrayList<>();
public List<T> getSomeList() { return this.someList;}
public void setSomeList(List<T> someList) {this.someList = someList;}
}

should result in:

export interface Test<T> {
someList: T[]; // or someList: Array<T>;
}

Relevant for this: http://central.sonatype.org/pages/ossrh-guide.html

• have to renaming packges to com.github.dzuvic.jtsgen because of http://central.sonatype.org/pages/choosing-your-coordinates.html
• The group-id has also be moved to something like com.github.dzuvic:jtsgen-generator

I my opinion the name jtsgen is not a good one to remember, because pronunciation is a bit awkward. The new name should be

• short
• easy to pronounce

The Type Variable is not generated:

Example:

interface Bla<T> {
    val bla:Int
}

@TypeScript
interface BlaBla<T> : Bla<T> {
    val blabla:Int
}

Leads to

  export interface Bla<T>  {
    bla: number;
  }

  export interface BlaBla<T>  extends Bla {
    blabla: number;
  }

This is a follow up of #23

The following will lead to generating a lot of not needed Java Types:

@TypeScript
public interface Issue_46_Wrong_Java_Types<T extends Integer> {
    T getUpperBound();
}

According to that document jtsgen has to claim an unique namespace prior first deployment on maven central. Meaning: The package name has to correspond a controlled / existing domain name.

When using Jackson and the @JsonProperty annotation to rename properties, jtsgen generates interfaces with wrong name.

Example:

@Typescript
data class Foo(
    @JsonProperty("foo_bar") @get:JsonProperty("foo_bar") val bar: String
)

generates: interface Foo { bar: string }

• One test using sun.misc.Version testing exclusion.
• warning: Implicitly compiled files were not subject to annotation processing.

This is a followup of #28. Direct only type mapping should also be supported. But maybe this is not needed. At first a proper use case should be defined for this kind of mapping.

• The name space mapping list is prepended to the calculated one
• to override the name space mapping, a new name space mapping strategy is needed

Types that are not defined in it's own compilation unit are not extracted without a reference to an annotated class. Therefore

• Add a compile option adding these types
• Add a similar data structure to the TSModule annotation

the runtime scope of the generated maven pom is wrong:

    <dependency>
      <groupId>org.immutables</groupId>
      <artifactId>value</artifactId>
      <version>2.5.5</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>org.immutables</groupId>
      <artifactId>builder</artifactId>
      <version>2.5.5</version>
      <scope>runtime</scope>
    </dependency>

The following two mapping should be done i another way:

• a java.util.Collection<T> and its sub types should be mapped to T[]
• a java.util.map<K,V> should be mapped to list of a type {[key: K]: V}

For this the mapping DSL should be extended to the the following:

• the mapping DSL consists of two parts distinguished by an single arrow ->
• The left hand side is the canonical Java type with type parameters
• The right hand side consists of literals and type variables, where the converted type from the java will be inserted
• The type variables on the right hand side are escaped using arrow braces or back tick symbols. arrow braces are kept, back ticks are removed from the result

For example, when defining a mapping like this:

java.uti.Map<K,V> -> {[key: `K`]: `V`}

the an HashMap<String,Integer> will be converted to {[kex: string]: number}