A few more thoughts, perhaps jumping the gun a bit. Seems possible we may want to support a variety of "JS module" types, including:
* standalone js files that you just <script src=> into your .html (not really "modules") * AMD-authored .js files * CommonJS-authored .js files * npm-styled packages of .js code See the problem. Many types of files, all ending in .js. If we want to have automated processes work against this stuff, for builds, we're going to need one of: * project-specific build scripts with hardcoded directory / file names * utilities to sniff .js files and tell us what kind they are, so tooling can operate against them correctly * configuration files that tell us what kind of files live where * convention that tells us what kind of files live where Some of this is kinda easy. It's easy to recognize npm-styled packages, because they live in directories named "node_modules". But how do I tell an AMD authored .js file from a CommonJS authored .js file (assuming the CommonJS file doesn't live in an npm package)? How do I tell either of those apart from a plain old .js file I just want to include in my .html file? I have no answers, only questions. But I do have a preference of convention over configuration, and sniffer utilities are too fragile for me. -- Patrick Mueller http://muellerware.org
