In response to the dialogue above, regarding the use of a SS2.1 module with a non-SS2.x client script. The replies are wrong in point of fact and in so far as they confuse the requirements of client scripts with those of the modules client scripts (and other types of scripts) can include in the

define

statement. 1. Requiring a SS2.1 module in a client script via

define

will not cause errors in the evaluation of the client script. The client script is evaluated correctly as a non-SS2.1 client script. NetSuite checks the doc block for special tags, the entry-point definitions, etc. 2. The SS2.1 custom module is evaluated correctly as a separate module. It does not have to satisfy the requirements of a client script. In that regard, a custom module has no entry points. 3. A "conditional require that only runs in the browser" is not a solution. That would be OK for any scripted functionality that exists independent of the functionality of the client script functions, but that is not the purpose of this suggestion. The purpose of requiring the custom module is so that you can call functions that exist within the same scope of the functions defined in the script. Please test assumptions! Your code will be better for it.

im not saying that it doesnt work, im saying that it will fail when netsuite evaluates the client script file like when working in the ui

That is not a valid module, and it is a mishmash of ECMA5 and ECMA6 syntax. Let me rewrite it correctly. The main thing missing is the docblock tag that NetSuite requires.

you can try giving examples of what you mean

OK. This is true: there will be an error if the require is there when you create the script record. But there will be no error if you add the required module after creating the script record. I think that this technique does not apply to people who don't use SDF. It's more for people who want to use post-2015 JavaScript.