umd module compiler option doesn't have a fallback for global namespace.

[niemyjski]

Most umd patterns have a third fallback that allows exporting to the window.namesapace = export; As such the current umd module export is pretty broken when a huge number of users / library developers need to support all three.

(function(root, factory) {
  if (typeof define === 'function' && define.amd) {
    define(factory);
  } else if (typeof exports === 'object') {
    module.exports = factory(require, exports, module);
  } else {
    root.exceptionless = factory();
  }
}(this, function(require, exports, module) {}

[kitsonk]

There is no specification for UMD and any interfaces with the global/window object require some specific decisions, like you would have to determine a module name for each module. What names on the global scope would you give these modules, all part of the same project?

src/index.ts
src/feature/index.ts
document.ts

[niemyjski]

If I'm outputting to a single file (like a library like jquery) it becomes very easy to say the export should be namespaced under the file name or module namespace.

https://github.com/umdjs/umd/blob/master/templates/commonjsStrictGlobal.js

We have to support a fallback to globals in our library and I've had to work around this like:
https://github.com/exceptionless/Exceptionless.JavaScript/blob/master/dist/exceptionless.js#L1236-L1264

[mhegazy]

You can find a discussion on why UMD implementation does not support the global in #2605.

mainly, what is the variable name to use, and how to manage dependencies.

One possibility is to use the new export as namespace <id> syntax added in #7264, but we will need a proposal for that.

[Arnavion]

There is precedent [1] [2] for compilers that output UMD to take a separate parameter for the global name. But I guess since you already have export as namespace you might as well use it.

[mhegazy]

//cc: @RyanCavanaugh

[nippur72]

As discussed in #9678, if we use export as namespace for setting the global name, then the export clause needs to be allowed in normal code other than declarations (.d.ts), otherwise library authors that are deriving their declarations from the --declaration flag have to add the clause at each recompile because it's overwritten.

So merging the two needs, my proposal is:

When --module is umd and there's an export as namespace in module code, TypeScript should:

1. emit declaration files .d.ts with the same clause export as namespace
2. provide a fallback for global namespace case.

Example: developer is writing a library "myreact" to be consumed in modules and in global:

myreact.ts:

export function createElement() { return 42; };
export as namespace React;

Typescript output

myreact.d.ts:

export declare function createElement() {};
export as namespace React;

myreact.js:

(function (root, factory) {
    if (typeof module === 'object' && typeof module.exports === 'object') {
        var v = factory(require, exports); if (v !== undefined) module.exports = v;
    }
    else if (typeof define === 'function' && define.amd) {
        define(["require", "exports"], factory);
    }
    else {
        root.React = factory(require, exports); 
    }
})(this, function (require, exports) {
    "use strict";
    function createElement() {
        return 42;
    }
    exports.createElement = createElement;
});

[niemyjski]

@nippur72 something like that could work but you also have to consider that require and exports won't always exist when doing a fallback to browser global and is the exact reason I had to do a hack:

https://github.com/exceptionless/Exceptionless.JavaScript/blob/master/dist/exceptionless.js#L1236-L1264 (which we may not what to do.

[nippur72]

@niemyjski yes the missing require is a problem. Also I don't think your hack covers all the cases, consider for example:

import _ from "lodash";

which translates into the now global code

var _ = require("lodash"); 

which is nothing else than

var _ = window["lodash"]; 

but which is also undefined because lodash is published globally as window._, not window.lodash.

So, we can fake require but still can't do nothing for modules whose global name is different than the respective module name. Is my understanding correct?

[niemyjski]

idk, it's something that has to be looked into...

[unional]

I don't see why the require would be a problem:
https://github.com/umdjs/umd/blob/master/templates/returnExports.js

[unional]

By the way, I did this two years ago, maybe it can be simplified and used in the compiler.