syntax-error

syntax-error copied to clipboard

> require('syntax-error')('return')
undefined

I don't see an issue here.

C:\Users\Michael\Github\JS_Source>echo return>return.js

C:\Users\Michael\Github\JS_Source>node return.js

C:\Users\Michael\Github\JS_Source>

Seems ok on the browser too: https://jsfiddle.net/a32b1nas/1/

1. node is wrapping your code in an IIFE, which breaks many things. See https://github.com/nodejs/node-v0.x-archive/issues/6254
2. JSFiddle is wrapping your code in a function as well:

<script type="text/javascript">//<![CDATA[
window.onload=function(){
console.log('here goes')
return
console.log('you will not see this')
}//]]> 
</script>

The JSfiddle was a bad example, sorry.

---

I still think this issue is invalid. This module is looking for a syntax error in a code string. This code string should not be presumed to be in the top-level context.

If I gave this string...

helloWorld()
return arguments[2]

...to this module, I would not expect to be given an error, even though in this code string helloWorld and arguments are undefined. Those would be runtime errors, not syntax errors. There is nothing syntactically incorrect in that code string.

Does that make sense?

Take a look at the ECMAScript grammar. Trust me, top level returns are a syntax error, not a runtime error.

Yeah, but my argument is that the provided code string should not be assumed to be top-level. The code string could hypothetically be part of a function.

@ArtskydJ I think it depends on use case. For browserify (and my own app devtool) the assumption is the source is not top-level (wrapped in Node's closure).

Perhaps it could be configurable in a third opts parameter.

EDIT: Updated wording.

@mattdesl That's true. Since a return statement is a SyntaxError in some cases, ideally it should be configurable.

Just like the code string shouldn't be assumed to be top-level, it shouldn't be assumed to be non-top-level either.