Currently, the package.json file is mainly meant to install the dev requirements of Chosen for developers.

As it is a library working only in the browser, not on the server side, does it make sense to have it on npm ? (this is a real question, I'm not a node.js developer at all but a PHP guy, so I don't know the npm conventions)

The main reason is to use Browserify so that in JS we can do var Chosen = require('Chosen'); instead of dropping script tag a bit everywhere. Server-side JS already uses the require format, browserify simply parses the requires (to simulate the nice module definition node.js got, but for front-end) and converts it into a big final build.js (with all the dependencies bundled) file to serve to index.html.

+1 on this issue — I use browserify and use chosen in my app but currently I have to put it in vendor directory which is really annoying

+1 on this as well. With Browserify it makes a lot of sense to be on NPM.

+1 from me, too :) Also using browserify

+1

+1

+1

+1

If you need this plugin only can do $ and jQuery into global scope and later chosen = require(../path/chosen.min.js)

example:

 var $ = require('jquery');
 window.$ = $;
 window.jQuery = $;
 var chosen = require(./chosen.jquery.min.js)

and you can use in your code $('select').chosen();

Source: http://www.codefornow.com/2014/06/08/browserify-jquery-and-jquery-plugins/

+1

+1

+1 for browserify support please

The fix here is pretty easy, I think.

1. Add a UMD wrapper
2. Add the built files to the repo
3. Publish the built files to npm

If the chosen team is interested in such a PR, let me know and I'll put something together. The built files could also be put on Bower, and then there shouldn't be any problems with developers using Chosen.

@jmeas

Add the built files to the repo

This is not going to happen. We used to do this, and it was a nightmare for the team. The compiled JS + CSS will not be added to the repo -- this has been discussed many times on the issue tracker.

Pre-compiled versions are provided via the releases page. If your package manager of choice supports specifying packages via ZIPs, you should use them. See the bower instructions for an example.

If your package manager of choice does _not_ support ZIPs or using the GitHub releases API, you should open an issue with them to add support for this.

Browserify users, you have two choices that I know of. The first is described above, but I'll summarize it once more:

Solution one: use Bower and the window

Follow the instructions in the README. Unfortunately, you cannot use npm, as far as I know, so set up bower in your project and install the zip. Add a module to your code with the following stuff:

var $ = require('jquery');

// Chosen requires this :(
window.jQuery = $;

require('path/to/bower_components/chosen_v1.3.0/chosen.jquery');

And it works! jQuery will, as you'd expect, be permanently modified, so you won't need to require chosen anywhere else in the app.

I recommend that you ensure that your linter throws an error if you try to access browser globals to ensure that you don't start referencing this window.jQuery anywhere else in your code.

Uninterested in bower and the window? I feel ya. A second option is to...

Solution two: wrap it yourself

My apps often have vendor directories for the handful of libraries that aren't packaged to handle module loaders. If you add this UMD wrapper around chosen, then you can require it in as usual. This wrapper will also work for AMD users.

Why not just use browserify-shim?

This is definitely an option. My app's tests run in Node+JSDom, so it needs to work without shimming or aliasing the libraries.

By the end of the week I hope to have a build of Chosen on npm and bower that is UMD wrapped, so folks can just install from there in the future w.o. any problems. I'll keep it up to date if you remind me, so if you're some future reader and my fork is out of date, just open an issue and I can cut a release.

:+1: for native bower component. Would like to be able to import scss files directly.

+1 for adding Chosen package to npm.

+9001 for adding Chosen package to npm.

It seems like development on Chosen is at a slow point (for now, at least) and the maintainers don't seem interested in updating the environments that Chosen works in.

The best way forward would prob. be to just fork this project to add npm support (and, if you wanted, UMD support, too!). You could publish a new release on npm/Bower (maybe under modern-chosen?) then open a PR to upstream the changes.

If they merge it, great – you can deprecate your module. Otherwise people will start using your fork instead.

(I'm using "you" in the sense of "whomever," rather than any particular person :P )

What is the difficulty is adding a package definition in the bower-chosen fork? Is it laziness or incompetency? At the very lease you can satisfy node users to a degree instead of hosing them completely.

What is the difficulty is adding a package definition in the bower-chosen fork? Is it laziness or incompetency? At the very lease you can satisfy node users to a degree instead of hosing them completely.

Such a thoughtful comment.. Remember that it's open source, and everybody is contributing in their free time. Besides that, every extra feature has to be maintained, which costs time. But sure, since there is the bower-chosen repo, a npm package shouldn't be far away.

@pfiller maybe we should rename bower-chosen to chosen-packaged (or something else that isn't related to a specific manager) and include a package.json in the repo.

I've setup a PR (#2550) which should take care of an npm package, please review is the example package attached to that PR is how this package should look like. Thanks!

2550 is merged and Chosen is now also on NPM as chosen-js

@koenpunt Thanks! Problem is the package contains built files, so can't import raw scss.

Related: #2347