Proposal:
- Auto-define a module if dev includes a ".js" extension (inject a noop factory: function () {})
- Fail if the dev used a ".js" extension with modules (define()s found in file)
- Fail if the dev forgot the ".js" ext on a non-module file
Pros:
- Allows use of run.js as a non-module
- Allows simple inclusion of non-modules without the js! plugin
- The js! plugin and the shim config could still be used for non-modules with dependencies
Cons:
- Newb confusion? Will noobs start thinking they can specify ".js" at the end of the module id?
- Will this prolong support for non-modules?
- Will folks think it will behave like RequireJS? (it won't because curl will use the paths mappings)
The run.js benefit is nice, imho. Personally, I think it's pretty cool that run.js can be a module, but I think forcing that may be confusing for some people, especially if they have seen or used RequireJS's
data-main
.That said, I'm pretty strongly against anything that will prolong non-modules, and anything that will make already-prevalent path vs. module id confusion worse. I dunno if this would make those things worse or not. Maybe it depends on how we document it, and on the examples we will provide.
On a slightly related note: It could also be confusing that people would need to call the
curl()
global, and not the localrequire()
inside the run.js module. And we've been saying that using thecurl()
global inside a module is somewhat of an anti-pattern. I wonder if allowing run.js to be a non-module would help people be less confused here.