In my last post, I asked NetSuite savvy developers not to pummel me with better ways to deal with SuiteScript 2.0 libraries (aka modules). I pointed out that using non-AMD compliant libraries had limitations. So I demonstrated how to get around these limitations. And now, I hope we’re all laughing together as I pummel myself with a better idea.

As programmers, we’ve all got to be similar in that after I finish writing code, I’m happy with it… until I find a better way. Then that old code is JUNK! So let me help you avoid junk after reading my last post.

Why use non-AMD compliant libraries?

Non-AMD compliant libraries can be ones you have no control over or are yours but too unwieldy to convert. Non-AMD libs are implemented as JavaScript namespaces (a concept, not really a construct). JavaScript namespaces are objects. Non-AMD libraries look like this:

var my_non_amd_library = { variables & functions go here };

In my last post, I demonstrated how to reference non-AMD libraries at design time, as well as how to include non-AMD libraries at runtime. If you reference at design time, you are limited to one NAmdConfig.json file per Suitelet. A config file can include multiple libraries, but the combinations of many Suitelets and libraries can leave you with lots of config files. Yuck.

Now it’s time for the pummeling! It’s not that difficult to convert a non-AMD compliant lib to AMD compliance. Let me demonstrate using the example above.

define(function() {
//variables and functions go here
return {
variable1: variable1,
function1: function1
}
}

Once you make those simple changes, you can use the standard method of including your lib. There is no limit to how many libs you can include in your Suitelet. The only issue I ran into was scoping variables that were global in scope within my library/module, but unavailable outside the define() function.

Just to close the loop, you include custom libs/modules in a Suitelet as follows:

That’s it. Super simple! Just say “No” to junk code!