On Thu, Jun 20, 2013 at 9:08 AM, Sam Tobin-Hochstadt <[email protected]> wrote: > On Thu, Jun 20, 2013 at 10:26 AM, Kevin Smith <[email protected]> wrote: >> I wonder, though, if this might create issues for polyfilling: >> >> // polyfillz.js >> if (this.Promise === void 0) >> this.Promise = function() { ... } >> >> // main.js >> import "polyfillz.js"; >> new Promise(); >> >> This would refuse to compile, right? We'd have to introduce all of our >> polyfills in a separate (previous) compilation/execution cycle. > > Yes, like so: > > <script src="polyfillz.js"/> > > Note that this is already the way people suggest using polyfills; see > [1] for an example.
I have found that once I have module loading, I want the dependencies to be specified by the modules that use them, either via the declarative dependency syntax or via module loader APIs, and at the very least, avoid script tags as the optimization tools can work solely by tracing module/JS loading APIs. In this case, only the "model" set of modules would care about setting up indexeddb access, not the top level of the app. Example, this AMD module: https://github.com/jrburke/carmino/blob/master/www/lib/IDB.js Asks for "indexedDB!", which is an AMD loader plugin: https://github.com/jrburke/carmino/blob/master/www/lib/indexedDB.js which feature detects and uses a module loader API to load a shim if it is needed. So the "IDB" module will not execute until that optional shim work is done. I believe this will also work via the ES Module Loader API, but calling it out just in case I missed something. I want to be sure there are options that do not require using <script src> tags, except maybe one to bootstrap a set of Module Loader hooks. James _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
