CODEWITHSUNDEEP
typescripttypescript1.4
Oliver Weichhold
Oliver Weichhold

Reputation: 10306

Typescript: Private class which is visible to classes in same module in different files

My project uses the 'Multi-file internal modules' approach. During build everything is compiled into a single Javascript file.

One thing that still bothers me is that I can't find a way to have private module level classes (not exported to the definition file) that are still visible and usable by classes in the same module residing in seperate files (i.e. C# internal classes). Any suggestions?

Foo.ts:

module shared {
  class Foo { 
  }
}

Bar.ts:

module shared {
  export class Bar { 
    constructor() {
      this.foo = new shared.Foo();
    }  
  }
}

Baz.ts:

module shared {
  export class Baz { 
    constructor() {
      this.foo = new shared.Foo();
    }  
  }
}

Upvotes: 2

Views: 3202

Answers (1)

Ryan Cavanaugh
Ryan Cavanaugh

Reputation: 221352

There isn't a language-side solution to this. There's two aspects to why this is the case -- what the consumers of your code see, and how the JavaScript is emitted.

From the emit side, either shared::Foo is an exported member of the shared object, or it isn't. If it isn't exported, shared:Baz can't see it and will be unable to use it. So any 'internal' class in a module obviously does need to be exported in terms of emit.

From the consumption side, there's a subtle danger here. Let's say this happened:

// ** YourCode.d.ts **
declare module shared {
   class Bar { ... }
   class Baz { ... }
}

// ** SomeConsumer.ts **
// Hey, 'shared' is a good namespace!
module shared {
    // My own personal Foo
    export class Foo {
    }
}

What just happened? A user of your code just stomped on the shared.Foo member without realizing it. Everything is going to break at runtime. The set of dangerous members that break the universe is an undocumented minefield.

The best solution if you have some members that should be used externally and some that shouldn't is to use a nested module called something like Internal or Implementation to clue in consumers that they shouldn't actually use those objects themselves.

Upvotes: 2

Related Questions