Switch to MJS extension

[IvanGoncharov]

Suggested by @Andarist in #1366
Based on: leebyron/iterall#34

@mjmahone I think it's the right moment for this change since there no active PRs from 3rd-party contributors.
Note: It doesn't break Git history since files were moved using git mv.

[IvanGoncharov]

Looks like coverage is broken 😞

[mjmahone]

I'm sorry, I don't understand the point of this (I am not very up to date on the latest happenings in JS). Why do we want to use .mjs instead of .js? That seems like it will break a lot of third-party tools (like syntax highlighting and other issues).

leebyron/iterall#34 seemed to be to allow in-line flow definitions. But we already have that for this repo, so I'm not sure what's gained here.

[Andarist]

Just to clarify - I was by no means suggesting a switch to MJS. Personally I dislike it 😉

My PR was solely about replacing custom bash script with a little tool that I've made for another project.

But I think it's better to follow the rest of JS ecosystem and switch *.mjs files.

I'm not sure if rest of JS ecosystem is really going that way, from major tools only webpack has embraced it thus far as first class citizen (as far as I know).

I agree with @mjmahone that it might break a lot of other tooling and personally I would advise against it at this point in time.

[IvanGoncharov]

I'm not sure if rest of JS ecosystem is really going that way, from major tools only webpack has embraced it thus far as first class citizen (as far as I know).

The main idea here is that node.js support it natively so you don't need to use babel anymore 🎉
If your file extension is mjs node enables native support for modules so you can use import/export syntax without transpiling. Same goes for browsers: https://caniuse.com/#feat=es6-module

So ecosystem definitely moving toward native ES modules and mjs is similar to "use strict" but for module support.

Moreover, after we drop support for node 6 on April 2019 (last version without mjs support) we can drop stop shipping js inside NPM package and fully switch to mjs. Plus when we finally drop IE support(maybe 2020 or earlier?) we can remove babel completely.

leebyron/iterall#34 seemed to be to allow in-line flow definitions. But we already have that for this repo, so I'm not sure what's gained here.

Since node support almost all ES6 features and import/export (in mjs files) it allowed doing local development (test, coverage, ...) without babel.
Inlining is Flow definition was the last step toward having this library node compliant.

But on a closer look I see a few differences between this lib and iterall:

• iterall doesn't use ES6 so it can drop babel for mjs and just copy it into NPM package
• graphql-js is Flow heavy so I don't think inline Flow is a good solution. We can use flow-node for local development: https://github.com/flowtype/flow-remove-types#use-flow-node but it's still not ideal.
• We need to support node 6 for local development until April 2019
• In our case coverage is not working for some reason

I agree with @mjmahone that it might break a lot of other tooling and personally I would advise against it at this point in time.

I agree it's too early. I looked at iterall and got carried away 😊
I closing this PR but I think we need to make the second attempt closer to April 2019

[IvanGoncharov]

Looks like node 8 hides this feature under --experimental-modules but node 10 works without it.
So we need to target node 8 depreciation on December 31, 2019
BTW. I found a good article on a topic: https://medium.com/@giltayar/native-es-modules-in-nodejs-status-and-future-directions-part-i-ee5ea3001f71