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

UMD #2215

Open
jamesplease opened this Issue Jan 30, 2015 · 7 comments

Comments

Projects
None yet
6 participants
@jamesplease
Copy link
Contributor

jamesplease commented Jan 30, 2015

Supersedes #2065 and #1433

The built version of Chosen only works with browser globals. Browser globals are falling out of fashion in favor of using module loaders, like AMD or CJS. Unfortunately, it's a bit of a pain for developers using those systems to integrate Chosen into them.

You can support the most common use cases of Chosen with a (fairly ugly) wrapper. Chosen's wrapper looks like this.

There's no question that it really sucks to include the wrapper, because it's added source code, but some folks feel that the benefits outweigh the cons. Some of the benefits are:

  • Chosen works with AMD and CJS out of the box
  • You don't force developers to use browser globals to use with Chosen
  • It would makes sense to publish Chosen on NPM, because it will work in Node
  • I can delete my fork of the project : D

Applying the wrapper can be easily done with an extra grunt task. I usually use grunt-preprocessor to wrap my files. I can make the PR if you wish.

If you add the wrapper, I would suggest that you add the repo to npm. Then, you could run npm publish after you've built the library to be distributed as a zip file, and the npm version would get the updated build.

whatcha think

@koenpunt

This comment has been minimized.

Copy link
Member

koenpunt commented Mar 5, 2015

What is wrong with a shim for Chosen? Not that I would be against a wrapper, but is there any real use to it?
Also, this is a valid comment: jashkenas/underscore@0d4b124#commitcomment-857644

{
// ...
  shim: {
    chosen: {
      deps: ['jquery']
    }
  }
// ...
}
@jamesplease

This comment has been minimized.

Copy link
Contributor

jamesplease commented Mar 5, 2015

UMD makes it easier for developers to consume your library. Your quote from Jeremy is 2.5 years old, and his two most popular libraries continue to ship UMD to this day.

@benmccormick

This comment has been minimized.

Copy link

benmccormick commented Apr 8, 2015

👍 To this. UMD reduces configuration for developers using module loaders, encourages modern practices and adds a minimal amount of extra code (that you can add as a build step if you like).

@JustBlackBird

This comment has been minimized.

Copy link

JustBlackBird commented Jun 26, 2015

+1 UMD simplifies using of the library in the most cases. Chosen should not force developers to use browser's globals.

@fkm

This comment has been minimized.

Copy link

fkm commented Jan 29, 2018

What is the status of this request? Is it under consideration or in progress?

@stof

This comment has been minimized.

Copy link
Collaborator

stof commented Jan 29, 2018

Nobody is working on this among maintainers. However, I think that this request is legitimate. So I welcome contributions if someone wants to work on this.

@fkm

This comment has been minimized.

Copy link

fkm commented Mar 20, 2018

Sorry for the tardy response. I don't have much spare time at the moment. But if I find any, I'll create a PR.

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