how is javascript version configured for server side global scope scripts?

[Dave Oshinsky]

I have a Utah PDI where I'm writing both "Fix Scripts" and Scripted REST API logic with global scope. The version of Javascript that's running appears to be really archaic - no support for "class" or "let".

I see here that the Javascript version is configurable, but I don't see anywhere so far explaining how to change it:

https://docs.servicenow.com/en-US/bundle/utah-application-development/page/script/JavaScript-engine-...

It seems that the default global scope Javascript in my Utah PDI is the ancient "compatibility" mode, based on no support for newer features like "class" or "let" (instead of "var").

Assuming I figure out how to change the setting to a more modern Javascript, the next question would be:

what happens when one of my scripts is deployed to another instance (perhaps non-Utah, perhaps non-PDI)?  Will the Javascript version setting have to be manually changed there (if I use more modern features like "class" and "let")?

[Dave Oshinsky]

@OlaNmy application needs to automate import of data into ServiceNow tables. Most of the logic will run client-side in Java. For now, I'm focusing on Import Set REST API, which seems closest. However, it's really not designed to run from a program (!!??), as there are prerequisites like the Staging Table that must be created first. In addition, it's complicated because it needs to run synchronously (the default is asynchronous), and the Transform Map needs to be setup beforehand.  I have found no REST API to create any kind of table, not to mention a Staging Table, which must extend sys_import_set_row, as well as have fields compatible with the exported JSON to be imported. Lots of fun for a ServiceNow newbee, plus I've managed to mostly avoid Javascript before now.  No more avoiding Javascript for me!  Even the more recent versions seem primitive compared to current C++, Java, and C#.  But ES5. Wow!

[OlaN]

Okay, thanks for the explanation.

I would advice that you create the data structure (tables, and fields) on beforehand in ServiceNow, and after that is done, you can easily build REST calls to create/update etc records on that table.

If you need any help with the REST part, there is a good series to watch on YouTube, and for additional ServiceNow questions, there are plenty people willing to help you here on the Community.

Best of luck!

[Dave Oshinsky]

Performing steps manually (at least some of them) seems to be part of the culture with ServiceNow. However, my employer's customers prefer to have as much of this automated as is possible. With ServiceNow, there are some challenges doing this. Thanks for the advice, @OlaN 

[John Dahl]

To add insult to injury, ServiceNow has polyfilled some newer capabilities into the platform, so some ES6 features will work in global scope. Here is an article that lists the different versions with references to describe what features were added to each. If you have any questions about a feature, this will help you understand if you should expect it to work or not.

https://www.w3schools.com/Js/js_versions.asp

[MatthewPinheiro]

Something's wrong though--the documentation you linked to says the exact opposite.  It says "ES5 Standards mode is the default mode for global applications"... but I'm definitely seeing Compatibility mode behavior when I run in global. 

For example, if you run the following code:

gs.foobar(); // This function does NOT exist

In a scoped application set to ES5 Standards mode, this throws an error. But in global, it doesn't throw at all and acts like everything's fine! That's definitely Compatibility mode behavior, right? So is the documentation just wrong?