Support _references.ts for controlling order of files in single file output

[brycepj]

We switched from grunt-ts, and started getting this error. Grunt-ts continues to handle it properly, which is why we're convinced it's a plugin issue.

Scenario:

All libraries are contained in 'src' folder, but kept in different, nested folders.

TypeScript plugins Source Folder is set to 'src'.

We have one 'base' file, responsible for importing dozens of libraries, d.ts files etc.

One of the libraries (imported by base), imports another local library (let's call it 'goodies') that is not imported by the base file. It's a large library that we don't want to import if we don't have to.

Goodies shows up in the compiled JS file, but with improper inheritance with sub-classes. Any of its classes that inherit from other classes have incorrect prototype references.

It seems that the issue stems from the fact that eclipse-typescript asks for a source folder to compile from, whereas grunt-ts allows us to specify a file. Thus, the compilation takes a more predictable path.

I'm still working on creating a simplified example, but I'm wondering if you've run into something like this, and if you've come up with any quick solutions.

If not, what can I do to help you reproduce it?

[derekcicerone-zz]

What error are you getting? Do you have a screenshot?

[brycepj]

notice that it's trying to import 'esc.widgets.esc.widgets' -- that's where the inheritance is messed up. Should be asking for esc.widgets

[derekcicerone-zz]

Oh whoa, so this isn't a compilation error - this is actually an error with the generated code. Are you using an external module system (like AMD/CommonJS)? If internal modules, do you have triple-slash references between the files?

[brycepj]

Yeah, you're right. It's an error in the generated code. But what's weird is that we don't run into the same problem with grunt-ts. And, we're just using the triple-slash references.

[derekcicerone-zz]

Hmm, ok, are you generating a single file output or is each source file compiling to its own JavaScript file?

[brycepj]

Single file.

[derekcicerone-zz]

Ok, thats what I suspected. In that case, can you look at the single file output and see if the code is being concatenated in the wrong order vs what you are seeing from the command line compiler? My suspicion is that the triple-slash references are either not working (the single file output is new) or that they are indicating a different ordering than what you would get by specifying a single file as the starting point for compilation.

[brycepj]

I think you're on to something there re: "that they are indicating a different ordering than what you would get by specifying a single file as the starting point for compilation." If I look over the whole JS file of the two different compiling methods, they're clearly importing files in a different order.

So here's the code output of eclipse-typescript on the class that's throwing the error:

And here's the output of grunt-ts, which works:

(notice that one properly passes in esc.widgets.KendoChangeable while the other omits the 'esc', causing it compile as if it was a relative path.)

I'll look further at the import references and see what I can come up with in the mean time.

[derekcicerone-zz]

Cool - I don't have a use case for the single output file option so its very possible it doesn't currently work. The way the plugin works is that it passes all the files into the TypeScript language service and then it recompiles whenever a file is saved. I'm not sure if the file being saved impacts the output or not (that might be worth looking into with a quick experiment). If so, it might be possible to always build a certain file first (I think the Visual Studio plugin supports this with an _references.ts file for example).

[brycepj]

Interesting. That makes sense. Any chance you'll ever add a single input file option? If not, it's possible that we should stick with grunt-ts, since what we're doing isn't quite a use case you're focusing on.

Also, I tested your theory about the file being saved affecting the compile order: you're right. It does impact the order.

[derekcicerone-zz]

Ah very interesting - thanks for trying that out. I think we'd like to match the behavior of the Visual Studio plug-in. That likely means adding the _references.ts support so that file ordering can be controlled. I don't think they allow for specifying a single file input, but if you learn otherwise please let me know. I'm going to repurpose this bug to reflect that request though if that's cool. I think using grunt-ts for now is definitely the way to go (much safer).

[brycepj]

Sure, go for it. Thanks for taking the time to work through this with me. Cheers!

[derekcicerone-zz]

Alternatively we could allow the root TS file to be specified - maybe I'll do that instead. The _references.ts thing seems to be very specific to Visual Studio and how they chose to address some JavaScript issues.

[brycepj]

That would definitely suit our situation better. It would give us the kind of control we need over source order. I'll stay tuned.

[derekcicerone-zz]

To be fair, I think both options will provide precise ordering control. For example, with the _references.ts idea, you could just specify the "main" of your project and get essentially the same effect. My aversion to the _references.ts thing is mostly that it will be somewhat undiscoverable and it seems somewhat specific to VS.

[brycepj]

You're right... I wrote that kinda hurriedly from my phone. I agree -- the references file would feel a little clumsy at first to non-VS-ers. This other approach however would give us all of the control without having to make many (if any) changes to our development and build systems.

[derekcicerone-zz]

I'm pushing a fix for this now which will honor the /// comments. I didn't realize they weren't already handled inside the compiler. Wanna take another look at the single file output? We are using it now for a new project so I have some test cases that seem to indicate this is a good fix. I think it may still be desirable to pass in an _references.ts, but I'm gonna hold off on that for now to see how well this works.

[gergelyrozsahegyiwhereiseu]

Hi!

I have 3 input source file: // Class1.ts /// class Class1 extends Class3 { constructor() { super(); console.log("Class1"); }}

// Class1.ts /// class Class1 extends Class3 { constructor() { super(); console.log("Class1"); }}

// Class3.ts class Class3 { constructor() { console.log("Class3"); }}

The single file output file is: // Class3.ts var Class3 = (function () { function Class3() { console.log("Class3"); } return Class3; })(); var __extends = this.__extends || function (d, b) { for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; function __() { this.constructor = d; } __.prototype = b.prototype; d.prototype = new __(); }; /// // Class2.ts var Class2 = (function (_super) { __extends(Class2, _super); function Class2() { _super.call(this); console.log("Class2"); } return Class2; })(Class1); /// // Class1.ts var Class1 = (function (_super) { __extends(Class1, _super); function Class1() { _super.call(this); console.log("Class1"); } return Class1; })(Class3);

The order in output file is incorrect. Why? Please help Me!

[derekcicerone-zz]

Do the files have explicit references (///<reference...>) to their dependencies? TypeScript does not figure out file ordering without those explicit references.

I'm also not sure if the current release of the TypeScript plug-in will honor references in the file ordering (I think I may have taken the code out because it severely degraded performance). You may want to check out the develop version of the plugin. It runs the in-development v1.3 version of TypeScript which I believe handles the references properly.

[domchen]

This may help： https://github.com/domchen/typescript-plus . The typescript-plus compiler is an enhanced version of the original typescript compiler, which provides extra features to the original typescript compiler, such as accessors optimization, class reflection, conditional compilation and the most useful one : automatically reordering the source files by analyzing their denpendencies in code.

It is basicly the same to the original compiler on usage, for a documentation of how to use the extra options please see the README.