<p dir="auto">I have a general question about project structures / modules.<br>
It's a project with 3 types of code:</p>
<ul dir="auto">
<li>client: classes used for the client web-app, built into a single js file (with --out).</li>
<li>server: code running on node</li>
<li>shared: classes used by both client and server, typically model classes with functions like validation, etc</li>
</ul>
<p dir="auto">My aim is this:</p>
<ul dir="auto">
<li>use 1 file per 1 class at the source level</li>
<li>deploy the client app into a single output file (for performance reasons: better start up time), the server can be deployed as many files (or if possible and makes sense from a perf. point of view it can be a single file too). These can be 2 separate compilations, the client with --out and the server with commonjs.</li>
<li>reuse the shared model classes (without duplication) in the client and the server</li>
<li>be able to use circular dependencies (although shared code will not depend on client/node code, only the other way around, circular dependencies can only occur in within the client code)</li>
</ul>
<p dir="auto">I can't seem to achieve these goals. The problem is this:</p>
<ul dir="auto">
<li>if I structure the shared code so that I only use the ///&lt;reference.../&gt; tags (like I do in the client) that won't be usable when compiling the server with common.js</li>
<li>if I use common.js style requires in the shared code then that won't work for the client's single file --out compilation</li>
</ul>
<p dir="auto">These are the options I think I have:</p>
<ul dir="auto">
<li>switch to using require js (amd) in the client as opposed to references and the single file output, and maybe use some post compile script to concatenate the modules to a single file. However circular dependencies may occur sometimes and that's a big issue I have with require.js</li>
<li>switch to using es6 style module syntax and use it on the client and in node with some polyfills/loaders until natively supported</li>
<li>switch to using commonjs style modules and load them with browserify on the client</li>
<li>do a pre-compilation step and transform the shared code to be eligible once for the client side single output compilation and once for the node.js side common.js compilation. However this can have many caveats and sounds like a hack.</li>
</ul>
<p dir="auto">What I think I'm really looking for is a way for each TypeScript class/file to be able to "say" what is the class it exports, but not specify how it will be consumed, ie. via commonjs or as a single file output. Probably that's not possible though in a simple way?</p>
<p dir="auto">I have a general question about project structures / modules.<br>
It's a project with 3 types of code:</p>
<ul dir="auto">
<li>client: classes used for the client web-app, built into a single js file (with --out).</li>
<li>server: code running on node</li>
<li>shared: classes used by both client and server, typically model classes with functions like validation, etc</li>
</ul>
<p dir="auto">My aim is this:</p>
<ul dir="auto">
<li>use 1 file per 1 class at the source level</li>
<li>deploy the client app into a single output file (for performance reasons: better start up time), the server can be deployed as many files (or if possible and makes sense from a perf. point of view it can be a single file too). These can be 2 separate compilations, the client with --out and the server with commonjs.</li>
<li>reuse the shared model classes (without duplication) in the client and the server</li>
<li>be able to use circular dependencies (although shared code will not depend on client/node code, only the other way around, circular dependencies can only occur in within the client code)</li>
</ul>
<p dir="auto">I can't seem to achieve these goals. The problem is this:</p>
<ul dir="auto">
<li>if I structure the shared code so that I only use the ///&lt;reference.../&gt; tags (like I do in the client) that won't be usable when compiling the server with common.js</li>
<li>if I use common.js style requires in the shared code then that won't work for the client's single file --out compilation</li>
</ul>
<p dir="auto">These are the options I think I have:</p>
<ul dir="auto">
<li>switch to using require js (amd) in the client as opposed to references and the single file output, and maybe use some post compile script to concatenate the modules to a single file. However circular dependencies may occur sometimes and that's a big issue I have with require.js</li>
<li>switch to using es6 style module syntax and use it on the client and in node with some polyfills/loaders until natively supported</li>
<li>switch to using commonjs style modules and load them with browserify on the client</li>
<li>do a pre-compilation step and transform the shared code to be eligible once for the client side single output compilation and once for the node.js side common.js compilation. However this can have many caveats and sounds like a hack.</li>
</ul>
<p dir="auto">What I'm really looking for is a way for each TypeScript class/file to be able to "say" what is the class it exports, but not specify how it will be consumed, ie. via commonjs or as a single file output. Probably that's not possible though in a simple way?</p>