wro4j icon indicating copy to clipboard operation
wro4j copied to clipboard

Update Rhino TypeScript Compiler

Open brian428 opened this issue 11 years ago • 23 comments

TS 0.9 just came out, so the current 0.8 compiler is now somewhat out of date. I may see if I can help via pull reqeust, but I just wanted to see if this could get on your radar.

FYI, the 0.9 typescript.js can be found at: http://typescript.codeplex.com/SourceControl/latest#bin/typescript.js

brian428 avatar Jun 20 '13 04:06 brian428

It would be great if the typescript would be packaged as a webjar. The benefit would be easier upgrade, with no release required.

alexo avatar Jun 20 '13 04:06 alexo

Funny, I hadn't even heard of a "webjar" before. Now that I see the repo, I agree. The only hangups on that I see are that TS isn't hosted on Github (not sure if that matters or not), and that the TS compiler probably isn't commonly used outside of...well...the TS compiler heh. While WRO4J is definitely one great candidate for using it, my thought is that this project is somewhat unique in what it does. But not many "normal" web projects would want or need the TS compiler itself within them. Am I making sense? heh

brian428 avatar Jun 20 '13 13:06 brian428

When building a webjar project, it doesn't matter where is the upstream source location. So it is not a problem that it isn't hosted on github.

But not many "normal" web projects would want or need the TS compiler itself within them. Am I making sense? heh

I'm not sure I understand what you mean. Could you provide an example?

The good part with using webjars is that it is possible to upgrade or downgrade the processor (in this case TypescriptProcessor) without changing or extending the wro4j istelf. Also, each rhino based library evolves with its own pace... and it is hard to release as often as a new library (like typescript) is released.

alexo avatar Jun 20 '13 13:06 alexo

I just mean that including the TS compiler ITSELF (typescript.js) is not something I can picture many people actually wanting to do. It's not like jQuery or Angular where people USE that library as part of their running web apps. With TS, people run the compiler in some other way (as part of a build, or through an IDE), and use the resulting JS files...but they don't use the compiler itself.

brian428 avatar Jun 20 '13 13:06 brian428

Indeed. Still, packaging it as a webjar would add a great value for other tools (build or runtime) which want to benefit from easier upgrade using it.

alexo avatar Jun 20 '13 13:06 alexo

Cool...so is packaging up the TS compiler as a webjar something the TS folks would have to do? Or is it something someone else (like me) can do? If you know, great. If not, I'll see what I can dig up on the webjar repo site.

brian428 avatar Jun 20 '13 13:06 brian428

I also see that CoffeeScript has a webjar...so if TS gets in, might be cool to use the same webjar approach for the Rhino CS compiler that you would for TS?

brian428 avatar Jun 20 '13 13:06 brian428

Anybody can do it. Use webjars-less as example. Create a project, configure it use correct upstream and ask webjars folks to fork it. I've already opened the issue

alexo avatar Jun 20 '13 13:06 alexo

Coffee-script webjar is already used.

alexo avatar Jun 20 '13 13:06 alexo

@brian428 I've started a branch (called issue750) for this issue, but have some troubles with the typescript.compiler script which requires few changes because the TypescriptCompiler api has changed since 0.8. If you have better knowledge about the changes in typescript-0.9, I would really appreciate your help.

alexo avatar Jun 23 '13 12:06 alexo

Sure, I'll try to take a look. Full disclosure: I'm not TypeScript expert at all...I just recently discovered it and was thinking about revising my CoffeeScript compiler plugin for Grails (which uses Wro4j) to include TS compilation as well. But I'll see what I can figure out! Thanks.

brian428 avatar Jun 24 '13 14:06 brian428

Also, just so I'm clear, the webjar for TS 0.9.1 looks like it is already in place in the webjars repo, is that correct? I admit that I'm always confused by Maven heh. I've used it and honestly I hate it compared to something like Gradle, but I know it's kind of the 800-lb gorilla of the Java build world. ;-)

brian428 avatar Jun 24 '13 14:06 brian428

It is easy to check what version of any given library is available on maven central repo. Just check it here: http://search.maven.org/#search%7Cga%7C1%7Ctypescript

alexo avatar Jun 24 '13 14:06 alexo

Alex, just curious how you are testing the TS processor? I see a TestTypeScriptProcessor.java class, and I can run it and all three tests pass. However, the test actually is creating a CoffeeScriptProcessor (named "victim"), and it also looks like the resource, etc. are all mocks. Just want to make sure I'm not missing something. Thanks.

brian428 avatar Jun 24 '13 23:06 brian428

Ah ok, I think I found it (Node and Rhino TS processor tests in the processor package).

brian428 avatar Jun 24 '13 23:06 brian428

Alex, I think I'm confused about how your current tests work. For example, you have a testFromFolder method in the TestNodeTypeScriptProcessor. It looks like this is being given the /typescript/expected folder from the resources package as the "expected folder", and /typescript/test as the "test folder". It then compares these two folders, but the comparison fails since the "actual" output is empty.

What I don't understand is where the generated output from the TS compiler is going, and how that plays into this comparison. This looks like it is trying to compare an expected folder of JS files against a folder with the TS source files...which would obviously never be correct. Does WroTestUtils.compareFromDifferentFoldersByExtension emit the compiled JS somewhere? Does it write to a memory-only string and try to compare that against the expected JS?

Thanks,

Brian

brian428 avatar Jul 03 '13 03:07 brian428

Hi Brian,

sorry for confusion. Probably the javadoc could be updated to make it less ambiguous. The WroTestUtils.compareFromDifferentFoldersByExtension works in the following way:

  • it doesn't compare two folders literally.
  • it applies processing on each file found in test folder and compares the result with expected file (having the same name) from the "expected folder"

The advantage of this approach is that for each new test-case, no java code should be modified. Instead, just two new resources has to be added to "test" and "expected" folders.

alexo avatar Jul 03 '13 07:07 alexo

OK I have the tests passing with the Node TS processor. Still having issues with the Rhino version and I'm wondering if it might have to do with this: http://blog.frickjack.com/2013/06/compiling-typescript-with-rhino.html

If so, that could be a deal-breaker, until/unless the TS folks adjust the compiler JS code...I'll keep digging.

brian428 avatar Jul 09 '13 06:07 brian428

Thanks for update. Could you push your updates? I would like to see the changes...

Cheers, Alex

alexo avatar Jul 09 '13 06:07 alexo

Sorry for the delay. Sure, I'll send a pull request tonight.

brian428 avatar Jul 11 '13 17:07 brian428

Also, quick question: when you set up this branch, did you modify the Maven config to pull in the latest TS webjar? I'm not sure how to figure out if it's being included, and if it is, how to reference it "the right way". My Maven ignorance asserting itself again. ;-)

brian428 avatar Jul 11 '13 17:07 brian428

It's worth mentioning, this should be 1.0 RC now.

http://blogs.msdn.com/b/typescript/archive/2014/02/25/announcing-typescript-1-0rc.aspx

jamesbradley avatar Mar 12 '14 21:03 jamesbradley

Will this be fixed anytime soon?

natami avatar Jul 19 '16 19:07 natami