[Help] SyntaxError: Illegal return statement

This error is coming up for a script that I submitted that worked and works from the API script entry and console - 
It came up for another script I tried there as well ... 

There are no return statements outside of functions, and I can't seem to figure out what is triggering this - it means Teleport 1.2.2 is not working currently, and this causes a problem for me if I can't validate scripts will work before I submit - or if they work in one case, but may fail when put into one-click. 

Edit: no version of the script works anymore - all throw the " SyntaxError: Illegal return statement"

It's unlikely anyone will be able to diagnose the problem without the scrpt code, or a direct link to the code.

One thing you should try though: create a fresh campaign, and install only that script and no other, and see if it works.

In case it ends up being relevant to the API install of scripts in general, Roll Handout Tables has also been broken for one-click install since it was last pulled yet functions properly if imported or copy-pasted to the console.

Illegal return statement happens when you have a return outside the scope of a function, at the global scope.  It's very likely that you have an extra } somewhere above one of your return statements, something like:

function foo() {
  if( bar ) {
    return baz;
  }} // <- like this
  return qux;
}

The Aaron said:

Illegal return statement happens when you have a return outside the scope of a function, at the global scope.  It's very likely that you have an extra } somewhere above one of your return statements, something like:

function foo() {
  if( bar ) {
    return baz;
  }} // <- like this
  return qux;
}

If you throw your code in the Google Closure Compiler, it should find the issue for you pretty quickly.  If you aren't editing your script in an editor set up for programming, you should probably look into doing that.  Brace matching, syntax highlighting and built in linting can really help with syntax errors like this.

Here's the thing - the code works in some instances and doesn't in others - specifically, some of this is code that is already up on one-click, and if I enable a local script and a one-click, things break this way - if I disable some of them selectively, it doesn't... (edited to add) - and it isn't consistent (which scripts are disabled changes, and there is no pattern to which one needs to be disabled and might be considered "the problem")
...and I had this crashing happening a lot earlier this week with a script that was of this pattern: 

var foo = foo||(function(){
   var bar = function(){}
    return {bar:bar}
})();

Edited again to add: I'm wondering if it's in the process that stuffs all the scripts together - something about how I write my scripts, it doesn't like. Something in how I write out the closures in the scripts in series is throwing the jam-everything-together script off when there's more than one. 

Ah.  It's definitely the concatenation problem.   The API concatenates all scripts together into a single script and that is what gets executed by the API Sandbox.  It concatenates them directly, with no separators of any kind, so various problems can happen, for example:

function scriptA() = {
  // do stuff
}
scriptA()

and

function scriptB() = {
  // do stuff
  return bar;
}
scriptB()

would become:

function scriptA() = {
  // do stuff
}
scriptA() function scriptB() = {
  // do stuff
  return bar;
}
scriptB()

giving you an unexpected token error.

If the previous script ends in a comment:

function scriptA() = {
  // do stuff
}
scriptA()
// finished

That could easily cause an unexpected return:

function scriptA() = {
  // do stuff
}
scriptA()
// finished function scriptB() = {
  // do stuff
  return bar;
}
scriptB()

That's one reason I always start my scripts with a comment block.

The Aaron said:

Ah.  It's definitely the concatenation problem.   The API concatenates all scripts together into a single script and that is what gets executed by the API Sandbox.  It concatenates them directly, with no separators of any kind, so various problems can happen, for example:

function scriptA() = {
  // do stuff
}
scriptA()

and

function scriptB() = {
  // do stuff
  return bar;
}
scriptB()

would become:

function scriptA() = {
  // do stuff
}
scriptA() function scriptB() = {
  // do stuff
  return bar;
}
scriptB()

giving you an unexpected token error.

If the previous script ends in a comment:

function scriptA() = {
  // do stuff
}
scriptA()
// finished

That could easily cause an unexpected return:

function scriptA() = {
  // do stuff
}
scriptA()
// finished function scriptB() = {
  // do stuff
  return bar;
}
scriptB()

That's one reason I always start my scripts with a comment block.

Okay, that's it, then - I have some cleanup to do for several of my in-progress scripts (comment blocks) before I can move them to one-click in that case. I threw a try-catch around the entire script and that had a similar effect, so yes - my in-progress scripts are not concatenation-friendly currently. 

That's one reason I always start my scripts with a comment block.

Very good to know, thanks!

Some stuff like that is probably so tribal knowledge-y as to be forgotten by habit.  I don't even think about that decision until something like this comes up.  It should probably be documented in the wiki somewhere.  Maybe a wandering Andreas J. will pick it up and drop it there... =D

A similar bit of tribal knowledge is that it's better to write HTML entities in code separated:

let foo = "bar &#13; baz";  // <- bad
let foo = "bar &"+"#13; baz"; // <- less bad

As some browsers when you copy/paste code into the API will expand those HTML entities into what they really are and break things subtly.

The Aaron said:

Some stuff like that is probably so tribal knowledge-y as to be forgotten by habit.  I don't even think about that decision until something like this comes up.  It should probably be documented in the wiki somewhere.  Maybe a wandering Andreas J. will pick it up and drop it there... =D

A similar bit of tribal knowledge is that it's better to write HTML entities in code separated:

let foo = "bar &#13; baz";  // <- bad
let foo = "bar &"+"#13; baz"; // <- less bad

As some browsers when you copy/paste code into the API will expand those HTML entities into what they really are and break things subtly.

Thanks again! You'd think I'd know about concatenation issues considering I once wrote a concatenation script to pull all of the included JS on the back end. 

The Aaron said:

Some stuff like that is probably so tribal knowledge-y as to be forgotten by habit.  I don't even think about that decision until something like this comes up.  It should probably be documented in the wiki somewhere.  Maybe a wandering Andreas J. will pick it up and drop it there... =D

A similar bit of tribal knowledge is that it's better to write HTML entities in code separated:

let foo = "bar &#13; baz";  // <- bad
let foo = "bar &"+"#13; baz"; // <- less bad

As some browsers when you copy/paste code into the API will expand those HTML entities into what they really are and break things subtly.

That's interesting. I think I have run into that problem once and never understood what was happening.

Jordan C. said:

That's one reason I always start my scripts with a comment block.

Very good to know, thanks!

Where's the upvote button?

Oosh said:

Where's the upvote button?

I found it, it's right here: