#LuxentTechTalk | Loading Custom Modules in SuiteScript 2.0 using @NAmdConfig

Are you tired of not being able to reuse your custom modules or other third-party JavaScript libraries in NetSuite’s SuiteScript 2.0 API? The article below will teach you how to load custom modules in SuiteScript 2.0 using @NAmdConfig.

The ability to customize NetSuite to suit your business needs is virtually unlimited with the application of SuiteScript – NetSuite’s JavaScript-based platform for customized scripting.  Upon the release of SuiteScript 2.0, NetSuite modernized this platform, especially by encapsulating their API into discrete modules and using a module loader to manage script dependencies.  While NetSuite’s SuiteScript 2.0 API provides a wealth of functionality on its own, sometimes it’s useful to extend that functionality with your own custom, reusable modules or other third-party JavaScript libraries.  This can become cumbersome without the use of the little-known @NAmdConfig directive NetSuite provides to configure extra modules for easy use within your scripts.


NetSuite decided to use RequireJS as their module loader to define and load a script’s dependencies in SuiteScript 2.0.  There are many modular design patterns within JavaScript, but RequireJS uses a specific pattern called AMD (Asynchronous Module Definition).

It’s worth noting that the NetSuite platform itself is written in Java, which, despite its similar name, has no connection at all to JavaScript – the language SuiteScripts are written in.  So, when a SuiteScript is running on the NetSuite platform, it’s actually JavaScript running inside of a larger Java application.  This makes SuiteScript scripts a little different from other JavaScript scripts and applications you might find on the web (it’s also the likely reason NetSuite settled on using RequireJS and AMD for their module loading technology).

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:

If you want to include a third party JavaScript library such as lodash.js and use it within your script, you can upload that file to your file cabinet (e.g. /SuiteScripts/Libraries/lodash.js) and include the full path in your script’s dependency array:

This can get clunky, particularly if your script depends on several custom or third party modules or if you ever want to reorganize your file cabinet.  However, using the optional @NAmdConfig directive lets you configure and maintain the paths to your custom modules in a separate file and then link that configuration to your script.  This configuration file must be a .json file.  JSON (JavaScript Object Notation) is an extremely common syntax for storing and exchanging data using key-value pairs, and it very closely represents a typical JavaScript object.  This .json file should have a “paths” object that defines all the paths to your custom module scripts.  In this example, we’ll put this file in our Libraries folder: /SuiteScripts/Libraries/requireConfig.js

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:

A screenshot of a social media post  Description automatically generated

Questions on how to get started using custom modules in SuiteScript 2.0 using @NAmdConfig? Click here to reach out and learn more!