<p dir="auto">This issue is explained in details in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="69690167" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/2839" data-hovercard-type="issue" data-hovercard-url="/microsoft/TypeScript/issues/2839/hovercard" href="https://github.com/microsoft/TypeScript/issues/2839">#2839</a></p>
<h2 dir="auto">Terminology</h2>
<p dir="auto">Through out this issue, i will be referring to different ways of declaring external modules, here are what i mean by them.</p>
<h4 dir="auto">Ambient external module declaration</h4>
<p dir="auto">Module declarations of the form:</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="declare module &quot;mod&quot; {
    ....
}"><pre class="notranslate"><span class="pl-k">declare</span> module <span class="pl-s">"mod"</span> <span class="pl-kos">{</span>
    ...<span class="pl-kos">.</span>
<span class="pl-kos">}</span></pre></div>
<h4 dir="auto">Proper external modules</h4>
<p dir="auto">The other way of writing a declaration of a module, i.e. a declaration file with a top level <code class="notranslate">import</code> or <code class="notranslate">export</code>; e.g.:</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="import { Contract } from &quot;.\core&quot;
export var MyContract: Contract;"><pre class="notranslate"><span class="pl-k">import</span> <span class="pl-kos">{</span> <span class="pl-smi">Contract</span> <span class="pl-kos">}</span> <span class="pl-k">from</span> <span class="pl-s">".\core"</span>
<span class="pl-k">export</span> <span class="pl-k">var</span> <span class="pl-smi">MyContract</span>: <span class="pl-smi">Contract</span><span class="pl-kos">;</span></pre></div>
<h4 dir="auto">Script file</h4>
<p dir="auto">A file that is not a module, i.e. does not include a top level <code class="notranslate">import</code> or <code class="notranslate">export</code>. it could however, include ambient external module declarations as described above.</p>
<h2 dir="auto">Background</h2>
<p dir="auto">With module resolution work done in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="99076428" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/4154" data-hovercard-type="pull_request" data-hovercard-url="/microsoft/TypeScript/pull/4154/hovercard" href="https://github.com/microsoft/TypeScript/pull/4154">#4154</a> and <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="101743391" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/4352" data-hovercard-type="pull_request" data-hovercard-url="/microsoft/TypeScript/pull/4352/hovercard" href="https://github.com/microsoft/TypeScript/pull/4352">#4352</a>, it is possible for node package authors to distribute typings with their packages. For these packages, users do not have to independently acquire the typings from definitely typed, but will just <code class="notranslate">import</code> the package, the the compiler will locate the typings in the package directory (either <code class="notranslate">index.d.ts</code> or by following <code class="notranslate">typings</code> property in <code class="notranslate">package.json</code> in the package directory).</p>
<p dir="auto">As noted in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="69690167" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/2839" data-hovercard-type="issue" data-hovercard-url="/microsoft/TypeScript/issues/2839/hovercard" href="https://github.com/microsoft/TypeScript/issues/2839">#2839</a>, for a package author interested in distributing their typings with their package, there are dependencies that they need typings for; the most common would be <code class="notranslate">node.d.ts</code>, which is possibly referenced by each package.</p>
<p dir="auto">The way they dependency typing are authored today on definitely typed is using <em>ambient external module declaration</em>; this indicates that these typings exist in the global scope, and thus are susceptible to conflicts. The classic the diamond dependency issue (courtesy of <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/poelstra/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/poelstra">@poelstra</a>):</p>
<ul dir="auto">
<li>myprogram
<ul dir="auto">
<li>mylib
<ul dir="auto">
<li>myutils@1.0</li>
</ul>
</li>
<li>myotherlib
<ul dir="auto">
<li>myutils@2.0</li>
</ul>
</li>
</ul>
</li>
</ul>
<p dir="auto">Now, if <code class="notranslate">myUtils.d.ts</code> uses <em>ambient external module declaration</em>, this is guaranteed to result in re-declaration errors.</p>
<h2 dir="auto">Proposal</h2>
<p dir="auto">When resolving an <code class="notranslate">import</code> target in a node module, it is an <strong>error</strong> to include files that are <strong>not</strong> either:</p>
<ol dir="auto">
<li><strong>Proper external modules</strong>, or</li>
<li>A <strong>Versioned script file</strong> - see below</li>
</ol>
<p dir="auto">For proper external modules, there are no conflicts expected, as external modules do no polute the global namespace.</p>
<p dir="auto">For versioned files, referring to the same library, the compiler will follow a <em>conflict resolution</em> logic picking only the <strong>latest</strong> copy (as described by <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/basarat/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/basarat">@basarat</a> in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="69690167" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/2839" data-hovercard-type="issue" data-hovercard-url="/microsoft/TypeScript/issues/2839/hovercard?comment_id=94630741&amp;comment_type=issue_comment" href="https://github.com/microsoft/TypeScript/issues/2839#issuecomment-94630741">#2839 (comment)</a>). The files provided on the command line will be allowed to override this conflict resolution policy.</p>
<h2 dir="auto">Versioned files</h2>
<p dir="auto">These are files declaring an <strong>identity</strong>, i.e. a name and a version. A versioned file is expected to contain a comment at the top of the form</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="/// &lt;library name=&quot;myLibraryName&quot; version=&quot;1.0.23.2-beta&quot; /&gt;"><pre class="notranslate"><span class="pl-c">/// &lt;library name="myLibraryName" version="1.0.23.2-beta" /&gt;</span></pre></div>
<p dir="auto">Where the <code class="notranslate">name</code> field is optional, and if committed, the file name is used instead, and the <code class="notranslate">version</code> field follows the version definition in <a href="http://semver.org/" rel="nofollow">http://semver.org/</a></p>
<p dir="auto">TypeScript support only two way of TSX transformation:</p>
<ol dir="auto">
<li>Preserve. I can compile to preserve and process file by classic JSX transform. This way support many framework.</li>
<li>React. This is hard coded transformation only for React. This way is not honest in relation to other frameworks.</li>
</ol>
<p dir="auto">I want to use TSX view on difference frameworks, such as angular 1/2, mithril, vanilajs and others. Maybe well be better make not a hard coded transformation? Maybe better way well be make customizable transformation rule, based on d.ts.</p>