Skip to content
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

Migrated to commonjs format #71

Closed
wants to merge 1 commit into from

Conversation

anvaka
Copy link

@anvaka anvaka commented Apr 17, 2015

Hello guys,

I am not sure whether this repository is still maintained, but I thought I would share with you regardless. Hope someone will find this useful.

This build makes dat.gui commonjs friendly and allows it to be consumed as a regular commonjs package.

All tests are passing, API is backward compatible.

This build makes dat.gui commonjs friendly and allows it to be consumed
as a regular commonjs package.

All tests are passing, API is backward compatible.
@doug
Copy link
Contributor

doug commented Jun 3, 2015

Thanks for this 👍 . For people concerned about a change like this we will still just keep building this as a single javascript file regardless of requirejs vs commonjs for the components. So for most people this shouldn't change anything. I too am in favor of the commonjs format over requirejs. More people seem to use it currently. @jonobr1 or @georgealways either of you care to weigh in? My only hesitation is this doesn't change things a great deal and we would probably want to change again once es6 modules are broadly adopted. http://www.2ality.com/2014/09/es6-modules-final.html

@korczis korczis mentioned this pull request Aug 14, 2015
@ffflabs
Copy link

ffflabs commented Nov 4, 2015

I'm using requirejs to bundle dat.gui into my build. I can't use the sigle file version because it exports to the global namespace even when user as AMD.

So 👎 to this PR.

@andyinabox
Copy link

👍 for browserify compatibility.

@ffflabs
Copy link

ffflabs commented Jan 6, 2016

During the last two months I've been using dat.gui source as a dependency of my GUI component, so at build/bundle time everything is inlined as small AMD modules into just one module. I've got to say it's been a pain in the ass.

I mean, the modular source is still meant to build a monolithic dat.gui script. When you want to include dat.gui in another module, you need to aliase all named modules and, still, loader plugins are not universal among AMD loaders. The text! plugin, for example, is hard to use with JSPM, unless you specify the pluginFirst option somewhere to true.

At this point I'd feel much more comfortable having a modular dat.gui build that could be required (without polluting the global scope) than I am with integrating AMD modules in another project, so if it's worth anything, I do recast my vote as 👍

@customlogic
Copy link
Contributor

This PR has been superceded by #78, which migrated to common.js as well as converted code to ES6 modules. Thanks for your work on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants