Using external modules in TypeScript

Question

Let's say we have the following 2 external modules in TypeScript:

export module My.Services.Common { export class Helper { //... } } 

and

 export module My.Services { export class Connection { //... } } 

Now in my applications, I would like to use the Connection and Helper classes. What I want to achieve is similar to the following code in C #:

 using My.Services; using My.Services.Common; 

Or at least just

 using My.Services; 

But it seems that I cannot work simultaneously with the assistant and the connection. If I write:

 import {My} from './services/common/Helper'; import {My} from './services/Connection; 

The duplicate identifier “My” leads to the error. This is logical. So my question is: how can I use different classes from the same (or nested) modules?

Answer 1

My personal view is to break away from what you see in C # or Java (which is more closely related to internal modules) and treat it more like external modules that you use ...

Step 1. Turn the module keyword. The file is already a module.

Step 2. Provide a pointless alias when importing.

Step 3. Now you can import everything, * * or certain classes upon import.

./services/common.ts

 export class Helper { //... } 

./services.ts

 export class Connection { //... } 

./app.ts

 import * as Services from './services' import { Connection } from './services/common' var x = new Services.Helper(); var y = new Connection(); 

You can also import several elements from the module:

 import { Connection, Example } from './services/common' var y = new Connection(); var z = new Example(); 

Answer 2

To add a good answer to Steve, since I was already drawing ASCII art: the top-level object exported from this module, My , does not merge with any other object from other files named My . The only thing that reaches the My.Services.Common module makes it more annoying to import Helper , because you have to fully qualify its name, even if there is nothing there.

What do you think you did:

 /-My--------------------\ | /-Services---------\ | | | /-Common---\ | | | | | [Helper] | | | | | \----------/ | | | | | | | | [Connection] | | | \------------------/ | \-----------------------/ 

What you actually did:

 /-My---------------\ /-My---------------\ | /-Services-----\ | | /-Services-----\ | | | /-Common---\ | | | | [Connection] | | | | | [Helper] | | | | \--------------/ | | | \----------/ | | \------------------/ | \--------------/ | \------------------/ 

This is similar to the fact that your house has an organization system where you have a dozen shoe boxes, each of which has one smaller box inside, each of which has a smaller box inside it. Nested drawers do not provide organizational benefits compared to shoes!

Answer 3

I found a different approach to solve this organization problem.

To return to the art of ASCII (ᵔᴥᵔ)

My folder structure is as follows:

 | |-- myawesomemodule | | | |-- myawesomeclass.ts | |-- myevenmoreawesomeclass.ts | |-- myawesomemodule.ts | |-- myevenmoreawesomemodule | |-- myotherclass.ts | |-- myanotherclass.ts | |-- myevenmoreawesomemodule.ts | index.ts 

In myawesomemodule.ts , I do:

 export {MyAwesomeClass} from './myawesomeclass.ts' export {MyEvenMoreAwesomeClass} from './myevenmoreawesomeclass.ts' 

Similarly in myevenmoreawesomemodule.ts , I do:

 export {MyOtherClass} from './myotherclass.ts' export {MyAnotherClass} from './myanotherclass.ts' 

And finally, at the root level in index.ts , I do:

 import * as MyAwesomeModule from "./myawesomemodule/myawesomemodule"; import * as MyEvenMoreAwesomeModule from "./myevenmoreawesomemodule/myevenmoreawesomemodule"; export {MyAwesomeModule}; export {MyEvenMoreAwesomeModule}; 

Now I can send this module to the consumer, pack it as NPM, etc.

From the consumer, I do:

 import MyPackage = require("mypackage"); //assuming you did npm pack 

OR

 import * as MyPackage from "./path/to/index.ts" //asuming you didn't 

Then I refer to the class names, therefore:

 let instance = new MyPackage.MyAwesomeModule.MyAwesomeClass(); 

I find this approach a little better than exposing all my classes to a large module at the root level.