Exported ambient variables are neither emitted nor an error

TypeScript Version:

1.9.0-dev.20160411

Code

foo.ts:

export type Foo = { bar: string; }
declare var foo: Foo;
export { foo };

bar.ts:

import { foo } from "./foo";
console.log(foo.bar);

tsc -t es5 -m commonjs ./foo.ts ./bar.ts

Expected behavior:

Either it should be an error to export an ambient variable, or it should be emitted something like this:

foo.js:

"use strict";
exports.foo = foo;

bar.js:

"use strict";
var foo_1 = require("./foo");
console.log(foo_1.foo.bar);

Actual behavior:

No error, and foo.js is emitted with no export, causing bar.js to blow up at runtime.

foo.js:

"use strict";

[mhegazy]

Just to clarify:

Exporting a name that was not declared in the module is an error as per the ES6 spec. the compiler flags this correctly today. see https://github.com/Microsoft/TypeScript/issues/6323#issuecomment-170170230

Exporting a name that is declared in the module is legal, regardless if it is ambient or not, the emitter should emit it correctly, and this issue is tracking fixing this. so

declare var foo: Foo;
export { foo };

should emit

exports.foo = foo; 

Now, one thing to note, if you are doing this to capture a global variable, which it seems @Arnavion and @ddotlic are doing, then you need to be aware that this is going to be an error if/when your run this code under a native ES6 module implementation. the fact that the compiler does not flag it does not make it ok at runtime. so consider declaring a local name:

var globalWindow = window;
export {globalWindow as window};

[Arnavion]

@mhegazy Yeah, I did think export would only allow local bindings, so yes TS should make that an error.

The intent was to use an external global and annotate it with a local type, so the workaround I went with was:

export type Foo = { bar: string; }
declare var foo: Foo;
var globalFoo = foo; // local binding to global
export { globalFoo as foo };