cujojs/curl — pull request #164 by dvdotsenko (2013-02-01 10:27:00+00:00)
Title: Treat plain JS as undefined-returning AMD modules and don't be grouchy

Example:

require(['plain/js/file'], function(){})

as an alternative to

require(['js!plain/js/file.js'], function(){})

From practical stand point, there is no difference between an AMD module with the following define:

define(function(){return undefined})

and a plain JS file loaded over "js!plain/jsfile.js"

Both effectively load only once, are cached and return `undefined`

However, CurlJS complains about plain JS files loaded using regular module ID references `require(['path/to/plain/jsfile'],function(){/*do something*/})` with "define() missing" error message.

There is a good argument for allowing treatment of plain JS files as if they were undefined-returning AMD modules:

- because of lack of AMD spec on the subject, resolution of paths handled by plugins is up to the plugin writers. This means the resolution / normalization rules may fall outside of formalized translation through 'paths' and 'maps' Indeed, RequireJS is screwed up in that regard, where "[js!]path/to/plain/file.js" is not subjected to 'paths' substitution. Because plugin resources path resolution is a Wild West, it became a compatibility issue in at least my projects, that are sensitive to AMD loader differences.
If an reference looks like a module ID it's subjected to more predictable and formalized path resolution rules.

- I see absolutely no practical difference between a plain JS file and an AMD module with `define(function(){return undefined})` Since there is no significant difference between the two, why produce superfluous errors in case of plain JS?

- RequireJS treats plain JS files loaded through regular-looking module ID pattern exactly as if it is an AMD module and does exactly what is proposed here - yields `undefined` There, the "module" is benefiting from full path normalization. Just for the sake of compatibility, and lacking a negative side-effect, why not do the same.

- Allowing plain JS loading over regular module-ID-like reference does not preclude use of "js!" plugin when appropriate. While there is an argument for use of "order" and "exports", users who need to use them can continue to use them.

- New users will bug you less when all of their JavaScript AMD and plain will just start loading without superfluous errors.

- What's the negative?