Differences Between SuiteScript 2.0 and SuiteScript 2.1
SuiteScript 2.1 uses a different runtime engine than SuiteScript 2.0 and supports ECMAScript language features that are not supported in SuiteScript 2.0. This causes some capabilities in SuiteScript 2.0 scripts to function differently when the script is executed using SuiteScript 2.1.
The following describes important differences between SuiteScript 2.0 and SuiteScript 2.1:
-
The N/llm Module and the N/pgp Module are only supported in SuiteScript 2.1. The N/crypto/random Module, when used in server scripts, is also only supported in SuiteScript 2.1.
Reserved Words as Identifiers
In the ECMAScript specification, reserved words are identifiers that have special meaning. For example, the var
reserved word indicates a variable declaration. You cannot use reserved words as variable names, labels, or function names in JavaScript/ECMAScript. Because SuiteScript 2.1 supports a later edition of the ECMAScript specification (ECMAScript 2023) than SuiteScript 2.0 (ECMAScript 5.1), the list of reserved words is different. SuiteScript 2.1 is stricter about not including reserved words in scripts.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You use
|
The script executes and does not generate an error. The |
The script generates a syntax error. The |
To avoid this issue, do not use any reserved words from any edition of ECMAScript (including those planned for future editions using ES.Next). For more information, see SuiteScript Reserved Words.
Error Object Properties
SuiteScript supports the Error object, which is provided by ECMAScript, to represent errors that can occur in scripts. You can call JSON.stringify(obj) on an Error object to obtain a string representation of the error. If you pass an argument to the constructor when you create the Error object, the string representation in SuiteScript 2.0 includes this argument as the value of the message
property. The string representation in SuiteScript 2.1 does not include the message
property.
This difference is because of how JSON.stringify(obj) handles enumerable and non-enumerable properties. In SuiteScript 2.0, the output of JSON.stringify(obj) includes the content of both enumerable and non-enumerable properties. In SuiteScript 2.1, the output of JSON.stringify(obj) includes only the content of enumerable properties and does not include the content of non-enumerable properties, as per the ECMAScript specification.
When you pass an argument to the Error object constructor, a non-enumerable message
property is defined. If you change the value of this property after the Error object is created, the property remains non-enumerable. So, when an Error object is created in this way, the message
property is not included in the JSON.stringify(obj) output in SuiteScript 2.1 scripts.
By contrast, when you do not pass an argument to the Error object constructor, the message
property is not defined. If you try to set the value of this property after the Error object is created, a new message
property is defined. Properties that are defined in this way are always enumerable. So, when an Error object is created in this way, the message
property is included in the JSON.stringify(obj) output in SuiteScript 2.1 scripts.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You use the following code to create an Error object with no argument in a script:
|
The
|
The
|
You use the following code to create an Error object with an argument in a script:
|
The
|
The
|
To avoid this issue, use only enumerable properties for objects. For error messages, create Error objects with no arguments. For more information, see JSON.stringify(obj) and Enumerability and ownership of properties.
Invalid JSON Parsing
SuiteScript can parse JSON strings that you use in your scripts. When invalid JSON is encountered, a syntax error is generated. The type and format of the generated error message is different in SuiteScript 2.1 than in SuiteScript 2.0. Also, including trailing commas in JSON strings is accepted in SuiteScript 2.0 but generates an error in SuiteScript 2.1.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You try to parse the following JSON string in a script:
|
The following error is generated: org.mozilla.javascript.EcmaError: SyntaxError: Unexpected token: b |
The following (or similar) error is generated: SyntaxError: Invalid JSON: <json>:1:0 Expected json literal but found b |
You try to parse the following JSON string in a script:
|
The script executes successfully. |
The following (or similar) error is generated: SyntaxError: Invalid JSON: <json>:1:0 Expected json literal but found , |
To avoid this issue, make sure you use the JSON format that is compatible with the ECMAScript specification. For more information, see JSON object.
Strict Mode
ECMAScript 5 introduced strict mode. If a SuiteScript 2.0 script assigns a value to a variable without first declaring the variable using the var
or const
keyword, the script continues executing and no error is thrown. If a SuiteScript 2.1 script assigns a value to a variable without using the var
, let
, or const
keyword, an error is thrown. For more information about strict mode, see Strict Mode.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You place a portion of your script (or your entire script) into strict mode and assign a value to an undeclared variable:
|
Script execution completes without throwing an error. |
The following error is generated: ReferenceError: x is not defined |
Reassignment of const Variables
JavaScript const
variables create a read-only reference to a value. When a const
variable is assigned a value, the variable identifier cannot be used again (reassigned). In SuiteScript 2.0, no error is thrown when you reassign a const
variable. In SuiteScript 2.1, a TypeError
is thrown.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You set a value for a
|
The script completes execution successfully, however the value of |
The execution stops at the TypeError: Assignment to constant variable |
Behavior of for...each...in Statement
The for...each...in
statement was deprecated as part of ECMA-357 (4x) specifications and should no longer be used. In SuiteScript2.0, the for...each...in
statement is accepted. In SuiteScript 2.1, a SyntaxError
is thrown if you try to use the for...each...in
statement in your script. For more information about the deprecation of for...each...in
, see for..each..in.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You use a
|
The |
The following error is generated: SyntaxError: SyntaxError: <eval>:3:4 Expected ( but found each for each ( var value in obj) { |
Formats for Converting Dates to Local Date Strings
JavaScript supports several date formats and ways to create a date. After you create a date, you can convert it to a local date string. In SuiteScript 2.0, the default format for the converted date string is the long format. In SuiteScript 2.1, the default format for the converted date string is the short format.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You create a date and log two different formats for that date:
|
The default format is the long format, and additional properties passed are ignored. The output is:
|
The default format is the short format, and additional properties passed are ignored. The output is:
|
Conditional Catch Blocks
In JavaScript, a try-catch
statement can include an optional if
statement within the catch
block, however it is not ECMAScript specification compliant. In SuiteScript 2.0, a script that includes a conditional catch
statement executes without error. In SuiteScript 2.1, a SyntaxError
is thrown for any script that includes a conditional catch
statement.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You create a
|
The script completes execution without throwing an error. |
The following error is generated: SyntaxError: SyntaxError: <eval>:2:11 Expected ) but found if } catch (e if e instanceof TypeError) { // Don’t use |
The toSource Method
In JavaScript, the toSource
method is used to return a string representing the source code of the object. However, this feature is obsolete and should not be used. In SuiteScript 2.0, a script that includes the toSource
method for an object executes without error. In SuiteScript 2.1, an error is thrown for any script that includes the toSource
method for an object. For more information about the toSource
method, see toSource.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You try to log a transactions source:
|
The script completes execution without throwing an error. |
An error is thrown indicating |
Set Decimal Number with Trailing Zeros
When you set a decimal number value in JavaScript, behavior depends on the format of the numerical value. In SuiteScript 2.0, if there are trailing zeros in a decimal value you set, the value is set as a double precision floating point number (double). In SuiteScript 2.1, if there are trailing zeros in a decimal value you set, the value is set as an integer value. Note that in both SuiteScript 2.0 and SuiteScript 2.1, a value is always set as a double value if there are no trailing zeros in the decimal value you specify.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You set a decimal value with trailing zeros:
|
|
|
You set a decimal value with no trailing zeros:
|
|
|
String Differences for RESTlet Post Method
In SuiteScript 2.0, a JSON.stringify()
call is added internally to whatever is passed in the post()
method of a RESTlet. This affects the value passed. In SuiteScript 2.1, a JSON.stringify()
call is not added to the post()
method for a RESTlet.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You return JSON.stringify in a post function:
|
Returns "\"flower\"" and a string length of 12. If you specify "flower" in the return statement, "flower" is returned with a string length of 8. |
Returns "flower" and a string length of 8. If you specify "flower" in the return statement, flower is returned with a string length of 6. |
|
The log statements are: xmlRequest.responseText="\"ok\"" xmlRequest.responseText.length=8 |
The log statements are: xmlRequest.responseText="ok" xmlRequest.responseText.length=4 |
RESTlet Return Type Difference
SuiteScript 2.1 changes the way that RESTlet responses are formatted for certain content types. When the Content-Type in the RESTlet header does not match the type that the RESTlet is returning, the results returned may not be what you are expecting.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
You set the Content-Type in a RESTlet header to application/json. For example, see the following sample RESTlet script and sample code for calling the RESTlet.
|
The response is automatically converted to a string and that string is returned instead of an object. In the example scenario, the alert output is a string, SS2.0 gives string; but in SS2.1 it comes as object. |
The return type for JSON will be an object. In the example scenario, the alert output is an object. |
parseInt Difference
The parseInt function operates differently in SuiteScript 2.1 than it did in SuiteScript 2.0, for certain calls to parseInt. To avoid encountering incorrect results because of this difference, follow best practices when using the parstInt function, which can be found at: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt.
Scenario |
SuiteScript 2.0 Behavior |
SuiteScript 2.1 Behavior |
---|---|---|
Parse a string value representing a number.
|
There is no value assigned to x. |
The return value for x is 8. |
Promises in SuiteScript 2.1 Server Scripts
Starting in NetSuite 2021.1, SuiteScript 2.1 supports non-blocking asynchronous server-side promises expressed using the asnyc
, await
, and promise
keywords. However, these keywords are only valid for a subset of modules: N/http, N/https, N/llm, N/query, N/search, and N/transaction. You will receive an error if you use the async
, await
, or promise
keyword in a module other than the N/http, N/https, N/llm, N/query, N/search, or N/transaction modules. In other words, no other modules support the use of the async
, await
, and promise
keywords in server scripts.