Can access UMD globals from modules (regression?)

[mprobst]

TypeScript Version: Version 3.1.0-dev.20180804

Search Terms: UMD module import export as namespace

Code

// declaration.d.ts
export = angular;
export as namespace angular;

declare namespace angular {
  export interface Scope {}
}
export {};

// user.ts
export {}; // make me a module
let scope: angular.Scope;  // no import!

Expected behavior:

Should fail to compile, as user.ts is a module, but has no import for angular. The global should only be available in scripts, according to the docs:
https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#support-for-umd-module-definitions

Actual behavior:

Compiles without errors.

Playground Link: n/a, needs multiple files.

I believe this to be a regression, at least at some point TS worked as documented, giving an error here.

[mprobst]

Apparently this is specific to types, for values TS works as expected:

console.log(angular.x);  // fails with angular.x being a variable

[mprobst]

@RyanCavanaugh is this a documentation bug then, if working as intended?

[RyanCavanaugh]

@mprobst the docs say "global variable" and a type/namespace is not a variable. We'd take a PR to the TS Handbook repo if you want to add a clarifying remark

[mprobst]

Mh, OK.

For some feedback: I'm maintaining a rather large TypeScript code base (Google's internal monorepo) that has several definitely typed libraries that people depend on. We had expected that the "needs import" restriction applies to all use from a module.

Allowing non-imported use is problematic for us:

• it means code relies on global "background" type definitions.
• it obscures code dependencies
• it circumvents the "must have explicit build level dependency on all imports" constraints we implement in bazel
• it causes code to inconsistently import the module with one prefix for values and use its types with another prefix (in particular for AngularJS, ng vs angular)

We can work around by removing those export as namespace statements in our vendor'ed copy of DefinitelyTyped, but at least for us, this feature is kind of working against code maintainability and our engineering goals in the large monorepo :-)

[RyanCavanaugh]

Good feedback - you may want to voice that in #10178 as well

[FranklinWhale]

@RyanCavanaugh Would you mind explaining why the team decided to have UMD namespaces visible in modules when they can be imported?

[mattmccutchen]

Another Stack Overflow user confused by UMD global types being accessible from modules.