The @NAmdConfig Directive
At the top of your SuiteScript 2.0 file, there is a code comment section where NetSuite has some directives prefixed with “@N” that you must fill out to tell the platform what kind of script you are writing and provide some other details about your script. For Example, a typical Suitelet script might look like:
We can now link this configuration file to our script using the @NAmdConfig directive and reference our custom modules by the name we assigned it in our requireConfig.js file:
The limitation here is that the module you define a path for must compatible with the AMD format meaning it has a “define(…)” function and can be loaded by the RequireJS module loader as-is.
Including Non-AMD modules
Not all is lost for non-AMD scripts, however! The configuration file also lets us “shim” non-AMD modules for use with RequireJS. This means that at runtime, your non-AMD file will automatically get converted into an AMD module that can be used as a dependency in your SuiteScript 2.0 script. This is useful if you have a file defining some global settings that you may want to reuse in many different scripts (even SuiteScript 1.0 scripts). So, you may have a file (e.g. /SuiteScripts/Libraries/globalSettings.js) defining some of these global settings:
You can then add the path to this globalSettings.js file to the requireConfig.json file and define a “shim” object that will tell NetSuite what variable to use as the module’s return value (i.e. what it “exports”) when it converts the script for use with RequireJS at runtime:
Finally, we can now include the “settings” module in our SuiteScript 2.0 script and reference those parameters we defined in globalSettings.js:
Questions on how to get started using custom modules in SuiteScript 2.0 using @NAmdConfig? Click here to reach out and learn more!