<p dir="auto">It seems in most typescript projects, the build setup will have tslint, tsc, and some form of minifier. This is also closely related to <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="37903148" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/8" data-hovercard-type="issue" data-hovercard-url="/microsoft/TypeScript/issues/8/hovercard" href="https://github.com/microsoft/TypeScript/issues/8">#8</a>. The build setup also has someway of deciding whether to invoke the build pipe depending on what files have changed.</p>
<p dir="auto">I believe typescript should have plugins just like babel. Basically the compiler has hook points at various before/after stages, plugins can modify scanner behaviour, parser behaviour, emitter behaviour.</p>
<p dir="auto">This means tslint can hook in and do its checks at parser/scanner stage. There could be a plugin to support a much stronger inference, kind of like flow at the checker stage. The minifier can hook in the emitter stage.</p>
<p dir="auto">I could write a plugin to support extra syntatic sugar. e.g is isn't, and, or, not.  a plugin to support Coffeescript like omission of parenthesis and curly braces.</p>
<p dir="auto">There could be a plugin to inline function calls, or a plugin to output computationaly intensive code as asm, or wasm.</p>
<p dir="auto">There could be a plugin to cache the AST's so when the same file is encountered with the same hash, it can load the AST from cache speeding up the compiler.</p>
<p dir="auto">This would mean typescript does what it needs to do the best, the community can build plugins rather than having to fork the whole typescript project to support a simple feature.</p>
<p dir="auto">tsconfig.json would have a plugins array and just like npm init, tsc can auto download the plugins if it doesn't have them.</p>
<p dir="auto">What do you think?</p>
<p dir="auto">We get "bug reports" of this nature very often:</p>
<blockquote>
<p dir="auto">I wrote this code</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="interface Window {
  myPlugin: any;
}
let x = window.myPlugin;
class Foo { }"><pre class="notranslate"><span class="pl-k">interface</span> <span class="pl-smi">Window</span> <span class="pl-kos">{</span>
  <span class="pl-c1">myPlugin</span>: <span class="pl-smi">any</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span>
<span class="pl-k">let</span> <span class="pl-s1">x</span> <span class="pl-c1">=</span> <span class="pl-smi">window</span><span class="pl-kos">.</span><span class="pl-c1">myPlugin</span><span class="pl-kos">;</span>
<span class="pl-k">class</span> <span class="pl-smi">Foo</span> <span class="pl-kos">{</span> <span class="pl-kos">}</span></pre></div>
<p dir="auto">then I added 'export' and I get compile errors, wat?</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="interface Window {
  myPlugin: any;
}
let x = window.myPlugin;
export class Foo { }"><pre class="notranslate"><span class="pl-k">interface</span> <span class="pl-smi">Window</span> <span class="pl-kos">{</span>
  <span class="pl-c1">myPlugin</span>: <span class="pl-smi">any</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span>
<span class="pl-k">let</span> <span class="pl-s1">x</span> <span class="pl-c1">=</span> <span class="pl-smi">window</span><span class="pl-kos">.</span><span class="pl-c1">myPlugin</span><span class="pl-kos">;</span>
<span class="pl-k">export</span> <span class="pl-k">class</span> <span class="pl-smi">Foo</span> <span class="pl-kos">{</span> <span class="pl-kos">}</span></pre></div>
</blockquote>
<p dir="auto">Our current answer today is "Move your stuff to another .d.ts file". This is an OK workaround, but not great. The real sticker is when there's a type defined inside an external module -- it's impossible to use those types to augment a global interface, even though this is a thing that actually happens. It gets even trickier because this encourages people to move types <em>into</em> the global namespace when they didn't want to in the first place, exacerbating the problem.</p>
<p dir="auto">We need some proposal for how to make this work.</p>