should curl.js support non-modules natively?

curl+plain-js.md

Q: should curl.js support non-modules natively?

from original Pull Request

Proposal:

code is here

• 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)

nice side-benefit: moving from two-script curl/run setup to a single script setup does not require changing run.js:

from this:

<script src="curl.js"></script>
<script src="run.js"></script>

to this:

<script data-curl-run="run.js" src="curl.js"></script>

You can't (currently) do the first example when run.js is a module. We could likely find another way to make this work, though.

another way to make it work: ensure run.js is a named module

define('run', ['curl'], function (curl) { ... });

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 local require() inside the run.js module. And we've been saying that using the curl() 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.

agree about the curl global. that's why i like this:

define('run', ['curl'], function (curl) { ... });

Interestingly, I think a named module will work in every situation:

1. separate script elements, unbundled / dev
2. separate script elements, bundled / prod
3. one script element, unbundled / dev
4. one script element, bundled / prod