New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build as UMD #12

Closed
xMartin opened this Issue Nov 22, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@xMartin
Copy link

xMartin commented Nov 22, 2014

Would be great to have this available to AMD loaders as well. I tried browserify's --standalone option and it works for me.

@nolanlawson

This comment has been minimized.

Copy link
Member

nolanlawson commented Nov 23, 2014

Sorry, that's just not something I plan to do. Too many JavaScript build systems, too little time. :/

@xMartin

This comment has been minimized.

Copy link

xMartin commented Nov 23, 2014

Arguments for building as UMD:

  • AMD is probably by far the most widespread format
  • PouchDB already does it so it would be consistent
  • The build system currently being used, browserify, supports it out of the box (--standalone)

Plugins behave differently depending on if being loaded with a script tag or required as a module. In case of the script tag the plugin is automatically registered and nothing is exposed/exported. UMD (and thus browserify's --standalone option) require exposing a global as the module's export if no module loader is present. What would that be in case of PouchDB plugins? (It could just be something like "PouchDBPluginNAME", it wouldn't be used anyway.)

In package.json:

-    "build": "mkdir -p dist && browserify index.js -o dist/pouchdb.all-dbs.js && npm run min",
+    "build": "mkdir -p dist && browserify index.js --standalone PouchDBPluginAllDbs -o dist/pouchdb.all-dbs.js && npm run min",
@nolanlawson

This comment has been minimized.

Copy link
Member

nolanlawson commented Nov 23, 2014

The reason PouchDB uses --standalone is expressly because we want to expose the global PouchDB object. For plugins we really don't want to pollute the global namespace and cause developer confusion by having a non-functional global for every plugin you add.

I do sympathize, the JavaScript module system is a mess (this article hits the nail on the head), but I maintain a lot of PouchDB plugins and this is just a lot of effort with very little payoff as well as some negative externalities IMO.

People using RequireJS etc. are fully welcome to npm install and then build the --standalone build themselves, or just add a script tag like we've been doing with JavaScript since time immemorial. I don't think it should be the responsibility of module maintainers to support every build system ever, so I'm also kind of philosophically opposed to this. Thanks for the discussion, though; I didn't know that about AMD and --standalone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment