<p dir="auto">To me Typescript seems to be a better choice for writing code where the code base is huge and requires more consistency.</p>
<p dir="auto">But the examples and experiences i find around the internet are more on client side , may be coz of the Angular2.0 decision to use AtScript/Typescript.</p>
<p dir="auto">Though Typescript adds a lot of power to Javascript , there is something that keeps on pissing me off is how to manage codebase with duplicate files.  According to my understanding i can have 2 ways to do it.</p>
<h2 dir="auto">1st Way</h2>
<p dir="auto">Use a build tool like gulp/grunt , watch for changes and compile Typescript to Javascript in the same folder. which may look something like this.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="├── models/
│ ├── User.ts
│ ├── User.js
│ ├── Likes.ts
│ ├── Likes.js"><pre class="notranslate"><code class="notranslate">├── models/
│ ├── User.ts
│ ├── User.js
│ ├── Likes.ts
│ ├── Likes.js
</code></pre></div>
<h2 dir="auto">2nd Way</h2>
<p dir="auto">Another way will be the same but of instead of outputting Javascript into the same folder , i can clone the entire workspace.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="├── typescript
│ ├── models/
│ │ ├── User.ts
│ │ ├── Likes.ts
├── javascript
│ ├── models/
│ │ ├── User.js
│ │ ├── Likes.js"><pre class="notranslate"><code class="notranslate">├── typescript
│ ├── models/
│ │ ├── User.ts
│ │ ├── Likes.ts
├── javascript
│ ├── models/
│ │ ├── User.js
│ │ ├── Likes.js
</code></pre></div>
<p dir="auto">Where both are not the best solution for me , is there any other way to manage codebase for nodejs. For client it is simple as we have only one output file.</p>
<p dir="auto">Hi all,</p>
<p dir="auto">We currently have a AST model for TypeScript which is useful for compilers, editors, and linters.</p>
<p dir="auto">However, it would be extremely useful to have a type model, a la Java's reflective model. There are a huge number of use-cases supporting this, but I will list a few here:</p>
<ul dir="auto">
<li>I have a REST interface and I define a data model for it as a TypeScript interface. I use this interface for the function definition of the REST implementation, but then use the type model to validate the input at runtime.</li>
<li>I have a service model that abstracts an interface for some system (database, or application, etc.). I define this as a TypeScript interface (maybe with some decorators as meta-data), and have a generator library that extracts this information to either generate code - or create a runtime implementation - that actually implements the service.</li>
<li>I have an injection (DI) system. I use injection decorators on class properties/constructor parameters, and use the type model to reflectively wire the correct instance.</li>
</ul>
<p dir="auto">A good example of what could be achieved with this, is something like the Spring platform for Java where our applications are built as decorated components and most of the boilerplate code is abstracted away by the platform thanks to reflection and decorators.</p>
<p dir="auto">I have a "first stab" at implementing such a thing: <a href="https://github.com/christyharagan/ts-schema">typescript-schema</a>. It's not feature complete and the design isn't finished either. But hopefully it gives a feel for what a reflective model could look like.</p>
<p dir="auto">Is this something the TypeScript team would be interested in having as a first class citizen?</p>