ES6 support?

[IngwiePhoenix]

Although I see the keywords inside the src/esprima.js file, I have this:

Ingwie@Ingwies-Macbook-Pro.local ~/W/test $ cat test.oj 
var foo = "bar";

export default foo;
Ingwie@Ingwies-Macbook-Pro.local ~/W/test $ ojc test.oj -o out.js
test.oj:3:1 Unexpected reserved word

Might want to look into this?

[iccir]

I think this is a duplicate of #38. It looks like import/export was added in Esprima 2.2 (See https://github.com/jquery/esprima/issues/1099)

[IngwiePhoenix]

Oh! :o When will you be updating to 2.2 then? As I see it, you currently are running a modified version of Esprima (src/esprima.js)...so updating, means merging your modifications in, if I am not mistaken...

[IngwiePhoenix]

O.o

> require("ojc/src/esprima").version
'1.2.2-oj'

I thought you updated to 2.0?

[iccir]

Just updated #38. Sorry, my comment in that issue was suppose to indicate that Esprima 2.0 was available, and the issue was unblocked, rather than indicating that I had adopted it.

[IngwiePhoenix]

I see. Do you have any idea when you can migrate to Esprima 2.x?

[iccir]

It's definitely on my list, but I'm a bit swamped at the moment. Hopefully later this year.

[IngwiePhoenix]

Okay! :) Maybe I’ll learn how to properly patch esprima to support OJ and can PR that stuff…maybemaybe. Good luck with the stuff you are tasked with! :) For now I’ll just have to substitute using ES6 features inside OJ.

[IngwiePhoenix]

Hey. Whats the status on this to-do currently? o.o

[iccir]

Still swamped, hopefully later this year after iOS 9 and El Capitan ship.

[iccir]

Duplicate of #38

[iccir]

I think this is resolved via 1.2. Ingwie, please re-open if you disagree.

[IngwiePhoenix]

Well, it seems that this basic example already breaks:

Ingwie@Ingwies-Macbook-Pro.local ~/W/oj-tests $ cat e.oj
import fs from "fs";

@implementation Reader {
    var fh;
}
+(id)initWithFile:(string)fileName {
    fh = fs.open(fileName, "r");
}
@end
Ingwie@Ingwies-Macbook-Pro.local ~/W/oj-tests $ ojc e.oj
e.oj:1:1 Unexpected token

I'll do more testing, but this is rather surprising to me.

[IngwiePhoenix]

I tried to use esparse on a similar file, and i got the same error. Nevermind, it seems to be an Esprima thing. I am looking into this now. :)

[IngwiePhoenix]

http://esprima.org/demo/parse.html?code=import%20foo%20from%20%22bar%22%3B This works as expected, but neither esparse nor ojc --dump-ast get it right. Both get to the same error.

[IngwiePhoenix]

Oh. So, that is...a thing. https://github.com/jquery/esprima/issues/1273

[iccir]

Let me read up!

[IngwiePhoenix]

Haha, sorry for the bombardement :)

It turns out that - pretty sneakily hidden in the docs though... - there are two types of "things" that can be parsed;

• script and
• module

There is not a lot said about it - except that it seems that import and export only work, when module is selected as the option.

esprima.parse(Source, {sourceType: "module"})

Thats all I was able to find out.

[iccir]

ES6 defines the concept of a "script" vs. a "module". import/export is only available for modules, and there are additional restrictions (await is a reserved word).

Modules are defined in the language spec, but usage in real life is distant. They aren't supported by node or any browsers yet, although Babel and Rollup can transpile module syntax.

Going forward, there needs to be a flag which passes import/export/await through the compiler, and then you can use an oj2 on-compile hook to have Babel/Rollup transpile. oj2 may also need the ability to output multiple source files rather than a concatenated single file (the concatenation may need to occur at a later stage, by another transpiler).

[IngwiePhoenix]

Oh, I see. So by default, esprima will read the input as a script instead of a module.

Do you think you can introduce an option to oj1.2 to allow it to parse modules instead? Something like input-format=[script|module] or enable-module?

As I am using WebPack, I already am only transpiling file by file and can have these post-processed by Babel. In fact, that was my intention.

[iccir]

I don't want to add an option on a whim without thinking it over a bit. But for now, can you change line 73 of compiler.js to:

var parserOptions   = { loc: true, sourceType: 'module' }

[IngwiePhoenix]

Looks like that that is what I will have to do in a local fork.

Well I guess i'll wait for a more cleaner solution though! :)

[adius]

This is almost 2 years old and it's still not supported by the cli 🙈

[iccir]

Thanks @adius! I forgot to update this bug when I landed support.

parser-source-type was added in #84 and should work, I just tested with:

test.oj:

import fs from "fs";

@implementation Reader {
    String fh;
}

+(id)initWithFile:(string)fileName {
    fh = fs.open(fileName, "r");
}
@end

ojc --parser-source-type=module test.oj

[iccir]

I believe everything mentioned in this bug has been resolved by some combination of #38, #84, or other oj 2.x features. This should have likely been closed back in 2015, but I goofed! Closing now, please let me know if I've missed something!