{"action":"created","issue":{"url":"https://api.github.com/repos/Microsoft/TypeScript/issues/983","labels_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/983/labels{/name}","comments_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/983/comments","events_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/983/events","html_url":"https://github.com/Microsoft/TypeScript/issues/983","id":47094780,"number":983,"title":"Global type references","user":{"login":"ahejlsberg","id":4226954,"avatar_url":"https://avatars.githubusercontent.com/u/4226954?v=3","gravatar_id":"","url":"https://api.github.com/users/ahejlsberg","html_url":"https://github.com/ahejlsberg","followers_url":"https://api.github.com/users/ahejlsberg/followers","following_url":"https://api.github.com/users/ahejlsberg/following{/other_user}","gists_url":"https://api.github.com/users/ahejlsberg/gists{/gist_id}","starred_url":"https://api.github.com/users/ahejlsberg/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ahejlsberg/subscriptions","organizations_url":"https://api.github.com/users/ahejlsberg/orgs","repos_url":"https://api.github.com/users/ahejlsberg/repos","events_url":"https://api.github.com/users/ahejlsberg/events{/privacy}","received_events_url":"https://api.github.com/users/ahejlsberg/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Microsoft/TypeScript/labels/Declined","name":"Declined","color":"556677"},{"url":"https://api.github.com/repos/Microsoft/TypeScript/labels/Suggestion","name":"Suggestion","color":"006b75"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":18,"created_at":"2014-10-28T23:29:55Z","updated_at":"2015-04-28T00:01:05Z","closed_at":"2015-04-27T23:39:23Z","body":"When a type declaration in an inner module has the same name as a type declaration in an outer module, the outer declaration becomes inaccessible. Programmers can typically work around this, for example by deriving a type with an alternate name in the outer module or, with our latest changes, by declaring a type alias. However, such manual work-arounds are not a good option for code generation tools such as the .d.ts generation facility provided by the compiler. We really need a fool proof way to ensure a lookup starts at the global scope. Consider:\r\n```typescript\r\nfunction makeError(): Error {\r\n    return new Error(\"We've got a problem\");\r\n}\r\n\r\nmodule M {\r\n    export class Error {\r\n    }\r\n    export var x = makeError();  // No way to name global Error type here\r\n}\r\n```\r\nIt is currently impossible to create a .d.ts file for the code above because there is no way to emit a type annotation for `x` that references the global interface `Error`.\r\n\r\nNode.js uses the name `global` for the global scope. We could consider supporting something similar in type names. Specifically, if a qualified type name starts with the identifier `global` and if a lookup of `global` as a module name doesn't bind to anything (meaning the user didn't define a `global` module), then we consider it a globally qualified name. For the example above we could then generate the following .d.ts file:\r\n```typescript\r\ndeclare module M {\r\n    class Error {\r\n    }\r\n    var x: global.Error;\r\n}\r\n```\r\nIf course, if the user defines their own `global` module we now have a problem again--but I think it is fine to just say you shouldn't do that. We could even consider making it an error, or allowing it only under a compiler switch."},"comment":{"url":"https://api.github.com/repos/Microsoft/TypeScript/issues/comments/96853912","html_url":"https://github.com/Microsoft/TypeScript/issues/983#issuecomment-96853912","issue_url":"https://api.github.com/repos/Microsoft/TypeScript/issues/983","id":96853912,"user":{"login":"basarat","id":874898,"avatar_url":"https://avatars.githubusercontent.com/u/874898?v=3","gravatar_id":"","url":"https://api.github.com/users/basarat","html_url":"https://github.com/basarat","followers_url":"https://api.github.com/users/basarat/followers","following_url":"https://api.github.com/users/basarat/following{/other_user}","gists_url":"https://api.github.com/users/basarat/gists{/gist_id}","starred_url":"https://api.github.com/users/basarat/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/basarat/subscriptions","organizations_url":"https://api.github.com/users/basarat/orgs","repos_url":"https://api.github.com/users/basarat/repos","events_url":"https://api.github.com/users/basarat/events{/privacy}","received_events_url":"https://api.github.com/users/basarat/received_events","type":"User","site_admin":false},"created_at":"2015-04-28T00:01:05Z","updated_at":"2015-04-28T00:01:05Z","body":"Internal modules seem to cause more pain than joy. So I am :cool: with this."}}