Determine ecmaVersion 'automagically'

[matAtWork]

Running some test scripts against a bunch of random JS files, I have an issue with not knowing which were written for ES5 and which for ES6, which clearly an ES6 capable engine (browser, node) somehow works out, otherwise some valid ES5 constructs (such as octals beginning with 0) fail as ES6 is strict by default, and obviously ES6 constructs fail with ecmaVersion: 5.

Is there a way to determine which version a script will 'correctly' parse as in a 'typical' engine without having to try ES5, letting it fail and then try 'ES6'? Or, put more usefully, is there a preferred or recommended way, and if not, should there be an additional option/function to work it out in the preferred/recommended way?

[marijnh]

ES6 is backwards compatible, so if you're not sure, just parse in ES6 mode.

[matAtWork]

Of course. What I'm actually observing is that if I parse with sourceType set to 'module', to enable keywords like 'import' in ES6, it fails on parsing un-strict ES5 scripts destined for a browser. Obviously in the real world, this is unlikely (a file will typically execute in one environment or the other), however my test is dumb and just tries every .js file I have locally. Since no ES5 files can be 'modules', I guess I'll just have to try in ES6 mode in both sourceTypes.

Perhaps I should rename the issue "Determine sourceType 'automagically'"

[RReverser]

I guess I'll just have to try in ES6 mode in both sourceTypes

No, that's a wrong way. If you work with ES5, just use "script". Modules and scripts are different kinds of code in ES6, and you can't just choose whichever parses, because in runtime they behave differently, too (in particular, different strict mode behavior).

[matAtWork]

This is pretty poor use-case I have - I'm testing my (estree) output routines by parsing (using acorn), outputting and re-parsing and making sure the trees are the same. To catch as many things as I can, I'm running it on my local tree (approx 75k .js files), but of course some are meant for browsers (sourceType: script) and some for nodejs (sourceType: module). Not being my files, I don't know which is which - they're just input for my test. This isn't a realistic scenario for any executing code - I'm just using it to validate my own code, so trying both sourceTypes and making sure that anything that parses generates output that re-parses as the same is fine. If neither modes parse, it's not valid JS and I don't need to worry as I won't have to transform or output it

[RReverser]

some for nodejs (sourceType: module)

No, the fact that they're for Node.js doesn't affect sourceType. Node.js modules don't have the same meaning as "module code" in ES6, they're just regular ES5/ES6 script code.

[marijnh]

So yeah, this does not exist, but trying one sourceType after the other and seeing what doesn't raise an error does actually sound like a good workaround in your case.

[RReverser]

If it's just for determining whether it's possibly a valid code - yes, but for comparing trees one needs to make sure to set same sourceType in both parsers.

[matAtWork]

Hmm, I'm probably making myself look more stupid that necessary by equating browser='script', node='module'. Perhaps I should be more accurate - I have some sample JS files that are clearly meant to be 'modules' (they contain import and export statements). Since they have the same extension, etc., I can't tell what I should set sourceType to in order to get them to parse.

[matAtWork]

Oops - crossed messages. @RReverser, yes this is a test case. And I can assume if it parses at all I can use the same mode when comparing trees, so as @marijnh suggested, I'll try one then the other.

I appreciate your help - I understand the separation of the two source types much better now

[RReverser]

Btw, I guess if you don't care about a specific case of import/export somewhere deeply in the tree, you can just set allowImportExportEverywhere to true.

[matAtWork]

Erm, yeah. I have no idea why I didn't spot that. Problem solved. Thx :)

[RReverser]

However... no, that won't solve your case as many other things will fail in strict (module) code while parsing well as scripts.

[matAtWork]

At least I've got options now (at least two) - I'll try it out and hopefully make progress. Thanks again