Namespace as module name

Is there any way to have modules named after namespaces? To have something like:

export module $Namespace
{
    $Classes(*VM)[
    export class $Name {
        $Properties[
        // $LoudName
        public $name: $Type = $Type[$Default];]
    }]
}

I need it to be able to import multiple typings to my Angular2 component. Unless there is a better way to do it?

[aluanhaddad]

@gregveres Sorry for the delay. Honestly my feelings about my setup have taken a downturn. Also, they may not be sufficient for your use cases. My use cases are rather simple, I am primarily generating types, not values. Here is how I generate interfaces from server side model classes:

$Classes($IncludeClass)[$Imports[import $ImportTypeName from '$FileName';
]$HasImports[
]$DocComment[/**
  * $Summary
  */
]interface $Name $HasExtends[extends ]$TypesExtended[$Name][, ]$HasExtends[ ]{
$Properties[
  $DocComment[/**
    * $Summary
    */
  ]$HasSetter[][readonly ]$name: $Type[$IsDate[Moment][$Name]];
]
}

export default $Name;]

Sorry for the poor readability, whitespace generation is a major pain. Anyway, on build of the containing .csproj, I have a powershell script that enumerates the director to generate an index and re-exports everything, but this is just a convenience because in the same script I copy the directory to the client side project.

[gregveres]

Ok. Do you really need that? Do interfaces need to go into separate namespaces? They don’t generate any real code, just a definition that is referenced.

I put all of my interfaces into a single namespace called SkyCourtAPI (my thought there was that it was all part of the definition of the API to interact with the server.). Also, since these are just interfaces, there is no import that is needed. I just reference them with their namespace qualified name. So even if you do want to separate your interfaces into separate namespaces, you don’t need the complications of imports. Imports are a pain in the butt to infer. I ended up creating an attribute that indicates where the class should be imported from.

I am using Knockout so I do generate Knockout versions of my interfaces. These are real classes, not just interfaces because they create the code that creates a set of knockout observable variables from the C# member fields. In this case, I do have some C# inheritance going on that translates into typescript inheritance of my knockout classes. This is where the import attribute comes in.

I am also using attributes to control which C# structures are being exported. I have [ExportToTypescript] to generate an interface and [ExportToTypescriptWithKnockout] to generate the knockout class.

if you email me greg . veres at rogers dot com, I will send you my tst files. and we can have a conversation about how to use them.