Invalid code generated with 'export module' declaration

[theRobinator]

Minimal reproduction follows:

test.ts

export module Foo {
    const notAnEmptyModule = 6;
}

Output: test.js

var Foo;
(function (Foo) {
    const /** @type {number} */ notAnEmptyModule = 6;
})(Foo = exports.Foo || (exports.Foo = {}));

Compiling with Closure Compiler v20180101 (the latest at the time of this writing) fails with this error:

vulcan/build/js/test.js:10: ERROR - Exports must be a statement at the top-level of a module
})(Foo = exports.Foo || (exports.Foo = {}));
                         ^^^^^^^^^^^^^^^^

As a workaround, doing the export on a separate line generates working code:

module Foo {
    const notAnEmptyModule = 6;
}
export {Foo};

[evmar]

Within Google we disallow use of namespaces ('module' is an obsolete alias for the 'namespace' keyword here I think), in part because they generate code that confuses Closure compiler. I think in particular if you start nesting module A { module B { you'll find Closure loses what things refer to.

[theRobinator]

@evmar Interesting. Is there a public collection of this kind of thing that confuses the compiler? I'm currently migrating a pretty large (500K LOC) codebase to a Typescript/Closure Compiler stack and it'd be great to know about this kind of stuff. Does this tslint.json cover it?

Our existing codebase declares a lot of properties on functions, and my translation is using declaration merging with namespaces to accomplish this. I assume you use an interface for this instead?

[evmar]

We don't have it well-documented unfortunately. The actual line is always kinda vague and varies with the rules of Closure compiler.

Coincidentally, just today I learned about properties on functions in Closure syntax. Search for "hacky" on http://closuretools.blogspot.com/2017/01/common-pitfalls-when-using-typedefs-in.html . Since I only learned about this today I doubt tsickle does the right thing here, but it might accidentally work.

[evmar]

(Note that by default tsickle leaves types out everywhere, as it's more concerned with "get the compiler to accept this code" than it is about "properly express these types so that the compiler understands them". So it often is the case that things accidentally work.)

[theRobinator]

Doing it using declaration merging actually does look like it works! No type comments are generated for those expressions and so the compiler accepts it.