The template.js fails to evaluate on Java 8 Nashorn. Nashorn doesn't support any module system like AMD out of the box and there's neither global nor window. The global context is available via this.

Please add another fallback to this in template.js.

This refers to: facebook/react#3037

UMD-packaged modules are designed to work in any environment. Unfortunately they don't work in very many client-side packaging systems (I tried browserify and requirejs, webpack works).

Here's the scenario: ./x.js requires ./y.js and we do browserify --standalone x x.js > ./temp/a.js. If I require a from Node or drop it in a browser everything works. Great.

Now I create ./temp/b.js which requires ./a.js and I do browserify b.js from ./temp/. It throws with Error: Cannot find module './y' because the word require() is used within the source still.

This is common behavior in many of the popular browser packaging systems I mentioned. They just look for calls to a function named require().

My solution to this is to syntax transform the require literal when used as a function argument or function call to muffin. Would a pull request that does something like this (with a more mangled identifier) be accepted? It would require esprima.

I was going to use this for component but the odd stream usage makes it kinda unusable :(

As mentioned in #23, I think there are some changes that should be made to casing:

• Use a module dependency for camel casing
• Throw if the name begins with an invalid leading character that's valid later in an identifier (e.g. a number) (instead of just stripping it)
• Throw if there are any invalid characters (instead of stripping them)

This could all get pulled out to a module as well.

Then there's the trickier issue of having automatic behavior at all. As mentioned in browserify/browserify#1210 (comment), it's potentially unexpected. But there are presumably a whole lot more people who ultimately want the behavior that's present now (camel casing) and would have to implement the casing on their own if it were removed as part of a major version.

In order to make it customizable, browser-pack would have to be updated to allow an object for opts.standalone and Browserify's docs would need updating.

Currently UMD uses just a static prelude part which looks like

var templateSTR = "(function(f){if(typeof exports===\"object\"&&typeof module!==\"undefined\"){module.exports=f()}else if(typeof define===\"function\"&&define.amd){define([],f)}else{var g;if(typeof window!==\"undefined\"){g=window}else if(typeof global!==\"undefined\"){g=global}else if(typeof self!==\"undefined\"){g=self}else{g=this}defineNamespace()}})(function(){source()});";

as you see amd part in this template looks like define([],f)

But some times modules you are producing depends on other modules,
and if you going to use your modules in AMD environment it should be able to list those dependencies in a define part of a umd template:

define(['dep1', 'dep2'], f);

There is an issue opened for browserify: browserify/browserify#1225
where my last two comments describes in depth why these dependencies should be listed in a define part of umd template.

I think there should be additional options for both cmd and runtime usage like:

umd(name, source, {deps: ['dep1', 'dep2']})

so these dependencies will become a part of a prelude header.

Hey Forbes,

Currently, umd places var define,module,exports; at the top of the generated factory function, making it impossible to 'use strict'; for wrapped code.

Would you be open to adding support for this in one way or another? One simple solution could be to add a useStrict property to the options object. I'd be happy to work on a pull request for this, if it's a feature you'd like to add.

As noted in this stackexhange post, umd doesn't allow non-alphanumeric functions, which means this give an error: browserify --standalone $ foo.js.

Using the dollar sign would be useful in places where you want to mimic a certain popular library's API. I'll admit that, running browserify -s replaceme foo.js | sed -e 's/replaceme/\$/g isn't that hard, but it seems brittle.

What's the recommended pattern for declaring dependencies?

I'm bundling a component using browserify with the externals option. I would like to use the standalone option as well, but the umd template doesn't support dependencies.

In the meantime I'm wrapping browserify's output using grunt-umd, but would prefer to have this be something the "standalone" option handles.

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

The devDependency mocha was updated from 6.0.2 to 6.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency uglify-js was updated from 3.7.4 to 3.7.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

uglify-js is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

define.amd){define([],f)}
how it support amd the right way maybe
define.amd){define('defineNamespace',[],f)}

I would expect this to define window.ABCDEFG to 555, but instead it defines window.aBCDEFG which is weird and surprising in a bad way.

$ browserify --standalone ABCDEFG <(echo 'module.exports = 555')

(function(e){if("function"==typeof bootstrap)bootstrap("abcdefg",e);else if("object"==typeof exports)module.exports=e();else if("function"==typeof define&&define.amd)define(e);else if("undefined"!=typeof ses){if(!ses.ok())return;ses.makeABCDEFG=e}else"undefined"!=typeof window?window.aBCDEFG=e():global.aBCDEFG=e()})(function(){var define,ses,bootstrap,module,exports;
return (function(e,t,n){function i(n,s){if(!t[n]){if(!e[n]){var o=typeof require=="function"&&require;if(!s&&o)return o(n,!0);if(r)return r(n,!0);throw new Error("Cannot find module '"+n+"'")}var u=t[n]={exports:{}};e[n][0](function(t){var r=e[n][1][t];return i(r?r:t)},u,u.exports)}return t[n].exports}var r=typeof require=="function"&&require;for(var s=0;s<n.length;s++)i(n[s]);return i})({1:[function(require,module,exports){
module.exports = 555

},{}]},{},[1])(1)
});

Is there a reason umd auto uglifies the template, instead of relying on the consumer to do so? I was thinking of submitting a patch that helps browserify produce more readable output, but wanted to know if there was a use case I was missing first.

EDIT: Sorry about the prelude mention, I completely got this confused with browser-pack. But I think my primary question is still valid as to why uglify is being applied within, instead of at a top level.

Related to: browserify/browserify#534

Given the following set of options:

umd A.B.C index.js

One would expect the generated UMD snippet to preserve the nested object relationship, such that:

((ref$ = (window.A || window.A = {}).B) || ref$.B = {}).C = entryPoint()

Otherwise this creates a somewhat horrible problem with making several micro-modules standalone.

Why can't I use requiure() after browserify main.js --standalone mymodule > bundle.js?

The CLI is great but at least two of the options provided could be derived from package.json

name can be taken from the package's name, and source would be from the package's main. This would leave only specifying the destination (or still piping to STDOUT)

I would love to be able to say just umd | tee dist/module.js | uglifyjs > dist/module.min.js for example.

Uglifyjs minifaction causes problems when generating trying to generate standalone UMD modules with browserify.

Is it minification really necessary? Shouldn't it be optional at the very least?