Support merging classes and modules across files

[dbeckwith]

I currently have a setup something like this:
A.ts

module mod {
  export class A {
  }
}

B.ts

/// <reference path="A.ts" />
module mod.A {
  export class B extends A {
  }
}

But I'm getting the error in B.ts:
A module declaration cannot be in a different file from a class or function with which it is merged.
It works fine, however, if the declarations are in the same file: Playground

In my compiler options, I'm concatenating all the files together in the output, so shouldn't it not matter that they're in different source files? Even if the output wasn't concatenated, I don't understand how the declarations being in separate files changes anything.
Basically, the structure I'm going for is that A is going to have a lot of subclasses, and I wanted to have them all be in a module also called A. It just makes sense organizationally to me.

Why is this not allowed? Is there a way around it?

[RyanCavanaugh]

It isn't allowed because we can't be sure about the ordering of the files. A.ts must execute first; this is different from other module merging scenarios because those can generally take place in any order.

[dbeckwith]

But if I'm compiling with concatenated output, can't you guarantee the order of execution?

[danquirk]

There are simple cases the compiler could know it's safe (but doesn't today), and more complex cases that would be harder (if not impossible) to analyze correctly. We generally haven't yet seriously invested in features that require analyzing ordering (whether code within a file, or file ordering itself), especially if that investment would still only cover some of the relevant scenarios (ex only allow classes and modules to merge in specific ordering and with --out). And of course there's another alternative where we don't give an error at all and leave it up to the user to make sure the ordering is working correctly/as intended. I'll edit the title a bit to reflect the suggestion.

[dbeckwith]

Okay, I understand, and I see the potential difficulty of the general problem. I can adjust my model to work around this, but if in the future support is built for module/class/function dependency ordering that would be great.

[indus]

I need this, too.

[niabot]

I also would like to have this feature. For readability i hold a lot of classes in separate files, which will be compiled into many tiny modules, which i don't need.

The example project structure (the source directory as root):

rootDir
|--libDir
|  |--packageDir1
|  |  |--ClassA.ts
|  |  +--ClassB.ts
|  |--packageDir2
|  |  |--ClassC.ts
|  |  +--ClassD.ts
|  |--packageDir1.ts
|  +--packageDir2.ts
+--lib.ts

The example content of lib.ts is:

import * as package1 from './libDir/packageDir1.ts'; export {package1};
import * as package2 from './libDir/packageDir2.ts'; export {package2};

On the other hand packageDir1.ts contains:

import {ClassA} from './packageDir1/ClassA';
import {ClassB} from './packageDir1/ClassB'; 

The final Library is used like this:

import * as lib from 'lib';
import ClassA = lib.package1.ClassA;
var instance = new ClassA();
var instance2 = new lib.package2.ClassC;

This works fine as it is if compiled with '--outFile', but it introduces a lot of not needed modules like 'lib/package1' and 'lib/package1/ClassA'. Additionally it increases the likelihood of cyclic references which can make class inheritance fail and enforces careful ordering of imports.

I really would like to see the compiler to recognize such a structure and to transform it from something similar to this:

module lib {
  export module package1 {
    export class ClassA {
      ...
    }
    export class ClassB {
      ...
    }
  }
}

to this:

module lib {
  class ClassA { ... }
  class ClassB { ... }
  class ClassC { ... }
  class ClassD extends ClassB { ... }
  export var package1 = {
    ClassA: ClassA;
    ClassB: ClassB;
  }
}

[dev-mraj]

+1

i'd like to have this, to just es6 output with typescript so then i can use clousercompiler to optimize that for es5

[salim7]

We would need this feature as well.

[deinok]

On "module":"es2015" and "target":"es3"
We should only require to delete the export { MyClass }; an the files would be ready to concat following the order of the imports and if something have been already imported, dont concat them

[RyanCavanaugh]

Accepting PRs for this - just re-use the existing logic we have for detecting if two constructs will be in the right order in an outFile

[deinok]

@RyanCavanaugh Should I writte a proposal of how this should work before send the PR?
With this feature we should be able to avoid WebPack, babel, rollup and others for the only task to use ES2015 imports while targeting ES3 or ES5

[RyanCavanaugh]

There shouldn't be anything to propose other than "correctly don't issue the error when the code would work". The emit should be the same; if you think it should be something different then we should get on the same page about what the scenario is

[terrible-coder]

I kinda need this feature too. Any recent updates?
Also, what would the import statements look like for importing these "distributed" class/namespace declarations?

[RyanCavanaugh]

Non-module compilation is basically extinct at this point, and no one has bothered implementing this since the seven years since it was approved, so let's just not bother at this point.