0
votes

We are trying to get core-js@3 to work properly in the SuiteScript 2.0 server-side execution environment, for all of its (very nice to have) ECMAScript 6 polyfills.

The bundled version of the library seems to work fine. For example, this works OK in the Script Debugger:

/**
 * @NApiVersion 2.x
 */
require(['/SuiteScripts/core'],
  function() {
    var test = Array.from(new Set([1, 2, 3, 2, 1]));
  }
);

(Where /SuiteScripts/core.js is the version 3.6.4 bundled version of the library.)

However, we'd prefer to use the standard (unbundled) version of the library because this will allow us to selectively load only the features we need. We uploaded version 3.6.4 of the library to our File Cabinet and then tried to load it:

File Cabinet

/**
 * @NApiVersion 2.x
 */
require(['/SuiteScripts/core-js'],
  function() {
    var test = Array.from(new Set([1, 2, 3, 2, 1]));
  }
);

This results in the following error:

{"type":"error.SuiteScriptModuleLoaderError","name":"MODULE_DOES_NOT_EXIST","message":"Module does not exist: /SuiteScripts/core-js.js","stack":["<anonymous>(adhoc$-1$debugger.user:4)"]}

It appears that RequireJS is doing something weird in the SuiteScript 2.0 environment, because normally, referring to a directory from require() should cause RequireJS to look for an index.js in the directory? If we refer to the index.js file in the directory directly, then we just get a different error when the index.js file tries to require('./es') the es subdirectory:

/**
 * @NApiVersion 2.x
 */
require(['/SuiteScripts/core-js/index'],
  function() {
    var test = Array.from(new Set([1, 2, 3, 2, 1]));
  }
);

Error message:

{"type":"error.SuiteScriptModuleLoaderError","name":"{stack=[Ljava.lang.Object;@73882a5d, toJSON=org.mozilla.javascript.InterpretedFunction@53fe9f7f, name=MODULE_DOES_NOT_EXIST, toString=org.mozilla.javascript.InterpretedFunction@32f5a028, id=, message=Module does not exist: /es.js, TYPE=error.SuiteScriptModuleLoaderError}","message":"","stack":["<anonymous>(adhoc$-1$debugger.user:4)"]}

We have tried various mechanisms of modifying the RequireJS configuration that we found suggested in NetSuite documentation and on the web, such as @NAmdConfig /Directory/... JSDoc argument, and require.config(...), with no success. @NAmdConfig seems to be totally ignored in every execution context we have tried it in, and require.config(...) can't be used to mutate the primary RequireJS context configuration.

Is index.js resolution simply broken in SuiteScript 2.0's RequireJS implementation? Are there any work arounds?

1
Can you share the directory structure from where your source NetSuite entry level script resides? that would help to zero-in on your problem. From what I could gather was you had your source NS script in some other directory, so could try using define(['require'], function (require) { }) in your source script file? You can check this out for further clarification.Avi
The simplified entry point script I referenced in my OP was copy-pasted directly into the Script Debugger to make it easier for other people to reproduce... however, we have observed the same behavior in scripts which we run from the File Cabinet. I read the article that you linked to, but I don't think it addresses the problem we are trying to solve. Loading require with define(['require'], function (require) { }) did not fix the index.js resolution problem that I described.Joe Crivello

1 Answers

3
votes

NetSuite uses a customized version of require, with no documentation on exactly what said customizations are. For best results, you will want to use minified, rolled-up versions of any libraries you want.

If you want to pick and choose features of core-js, you should use webpack or rollup or whatever compilation tool you want to build the library the way you want, then import the single resulting file in your SuiteScript modules.

Alternatively, if your goal is ES6+ features, you can try using SuiteScript 2.1 instead.