Try writing some code using ES6

[tofumatt]

It might be nice to experiment with some ES6 goodness in localForage. And with #157, we can nicely transform it to ES5 for distribution.

[tofumatt]

This might also allow us to close #114.

[thgreasi]

Do you have any specific transpiler in mind to recommend?
I would go with traceur for start, since it has been tested well enough by the angular community.

Should we also emit an es5 folder in the dist directory (or somewhere else)? Should the es5 files be included in the bower package?

[stephanebachelier]

There is also babeljs which was previously 6to5.

[thgreasi]

After some comparison of babel and traceur I spotted some differences.

I think babel is using object property definition. Is this es3 polyfillable?

[stephanebachelier]

@thgreasi for older browser you must use the es5-shim and the babel polyfill.

There is a section at the end of babel caveats page

By default, when using modules with babel a non-enumerable __esModule property is exported. This is done through the use of Object.defineProperty which is unsupported in IE8 and below. A workaround for this is to enable loose mode - modules.

[thgreasi]

@stephanebachelier 👍 it look like that loose mode produces cleaner code without the need of Object.defineProperty.

[thgreasi]

Just created a branch to test babel.
All the tests pass and the generated code is as readable are the original non es6.
The most annoying thing was jshint and jscs on es6 code.
Also, the component build does not like es6 so I had to keep a separate es5src.

As side notes:

• Didn't test it on IE8 (maybe next week)
• It places a global "use strict" statement and a global _classCallCheck object.
  • Maybe I should wrap all the generated code in an IIFE.

[tofumatt]

So far that looks good, I like being able to use the class for LocalForage 👍

I'm moving right now (Canada to the UK!) so I can't code/test much stuff but happy to review things later, whenever you can get to them 👍

[jamiebuilds]

Hi I'm a Babel contributor. @thgreasi if you want to leave out the "use strict" you can blacklist it. If you want to see an excellent example of how to write a library with Babel check this out: https://github.com/babel/babel-library-boilerplate.

If you need any other help let me know or ask in our support chat: https://gitter.im/babel/babel

[thgreasi]

Thanks @thejameskyle 👍
Atm I'm looking at custom module formatters.
UMD looks very similar to what we currently do to fetch driver modules, except that we also look at the global object as well.

[jamiebuilds]

We're looking to improve that in the future, right now if you need a global in the UMD you can use esperanto like the boilerplate does.

[thgreasi]

Thanks, I will take a look at it asap.

[thgreasi]

@thejameskyle We do import some files programmatically and so I was
thinking about writing a Transformer to change expressions like:

System.import('aDriver')

Into something like Esperanto/UMD+Globals.

Does this actually make any sense?

On Sun, Apr 19, 2015, 09:48 James Kyle notifications@github.com wrote:

We're looking to improve that in the future, right now if you need a
global in the UMD you can use esperanto http://esperantojs.org like the
boilerplate does.

—
Reply to this email directly or view it on GitHub
#158 (comment).

[RangerMauve]

System.import is apparently the future since it's being officially standardized. I'd give a -1 to moving away from that.

[thgreasi]

I thought it got removed in the April's es6 draft!?!?!?
(As you can see the #sec-loader-objects is missing from the current page, as well as any System.import reference.)

[RangerMauve]

Huh, good point. I hadn't heard about that yet.

[jamiebuilds]

I don't know how you'd dynamically load something in a UMD. You could certainly do it if you were using a module loader like system.js.

[megawac]

UMD supports AMD which is all about dynamic loading no?

[jamiebuilds]

Yeah but the point of the UMD is to work in all environments (AMD, Common.js, Globals).

[thgreasi]

The current UMD formatter does a great job in creating modules that can be imported using any/many different module systems.
However it does not specify a way on how your code should be written when it needs to import sub-modules

LocalForage tries to dynamically load the drivers and the common Serializer, by guessing the available module system available. It currently supports global and commonjs/browserify imports as well as async loading with AMD/requirejs. That's so that the user can benefit the most of his module loader of choice, no matter what he is using (RequireJS/Browserify/GlobalNamespace).

I was discussing about creating a Transformer (if there isn't one already) that would allow to programmatically import UMD modules no matter what the module loading scheme is used at runtime.

I would expect that such a Transformer would change expressions like:

System.import('aDriver').then(...);

To something like:

new Promise(function(resolve, reject)){
    if (System && typeof System.import === "function") {
        System.import('aDriver', resolve);
    } else if (typeof define === "function" && define.amd) {
        require(['aDriver'], resolve);
    } else if (typeof exports !== "undefined") {
        resolve(require('aDriver'));
    } else {
        resolve(globalObject['aDriver']);
    }
}).then(...);

I guess I should probably move this discussion to the babel repo...

PS: I chose System.import as the default way to programmatically import a module, because it looks like it's the the most promising to become a standard (at some point in the future).