Ways Of Migrating
Using a Semi-Automatic Tool
|Immediately-invoked function expressions|
|Immediately-invoked function expressions with namespace object passed as an argument|
|Classes and inheritance|
|Native class implementation|
|Function expression to lambda|
|Member assigned by a function expression to function member|
|Usage of parent class via invocation of call/apply to keyword super|
|Creating dynamic property to ambient declaration|
|Infer possible overload signatures by function body/vsDoc|
In general, support for these patterns allows ReSharper to very quickly produce an OOP baseline implementation. This is the tool’s main advantage. As a result we get approximate TypeScript code, which requires some error correction before it can be put into production.
So, what errors did we get after performing the conversion? We got about 1,200 errors and, after a certain amount of classification (thanks to ReSharper’s Solution-Wide Analysis) we managed to pinpoint these particular types of errors:
“Cannot resolve symbol” and other related errors – 70% of cases
“Supplied parameters do not match any signature of call target” – 25% of cases
Other cases – 5%
The occurrence of the “lack of matched signature” errors is related to the fact that the inference of overload signatures is not always possible statically without special annotation libraries. See example below.
Generated TypeScript code:
But this is not the only source of problems. The next example illustrates a more frequent situation:
You may notice that the
fail function does not declare optional parameters. That is why ReSharper is unable to infer the overload signature with optional parameters. This code can be confusing, and may cause errors.
The most frequent type of error, however, is the inability to resolve a particular symbol, as well as related issues. These also appear because of dynamic nature of the language:
In general, these sorts of errors are expected. At the moment, it is the developer’s responsibility to fix these errors but, in the future, ReSharper might be able to resolve them automatically.
Errors from the other category are more interesting. Some of them shows that the lack of common convention leads to confusing. The next example shows a typical deviation from convention CommonJs modules.
Buffer as exported variable:
Usage of the
Buffer symbol, which was not imported:
Buffer is global type, by design, of node.js, but it is not obvious by code.
The next example demonstrates multiple inheritance. If your parent classes have properties with the same name and you don’t notice it, it obviously leads to undefined behavior. The compiler can’t help you either. And if you use multiple inheritance in code, you will have to replace it on composition yourself. TypeScript doesn’t support it.
Generated Ts code:
How To Perform Conversion?
Obsolete code can be converted with ReSharper’s highlightings and the corresponding quick-fixes. There are different granularities for conversion:
- Element under caret
- In file
- In folder
- In project
- In solution