ES6 compatibility

[131]

Async just move to ES6, and use lodash for tooling (since lodash provide ES6 compatibility). All our projects are moving to ES6 either. Is mout willing to evolve to this ?
Any draft/plans here ?

I can help !

[millermedeiros]

@131 can you elaborate better your expectations? any special thing about ES6 that you would want us to support? is it just the module format or new features like Map/Set/etc?

[131]

Well, it all start from "lodash did that, maybe mout should". Now that i think about it, i do not see much gain in it. (insert thinking/perplexed smiley here). Maybe you can just brand mout as ALREADY ES6 COMPATIBLE (& hashtag & buzzword & so ) !

[roboshoes]

I'd like to open that issue. I think mout should in the future move to a ES6 import / export. Currently you can keep the file size pretty low by using this syntax"

var clamp = require( "mout/math/clamp" );

However, I believe going forward it would be nice to do things like:

import { clamp, map } from "mout/math";

In order to keep file size low and enable tree shaking we would need to implement ES6 export in files generated by the npm publishing scripts files.

Ideally we could even go as far as:

import { clamp } from "mout";

but that will cause several collisions of module names in different namespaces.

However, porting this should probably be another major release, as it's definitely breaking some code. Also makes me think if it should be changed to use at least commonJS as the default and slowly move away from AMD. I don't have any stats on how much of it gets used with requireJS these days, but my assumption would be very little.

[niksy]

What is the status of this issue? Will this be considered as standard consuming format? I don’t think it should be major problem converting this from (generated CommonJS) to ESM. There are also tools which can help with that. Would the maintainers consider implementing this and accepting help from community with this? I would also like to help with this!

[roboshoes]

I'm actually very interested in this. I would potentially even go one step further and would love to add type information to this. I think we could potentially port this to TypeScript. with the advantage that we can generate the ES level that we are comfortable with. I considered simply writing types for it, but we might as well make it the real thing.

[niksy]

Maybe go step by step? Setup new infrastructure around tooling, building, publishing and testing, implementing ESM as standard, and then adding types (maybe through community driven effort)?

[roboshoes]

Right. We could add type information in separate files, but since we would add them to this repo anyway it seems like a round about way for me to maintain them.

The reason I suggested to go right to converting it to typescript is that we could skip the process of simply updating the import statement. Typescript compilation would then allow us to generate either level of ES5 or ES6 or ESnext and so forth.

I don't want to push this too hard, but if there is a chance that we end up converting them AND write type files, I'd strongly vote against it as it seems unnecessarily doubling the work.

That being said, if you want to "just" make a PR that converts the import to newer standards to news ones, I'm more than open to it. We have an elaborate test suite. This would go into a new major version, dropping AMD support or rather point users to 1.x version for AMD and 2.x for ES6 and higher.

[niksy]

I’ve started with the initial conversion in #264!