Add support for CommonJS & AMD

[rnicholus]

Please see #690 for details.

[feltnerm]

Bumping this.

• Latest jQuery is going to use AMD modules. Proof there is a clear push for JS libraries to support AMD, and that it is more than possible.
• We already have pull request demonstrating that this is possible.
• Being able to use a node-like require system would greatly enhance the custom build process

[rnicholus]

Yep, lets make this happen in 4.2.

[pherrymason]

How's the state of this?
I'm trying to use fineuploader in a CommonJS environment and qq object evaluates to MegaPixImage.

[feltnerm]

@raulferras -- We have been punting on this in lieu of other features and bug fixes. Could you post your code/issue on StackOverflow? Maybe we can at least help debug your issue as Fine Uploader should still work in CommonJS environments.

[Ixonal]

Sorry to resurrect an old issue, but I think this needs to be looked at again. Fine Uploader is currently impossible to import if using Type Script, since there are no exports, and the compiler eliminates any import statements for which exported items aren't used. So, even if I require the file, that require statement is removed from the generated code.

It's the same sorta problem as this:
http://stackoverflow.com/questions/16455211/typescript-import-module-with-only-statements

I'm not sure about Babel or Traceur, they may or may not have this behavior when transpiling.

[rnicholus]

@Ixonal I can't guarantee support for TypeScript as I don't use (or ever plan to use) TS. However, I am aware of the need to make integration w/ AMD/CommonJS/ES6 Modules a bit easier. At the moment, I'm the only one available to tackle these sorts of things, so if you think this can be solved in a quick PR without breaking anything else, I would be willing to take a look and consider it for a near-future release.

[feltnerm]

https://github.com/FineUploader/fine-uploader/compare/feature/umd (specifically 697e6e9) has the initial work required the make this happen.

Seems like some tests were failing, and then this got de-prioritized, but should be a good launch point for anyone wanting to make this happen.

[Ixonal]

All that should be required is some form of export, be it amd, umd, commonjs, or ecma 6 module syntax. Use feature detection to determine which module system is being used, and you should be able to just export the qq object. For example, if the "System" object exists in the global namespace, and "System.import" is a function, then you can assume ecma 6. If "require" exists in the global namespace, and "require.amd" is an object, then you can use amd. Etc...

I can't imagine it'd take too horribly long to implement.

[rnicholus]

There are a couple other namespaces to maintain, other than qq. Currently, ExifRestorer and CryptoJS. I'm guessing we don't want these to remain global objects, so that will need to be accounted for as well.

[Ixonal]

simplest solution would probably be to just wrap them all in a parent object and export that.

[rnicholus]

Yes, I think perhaps the way to handle this may be to wrap the entire concatenated JS file in an IIFE, and then, as you suggested, export the qq object based on the type of module system available. Am I missing something?

[Ixonal]

Sounds about right. Knockout has a pretty good example of doing that, if you want to take a look at it.

[rnicholus]

It sounds fairly straightforward, but nothing is ever as simple as it seems. I'm a bit apprehensive to commit any changes and call this "done" though, as I'm not making use of any module loaders in any of my code. I could give it a whirl as part of 5.4.0, but we'd need some confirmation from users who rely on these systems, such as yourself.

[Ixonal]

I can try it out and see, yeah. It shouldn't be much effort to set up some tests for this. At least, so far as browser-based loaders. CommonJs would require a node instance.

[rnicholus]

The quickest solution here is going to involve properly exporting qq object. Seems like this is the most important goal, and shouldn't be too difficult.

Everything else (build enhancements, exporting each internal module, etc) is secondary and not something I have time to complete at the moment. I've moved this into 5.4.0.

[rnicholus]

For proper module support, I imagine we will need to do a bit of refactoring. To make this less confusing to use and document, since we will still want to support users who do not want to use a module system to import Fine Uploader, there will probably need to be some breaking changes. I think this is a prudent time to remove the qq namespace, and instead make everything available via a FineUploader object.

For CommonJS support, I imagine all of the individual source files that make up Fine Uploader already will be exported as modules. The root of the distributed directory will contain several JavaScript files, such as "s3.js", "azure.js", "ui.js", etc. Each of these will pull in other required dependencies from the library.

So, if a user wants to pull in Fine Uploader core for traditional endpoints:

var FineUploader = require('fine-uploader')
var uploader = new FineUploader({
   // define config option values
})

The above module will be represented by a "fine-uploader.js" entry point file in the root of the fine-uploader distribution directory.

If a user wants to pull in Fine Uploader UI for traditional endpoints:

var FineUploader = require('fine-uploader/ui')
var uploader = new FineUploader({
   // define config option values
})

The above module will be represented by a "ui.js" entry point file in the root of the fine-uploader distribution directory.

If a user wants to use Fine Uploader S3 w/out the UI modules, their code will look something like this:

var FineUploaderS3 = require('fine-uploader/s3')
var uploader = new FineUploaderS3({
   // define config option values
})

The above module will be represented by a "s3.js" entry point file in the root of the fine-uploader distribution directory.

If a user wants to pull in Fine Uploader UI for S3 endpoints:

var FineUploader = require('fine-uploader/s3-ui')
var uploader = new FineUploader({
   // define config option values
})

The above module will be represented by a "s3-ui.js" entry point file in the root of the fine-uploader distribution directory.

...etc. At least, this is how I would expect it to be structured at the moment.

[powerbuoy]

This is something we would very much like to see too :) FYI.

$ npm install fine-uploader --save-dev and var qq = require('fine-uploader') would be so nice to be able to do.

[rnicholus]

This is a priority for 6.0, but I see a lot of work ahead in order to do this properly.

[rnicholus]

In light of the efforts associated with Modern Uploader, I'm going for a quick and dirty (but effective) solution - simply provide access to the qq object via CommonJS, AMD, or the window. I will begin working on this at once. Once complete, I hope to release this as 5.8.0.

[rnicholus]

I expect to release 5.8.0 next week with AMD/CommonJS support unless I hear form anyone with requests for implementation changes. Once 5.8.0 is released and AMD/CommonJS support is in place, it will not be changed in any breaking fashion in subsequent releases. So, please let me know if anything is missing.

[rnicholus]

Closing - please follow #1562 for updates regarding support of CommonJS in Fine Uploader 5.8.0.