external module import

[isakovarseniy]

jsweet-module.zip Hi In archive two project. Please run

cd project1
mvn clean install
cd ..\ project2
mvn clean install

Second run gives you an error

This is generated class from second project

/* Generated from Java with JSweet 2.0.0-SNAPSHOT - http://www.jsweet.org */
export class B {
    public method() {
        let v : A = new A();
    }
}
B["__class"] = "c.B";

As you can see class A is not imported.

I have analyze your code of class Java2TypeScriptTranslator. in method checkRootPackageParent you calling Util.isSourceElement

    public static boolean isSourceElement(Element element) {
        if (element == null || element instanceof PackageSymbol) {
            return false;
        }
        if (element instanceof ClassSymbol) {
            ClassSymbol clazz = (ClassSymbol) element;
            // hack to know if it is a source file or a class file
            if (clazz.sourcefile != null
                    && clazz.sourcefile.getClass().getName().equals("com.sun.tools.javac.file.RegularFileObject")) {
                return true;
            }
        }
        return isSourceElement(element.getEnclosingElement());
    }

in this case class name is com.sun.tools.javac.jvm.ClassReader$SourceFileObject

I am thinking to create my custom Adapter and extends your Java2TypeScriptTranslator. I can override method getRequireInfo. But this method is private. Can make it protected ? Another thing which need to be implemented is add prefix to library import

import  {x}  from <prefix>/q/A 

This also I can handle it from custom Adapter.

Thanks Arseniy Isakov

[lgrignon]

That would be nice indeed to have import prefixes/aliases.

I might give a look when I have time.

[lgrignon]

I create a separate issue for it

[renaudpawlak]

From what I understand, it should be possible to configure better the way imports are handled. Problably have specific prefixes depending on the lib being imported right? Extending Java2TypeScriptTranslator is possible in JSweet but you need to create your own factory. That's low level... It would be bad having to do this.

Possible "clean" solutions:

1. move the getRequireInfo in the adapter API
2. as suggested by Louis, have a more declarative way to configure prefixes...

Both solutions can work together. As a quick fix, I guess I would try to provide 1 ASAP.

[renaudpawlak]

Hey! I have added a PrinterAdapter.getModuleImportDescriptor that should allow you to tune the import statements the way you want. This is kind of experimental (just putting public some internals). I am still unsure it is the right way to go, so any feedback will be welcome ;)

[isakovarseniy]

Hi Do you have maven plugin for 2.0.1 ? I cannot find it in your repos http://repository.jsweet.org/artifactory/plugins-release-local http://repository.jsweet.org/artifactory/plugins-snapshot-local http://repository.jsweet.org/artifactory/libs-release-local http://repository.jsweet.org/artifactory/libs-snapshot-local

Thanks Arseniy Isakov

[renaudpawlak]

Sorry. I have just deployed Maven plugin version 2.0.1-SNAPSHOT.

[isakovarseniy]

Hi Actually it works pretty good. I manage to convert import modules like following: import { Query } from 'sql-dsl/com/octo/sql/query/Query'; import { Nullable } from 'sql-dsl/com/octo/sql/exp/Nullable'; import { Operator } from 'sql-dsl/com/octo/sql/exp/Operator'; import { SelectQuery } from 'sql-dsl/com/octo/sql/query/SelectQuery';

But there is another issue. During compilation it gives an error : couldn't find sql-dsl/com/octo/sql/query/SelectQuery seems it is not using tsconfig.json

{ "compilerOptions": { "baseUrl": "./", "paths": { "sql-dsl/": [".jsweet/candies/typings/META-INF/resources/typings/java-sql-dsl/0.1.1-SNAPSHOT/"] // This mapping is relative to "baseUrl" }, "module" : "ES6", "target": "ES6", "sourceMap": true }, "include": [ "target/ts//*.ts", "typings/*/.d.ts", ".jsweet/candies/typings/META-INF/resources/typings/java-sql-dsl/0.1.1-SNAPSHOT//*.d.ts" ], "exclude": [ "node_modules" ]

}

Thanks Arseniy Isakov

[renaudpawlak]

JSweet launches tsc with its own options. They probably override the ones found in tsconfig.json. Now that I see better what you are trying to do I am unsure that it is the right way to go.

Several remarks:

1. So far, candies use the @Module annotation to declare that they belong to a module that should be imported... when JSweet meets this annotation it automatically imports the right module. In think we should keep this way of doing things.
2. JSweet adds the candies typings automatically in the include option, so you don't need to do it. If you want to explicitly specify more d.ts files, there is an option to do so but I believe that this option was never made public.
3. What I don't understand is that including the d.ts is not sufficient to include modules. Modules should be ts files right?

As a conclusion, I believe that all this should be internally and automatically handled by JSweet.

As a first step, what I suggest is to try to make it work manually as you started to do. What you can do is to generate the TypeScript code only and manually compile it with tsc. You can simply use the tsOnly option.

Once you have a tsc configuration that works for you, we will be sure of what is required and we will have more information to automate it.

So could you please make it work with the tsOnly option and then send me your candy and the tsconfig.json file so that I can figure out what would need to be done?

Thanks!

[isakovarseniy]

Hi If I use tsOnly everything is fine. See archive with my projects.

1. Project "java" - java source code
2. Project "typescript" - candy
3. Project "test-typescript" - project which is includes candy

What I don't understand is that including the d.ts is not sufficient to include modules. Modules should be ts files right?

I think modules should be javascript file with definition "d.ts" file.

Thanks Arseniy Isakov test-modules.zip

[renaudpawlak]

Hi @isakovarseniy ! Sorry for very late answer. I just had the time to look at your project a little. Looks like a nice projet BTW.

So, first things first. I have installed the candy: cd typescript; mvn install Then I have removed the tsOnly option and tried to compile typescript-test and ran into the errors.

The first thing I don't understand is that JSweet runs tsc with a bundle.d.ts file (look in the tsc command of the log). That's not normal because it is using modules and should only include the files (there is no bundle here).

So it looks that there is an old bundle generated in typescript/src/main/resources/META-INF/resources/...... This bundle gets packaged in the candy. That a typical problem with how the candies pom.xml works. You need to delete manually typescript/src/main/resources/META-INF/resources/ each type you change the structure or version of the candy. My fault. There would be better ways to do it but did not have time yet.

So let's first fix it.

Second, once the code is generated with tsOnly, do you manage to compile with tsc? That would help to know the command you are using in that case.

I am running out of time for now but I will look closer again soon hopefully.

Thanks for your help!

[isakovarseniy]

Hi @renaudpawlak I have resolve all issues. Please take a look at my project on github This is link on my project https://github.com/isakovarseniy/tura . You need switch to version 4.3.0.

>cd platform/platform-ts/
>mvn clean install

ts-sql-dsl is project with code test/test-ts-sql-dsl project with test.

Take a look at pom files. I am running tsc and cleaning from maven. If you run mavin you can com across of issue which I have created under "jsweet-maven-plugin" project. issue #37 https://github.com/lgrignon/jsweet-maven-plugin/issues/37

I have fix this issue in my local code ( fix ix posted in #37). In this case you can run maven in "ts-sql-dsl " project then run maven for "test-ts-sql-dsl"

Regards Arseniy Isakov

[renaudpawlak]

Thanks @isakovarseniy. I am glad it is working for you with the tsOnly option. It is a good start for me to figure out what should be done to have JSweet working for the whole compilation workflow. I'll keep in touch but if anyone have insights on that topic, it is mostly welcome :)

[isakovarseniy]

I do not think you should change compilation workflow.You have 2 option:

1. Basic - when jsweet process everything
2. Advance (tsOnly) - in this case external tools will complete compilation and packaging. It is not your problem

Regards Arseniy Isakov