Closed rgladwell closed 3 years ago
@rgladwell Would it be possible to have the code which fails to transpile please? Could you also please confirm this works with JSweet 2?
I will add unit tests to cover your case. Thanks
It's failing with that exception in many places, one such place is here:
Unfortunately, I can't tell if it was failing in JSweet 2 because the previous compiler issues may have concealed this bug.
Okay, it seems like a huge code base and if JSweet 2 did not manage to transpile it, JSweet 3 won't.
I will try to clone itext repo and see how many errors pop in, but there might be too many things to change / fix.
For instance, I guess itext relies on external jar dependencies, which cannot be supported in JSweet except if you already have a JS runnable version
Indeed, itext7 kernel depends on Java library https://github.com/ink-elements/itext7-js/blob/master/itext7/kernel/pom.xml#L16 which cannot be transpiled to something runnable in JS
Did you have something in mind for this?
This code base would not transpile in JSweet 2 because of previous bugs which I believe were only addressed in JSweet 3.
The library only has a logging dependency which I already mocked for JSweet:
https://github.com/itext/itext7/blob/develop/pom.xml#L134
I also stripped out the encryption parts of the library. I'm in the process of fixing bugs, removing dependencies and consolidating the code base until this transpiles
But I feel this is orthogonal to the NPE being thrown. I suspect it would be an issue even for smaller code bases.
It already sounds like this is a wont-fix for this project. Could you please clarify?
Hello @rgladwell There are 2 things:
1) You hit something that looks like a bug, so we will do everything we can to try to fix it, but it would be better to have a small repro to analyze it. I will make some tests today to isolate a small repro but I can sense it won't be reproducable easily, and then, try a blind null safe fix if I cannot get anything else.
2) Transpiling the itext7 codebase: I am very glad that you work on this because that's exactly what JSweet is for. Unfortunately, it seems that there are still some unsupported side cases, or dependent libs which would require some work on your side. I get that you are working on it so that's perfect, we can go step by step and enhance what JSweet cannot do yet (because there are still gray areas) and fix what's just failing.
One thing I want to add is that the NPE we get can result from a codebase with unrecognized dependencies. That's why I checked it yesterday.
I will keep you informed here about this NPE (and renaming the issue to focus on this). Can you then try with RC5 when ready, and if you hit more bug, try to narrow down to a small repro case for us to analyze, add to test suite, and fix?
@rgladwell I have a simple repro, that's nice. It will be fixed pretty quickly now.
That should be ok, I will deploy a RC5 soon. Thanks for reporting.
Please keep us informed here about your progress on itext7, this is a nice project. If you find a bug, the best is trying to provide a unit test, or a small repro on a dedicated issue.
Thanks again
3.0.0-RC5 is deployed, please test it on this version. groupId is org.jsweet.v3 for almost all artifacts now (please see pom.xml & build.gradle here: https://github.com/cincheo/jsweet-examples)
@lgrignon Thanks for the quick fix, just tested and it resolved the NPE.
Getting multiple NPEs on transpilation: