javascript-to-typescript conversion tool + site?

Topics: General
Nov 1, 2012 at 5:32 PM

Brian Harry mentioned the conversion tool as part of the TFS team switching over to using TypeScript:

While Brian mentioned in the comments that he asked that the tool get released, can it be released as part of the site as well?

A good example is which allows conversion in both directions - the 'normal' coffee -> js but also js -> coffee.

Now, due to the 'superset of js' nature, it's not strictly necessary, but clearly there's a lot of low-hanging fruit that such a converter can (and presumably, already does) tackle when the existing js already does the idiomatic js patterns, and that'd be very useful to have instead of having to do those conversions manually. :)


Nov 2, 2012 at 3:33 PM

One of the main differences between JS and TS is the type system and annotations.  It's not possible to convert JS to full-typed TS in the general case without having type information annotated in the JS (which is what the TFS team did, IIRC).

For different kinds of annotations (VSDoc, JSDoc, etc), there could be tools to help users migrate to TS.  Telling users about what tools are available sounds handy - a good suggestion for the website.

Nov 2, 2012 at 8:11 PM
Edited Nov 2, 2012 at 8:14 PM

agreed - I didn't really mean trying to infer the types and include that in the generated TS (although that would be awesome), I was more thinking of the structural things where TS generates idiomatic JS (the modules and classes in particular).  It seems like there's a lot of existing JS out there that already includes the same idiomatic JS, so having something that catches a lot of those cases and automates switching it to TS class/module declarations would be very helpful, even if its ability to match/convert isn't exhaustive.

IOW, non-type-annotated js, using idiomatic structures (same structure as the TS output for class/module) would transform to .ts with class/module declarations.  Type-annotated js converts over with the type annotations as you mentioned, but I'm just hoping that's not a requirement.  I'd much rather the path from the typical JS codebase today (idiomatic patterns, no type annotation) to a 'clean' TS codebase (class/module, type annotations) didn't require the user to go add type annotations (VSDoc, JSDoc, etc) on the JS side, and instead allows those to be added to the post-conversion TS. :)

It seems like an easier onboarding/migration path to allow people to get the structure bits converted over in an automated fashion and then let them add the typing as time allows or needs dictate, rather than the conversion tool requiring input source be fully type annotated before they can have an automated conversion to TS.  If nothing else, perhaps the converter could take any places where type annotation is missing and just make it ": any" in the output, so people trying to convert code bases with partial type annotation coverage could convert 'everything' over.

As a workflow, if I could have a set of JS files that convert over to TS files and load them into VS, even if all the TS files start out with ": any" for the types, I can then leverage all that work you guys have done as I start to replace the "any" instances with the right type. :)

Worst-case, if the conversion tool requires fully-type-annotated source for the conversion process, I can probably still manage the class/module conversion via regex or the like for most cases, but would much rather leverage the converter tool if possible. :)

Thanks, Jon!

Nov 2, 2012 at 8:42 PM

Semi-related, but WRT tooling, is there anything in the ecosystem that will take run-time type determination and persist that out in a way that could allow automated type annotation?  With the Source Map support, it could even modify the source TS (or create a modified version of it), although just having it persist out the runtime type info in a way that maps to the generated JS is certainly sufficient. :)

Searching around, I see someone else asking for the V8 team to do this in the context of Node development about a year ago, but I'm having a hard time finding anything that seems to actually do it.

I'd imagine it doesn't really matter which engine (V8, Chakra, whatever) is used as long as it has the necessary runtime type information (which, for perf reasons, I would imagine at least V8 and Chakra both do), but getting them to persist that info back out is what I'm hoping already exists somewhere (and if not, that one or more of the engines will be willing to add it :)

Being able to automate the type annotations via runtime type information would make the converter requirement of 'input js must be type annotated' not so scary, since there would then be an option for getting an existing JS code base modified with type annotations.  Even if it only worked correctly (say) 90% of the time, that's still a better result (IMHO) than 100% manual type annotation before any conversion to TS is possible. :)

Thanks again, Jon!!

Nov 5, 2012 at 4:53 PM

You can get some of this now - eg, it's possible to rename .js files over to .ts files and start with your types default to :any in most cases.  You may get some type warnings, but those you could ignore as you finished converting code over.

That said, being able to detect patterns of use, like detecting class-like behavior, in the JS is non-trivial.  It'd likely take a separate tool and a lot of polish to get to a decent user experience.

For the runtime aspect, are you asking if we can detect the runtime type and make it available later for static typing?  Perhaps not for the general case, but as a first approximation that may work.  

Because TS code is inter-operable with JS, another way to do the conversion is a little at a time.  You could take a wholly JS codebase and add a few annotations at first, and over time bring more annotations in.  The code would work the whole time, and you're not faced with doing the type annotations all at once.

Jun 6 at 5:20 AM
I wrote a tool to convert JSDoc annotations to .d.ts files. It's designed to handle the easy cases correctly, and to produce a useful starting point for manually fixing the difficult cases.

It works best on closure-style modules; it can process the entire google closure library without error, though some ambiguities have to be resolved manually.

You can use it online at:

Source repo:
Oct 16 at 3:45 PM
Edited Oct 16 at 3:50 PM
You can try to use Resharper for structurally converting Js to Ts (class/module/external module/lambda/...).