TypeScript's “Combine JavaScript output into file” option doesn't infer correct script order without /// <reference> tags

I'm working on a TypeScript solution that uses the "Combine JavaScript output into file" option:

enter image description here

I'll often reference an item defined in another file, for example:

In MyBaseClass.ts:

export class MyBaseClass { }

In MySubClass.ts:

export class MySubClass extends MyBaseClass { }

While developing, Visual Studio has no problem understanding that MySubClass references the MyBaseClass defined in MyBaseClass.ts - the solution successfully builds and I can navigate to MyBaseClass using F12.

However, I run into runtime errors when I run the solution because the generated JavaScript file defines MySubClass before MyBaseClass.

I can fix these runtime errors by adding a /// <reference> tag in MySubClass.ts:

/// <reference path="MyBaseClass.ts" />
export class MySubClass extends MyBaseClass { }

Why does the IDE understand the relationship between MySubClass and MyBaseClass, but the compiler doesn't correctly order the definitions of these classes in the generated output?

I'd either like the generated output to correctly infer the order of the class definitions (preferred) or the TypeScript compiler to throw errors if the /// <reference> tags aren't present.

Answers:

Answer

Why does the IDE understand the relationship between MySubClass and MyBaseClass,

It only knows the semantic relationship. Not the runtime requirements. How you do the module loading is up to you.

Note: https://github.com/TypeStrong/grunt-ts#reference and https://github.com/TypeStrong/grunt-ts#javascript-generation

Answer

I really whish this could be fixed. Typescript intellisense does not seem to have any problem at all infering the proper order. When the compiler, which has the option "Combine into one file" does not solve this, it renders larger js files upfront unreliable ... The normal response to this issue is, use dynamic loading ... that is true. But in my case, the modules which are dynamically loaded, already exist of many classes which are in seperate projects compiled into a single file. Hence the problem exists in that scenario as well ...

Tags

Recent Questions

Top Questions

Home Tags Terms of Service Privacy Policy DMCA Contact Us

©2020 All rights reserved.