[erictgrubaugh]

Is there a way to use `require.config` such that it applies globally to an account? I am currently using this to alias d3:

Code:
require.config({
paths: {
“d3”: “/SuiteScripts/lib/d3.min.js”
},
shim: {
“d3”: {
exports: “d3”
}
}
});
define([“d3”], function (d3) { … });
This works as expected, but it means I need that `require.config` block in *every* script where I want d3. Is there a place I can define it once and be done with it for the account?
This is a cached copy. Click here to see the original post.

[david.smith]

I’m surprised you’re using d3.

---

erictgrubaugh replied on 10/06/2016, 12:57 PM: I’m not anymore. I ditched d3 because I don’t want to learn to be a graphic/web designer; I just want to say, "Hey, draw me a pie chart". I switched to Chart.js, which is working great.

I also noticed that NetSuite already includes Highcharts on dashboards, which is an amazing library, but it is not accessible from Portlets.

Would still like to know if we can globally configure `require` somehow. I tried a few different mechanisms of including a module that did the configuration, but no dice.

If it’s not possible right now, I think it definitely should be.

[david.smith]

erictgrubaugh So if I understand, you’re asking for a global require config library to be loaded on every script in the account?

[erictgrubaugh]

I’d like to be able to define paths and shims for custom modules and third-party libraries on an account-wide basis, so that any time I want to pull in, say, d3 or lodash or moment, I can simply write:

Code:
define([“d3”, “lodash”, “moment”], function (d3, _, moment) { … });
Instead of the very verbose:

Code:
require.config({
paths: {
“d3”: “/SuiteScripts/lib/d3.min.js”,
“lodash”: “/SuiteScripts/lib/lodash.min.js”,
“moment”: “/SuiteScripts/lib/moment.min.js”
},
shim: {
“d3”: {
exports: “d3”
},
“lodash”: {
exports: “_”
}
}
}); define([“d3”, “lodash”, “moment”], function (d3, _, moment) { … });

[JacksonP]

I’m not sure if I’m missing something, but I created a folder in the file cabinet just named ‘S’ and I load in moment.js by typing

Code:
/**
* @NApiVersion 2.x
* @NScriptType UserEventScript
* @NModuleScope SameAccount
*/
define([‘N/record’, ‘S/moment’],
/**
* @param {record} record
* @param {moment} moment
*/
function(record, moment) {

[david.smith]

You are

./S/ oment

[JacksonP]

I mean I just tried using it with this code and it worked fine in debugger.

Code:
/**
* @NApiVersion 2.x
* @NScriptType UserEventScript
* @NModuleScope SameAccount
*/
require([‘N/record’, ‘S/moment’],
/**
* @param {record} record
* @param {moment} moment
*/
function(record, moment) {
afterSubmit();
function afterSubmit(scriptContext) {

var date = moment().format(‘dddd’); // returns Friday
test = 1;
}
return {
afterSubmit: afterSubmit
};
});

---

david.smith replied on 10/07/2016, 09:14 AM: afterSubmit(); ??

try removing that 1st line

[erictgrubaugh]

Sure if your path is nice and short, and you’re using an AMD-compatible library like moment, it’s not so bad. But when your paths to common libraries are multiple levels deep in the file cabinet, or you’re trying to use a non-AMD library, like d3 for instance, you end up with this massive chunk of unnecessary boilerplate in all your scripts.

I would like to be able to define library paths and shims at an account level. It does not seem like this is currently possible.

[david.smith]

I couldn’t imagine this ever being available. Doing so would cause issues with other scripts.

Here is a thought. I haven’t tried this but it might work.

Code:
var path = “/SuiteScripts/lib/”;
define([path+”d3.min”], function (d3) { … });

[ironside]

I want the same feature – largely because I’m using TypeScript, which emits AMD modules perfectly but I can’t seem to get it to emit the require.config() stuff at all.

It would require some sort of build process patching that boilerplate onto every file and I’m not willing to add that complexity to our lightweight development process.

[david.smith]

erictgrubaugh Have you considered just using the relative path option?

Code:
define([“./lib/d3.min”], function (d3) { … });

---

erictgrubaugh replied on 10/07/2016, 04:32 PM: I have, and this is exactly what I do when the libs I’m using are packaged up in the same folder structure as the code I’m building. Works like a charm. Sometimes though, especially when doing Account Customization rather than building say a SuiteApp, the libs are in a more common place, or out in a different module, so the relative path will often be "../../../lib/d3.min". The paths aren’t the only problem; either; there are also the shims.

The current functionality certainly works, but it’s way more verbose and repetitive than I think is necessary.

I would prefer there to be one single place in the account I could go to let the SuiteScript 2.0 engine know: "Whenever I tell you to load the module named ‘greatStuff/myAwesomeModule’, you should grab that from /SuiteScripts/common/lib/anotherUnnecessaryFolder/com/src/js and it will export an `awesome` variable". As it is now, I have to re-tell the engine those details every time in every script where I want to load myAwesomeModule. Again, it works, but it’s bulky and repetitive, and that’s definitely a pet peeve of mine.

[chanarbon]

Hi Eric,

I would like to agree with david.smith that it is a better option to use the path-based approach on importing your library e.g. d3. As of the moment, I haven’t heard of the option to globally create a require.config(). Another alternate solution is to create a library which will act as you mask or alias to the libraries that you want to be imported and have this alias library imported to your scripts on its dependencies.

[Jim ThompsonMember @jim_thompson]

Eric,

I have an environment where I have 1 production account 4 sandbox accounts. Moving work across 5 environments is cumbersome and time consuming.  I’m trying to figure out if there is a way I can create a utilities library module in production and configure  the sandbox accounts to really load in the production version of the module. For example…

In production, no special config would be needed. I just put the utils.js in the correct location in the file cabinet…

define([‘L/utils’],function(utils){…..});

In the sandbox accounts I would need to figure out some configuration that mapped ‘L/utils’ to the public/external url of utils.js in production. Then the same code would work in the sandboxes but would really be loading the production version.

It that possible?

[Adolfo GarzaMember @adolfo_garza]

Yeah, you can load any library/file as a string and then run the code using eval.

[Jim ThompsonMember @jim_thompson]

Eric,

I’ve moved to have a single lib file that dynamically loads on other libraries as needed. All my scripts use this single lib file as the module to load and to access the other libs. I’ve just used Object.defineProperty to dynamically load in additional functionality as needed. This gives me one central location to manage new functionality and things like version control. I call this my “core” set of libraries and this project always gets deployed as single project through environments.

define([some native NS commonly used modules],function(…){

require([the list of my libraries and less common NS libs ]);

_this= {};

Object.defineProperty(_this,”moment”,{

get: function(){

if(!this._moment){

this._moment = require(‘/SuiteScripts/Libs/moment’);

}

return this._moment;      }    });

….

return _this

}

Now, when consumed by a script the script always refers to the  same property on the core library but I can control which version of that core library is used by changing one file.

define([‘/SutieScripts/Libs/utils’],function(utils){
var moment =utils.moment;
…..

});

[Author]

Posts