Repository navigation
[ts2.6 regression] cannot name symbols referring to types using declare global #20749
Description
TypeScript Version: 2.6.2 & 2.7.0-dev.20171216
Code
// module.d.ts (from the AngularJS typings)
declare var angular: angular.IAngularStatic;
export = angular;
export as namespace angular;
declare namespace angular {
export interface Module {}
interface IAngularStatic {
module(): Module;
}
}
// globalize.d.ts
import * as alias from './module';
declare global {
const angular: typeof alias;
}
// user.ts
export const foo = angular.module();Compile with tsc --declaration
Expected behavior:
In TS2.5, this compiles fine, and produces a .d.ts with export const foo: angular.Module;, i.e. using the global alias for the module-scoped type.
Actual behavior:
In TS2.6+, this complains the symbol cannot be named:
user.ts(2,14): error TS4023: Exported variable 'foo' has or is using name 'angular.Module' from external module ".../module" but cannot be named.
Activity
weswigham commentedon Dec 20, 2017
Two things at play here, and fixing this needs a small patch to the compiler and maybe an update to angular's definitions.
That this worked at all in the first place was due to a bug. #18049 fixed the bug enabling this. UMD aliases should not have been considered visible with modules for declaration emit, since they are not looked up when checked later (and thus will cause downsteam errors in consumers if the types get emitted relying on them). Hence the current error. Now, the global patch is supposed to work around that, I imagine, by always exposing the global - except there are two issues. One is that we don't consider a symbol which is both a UMD symbol and not-a-UMD-symbol as visible in a module since the aforementioned bug fix - I have a correction for that now up at #20837. That's the case here because
export as namespace angularis creating a UMD export symbol, andconst angularindeclare globalis creating another declaration for that symbol (which should probably take priority over the information infered by the UMD one).The other is an issue with your
globalpatch:should only be enough to make a call to
angular.moduletypecheck (which is why you were able to get away with it sometimes), but shouldn't actually reexpose any of the types thealiasnamespace has in the global namespace. So it's return type,Module, should not be nameable even once I change it so that symbols which are both umd exports and not umd exports are considered usable. The types from the UMD export part of the symbol still shouldn't be visible, so you should still need to reexport all of your types in your global patch as well, ie:weswigham commentedon Dec 20, 2017
I adjusted my wording in my prior post to say "should" in many places in the second half because the simple fix in #20837 is insufficient to actually break the negative case correctly; so even if you don't reexport the types in your
globalize.d.ts, it'll still emit types without error (and typecheck the definition file without error); however that's liable to cause errors in downstream consumers (because UMD globals aren't visible within modules, once someone consumes something usinguser.ts's declaration output and tries to print it's type, they'll get visibility errors).In short, #20837 gets the old behavior back for your case, but it's usage is able to cause issues like those mentioned in #16155 (at least if you do not have a complete
declare globalpatch), so you probably shouldn't rely on the types being erroneously made available through the UMD namespace since it causes issues for consumers and we're likely to fix it.weswigham commentedon Dec 17, 2018
This should have been fixed (in 3.2 even) by #28909.