Global return statements fail

[watson]

If I read #148 correctly, this should already be fixed and on npm, but given the following code in the file foo.js it fails anyway:

var n = Math.random()
if (n > 0.5) return console.log('You won the lottery!')
console.log('No luck - try again')

Standard will fail with the error "Illegal return statement":

$ standard --version
4.3.1
$ standard
standard: Use JavaScript Standard Style (https://github.com/feross/standard)
  /tmp/foo.js:2:20: Illegal return statement

So, help me out here :) What's going on?

[feross]

eslint (what standard uses under the hood for error checking) doesn't both support ES6 module syntax and global return statements at the same time. It's super annoying. We added module syntax support somewhere in the v3 series and lost global return support then. Right now, we've opted to support the module syntax instead of global return, as you can see in #148.

But, since we now have support for custom js parsers now, perhaps we can remove module support and add back global return support. Users can get module support by using the esprima-fb or babel-eslint custom parsers.

What do folks think?

[dcousens]

Users can get module support by using the esprima-fb or babel-eslint custom parsers.

vs

No configuration. The easiest way to enforce consistent style in your project. Just drop it in.

and

No decisions to make. No .eslintrc, .jshintrc, or .jscsrc files to manage. It just works.

I'm undecided.

[watson]

Just to clarify my use case: Some of my modules (like git-att referenced in this PR) ships with command line scripts (bin in package.json) and here it's really convenient to use global returns to abort under certain circumstances.

[feross]

@watson Understood - I like to do that in my code too. Here's a workaround, if you're interested in one:

if (argv.version || argv.v) {
  version()
  process.exit(0)
}

[feross]

@dcousens Yeah, I get what you're saying. Maybe we should just make standard use babel-eslint for broader ES6 and ES7 support? I wonder if that parser supports global return...

[dcousens]

That could be worth looking into.

Out of interest, would the desired behaviour with ES6 modules be that if an export is detected, global return should give an error?

[watson]

@feross Yeah, I usually also do that - but when calling an async function it doesn't help: https://github.com/watson/tweetcat/blob/4b287496b4a2d6dbcc22c495d1e071a9366242f3/bin.js#L25

[feross]

Using babel-eslint won't solve the problem. babel doesn't support top-level return either.

babel/babel#1298

[feross]

I think this issue is unlikely to be fixed since global returns aren't valid ecmascript (which is silly). The various teams that work on the parsers are unwilling to add a special rule for invalid ecmascript.

Unless anyone can think of something clever, I'm going to close this issue as WONTFIX.

[dcousens]

I'm thinking WONTFIX is suitable. To clarify, the final position is that any globalReturn shall be invalid, ES5 or not?

[feross]

@dcousens That's correct. standard doesn't distinguish between ES5 or ES6 right now so there's no easy way to allow it for just ES5.