Module Dependency Paths
To specify module paths and module names, you can use the define Object or the require Function.
SuiteScript supports the following path types:
|
Path Type |
Description |
|---|---|
|
Specifies the path from the root folder in the File Cabinet. Absolute paths start with a forward slash (/). For example, "/SuiteScripts/MyApp/Util". |
|
|
Specifies the path relative to the dependent module’s location in the File Cabinet. This provides greater flexibility when moving nested folders containing modules in the File Cabinet. Relative paths can start with a period (.) or two periods (..). For example, assume that the dependent module is located in the following folder: ”/SuiteScripts/MyApp". The relative path for a sibling file under "SuiteScripts/MyApp" could be "./Util". The equivalent absolute path in this case would be "/SuiteScripts/MyApp/Util".
Note:
Do not use relative paths in global contexts. |
|
|
Specifies a bundle path that NetSuite can resolve to a File Cabinet pointer. A valid bundle ID is required in the bundle virtual path. Bundle virtual paths start with a forward slash followed by a period (/.). For example: /.bundle/<bundle id>/SS2_CustomModuleTest.js/ |
Modules can also be referenced using custom module naming which defines a global identifier used to reference a module by name instead of by a path. For more information, see Naming a Custom Module.
Absolute Paths
Avoid using any file extensions in the path.
Use an initial forward slash (/) to denote the top-level File Cabinet directory when using an absolute path. Be aware that files inherit the restrictions of parent folders. Library files must be available to users who will be affected by scripts that reference the library file.
In the following example, the Module Loader expects the custom module files lib1.js and lib2.js to be located in the SuiteScripts top-level directory in the File Cabinet.
// myModule.js
define(['/SuiteScripts/lib1', '/SuiteScripts/lib2'], // myModule has a dependency on modules lib1 and lib2
...
);
Relative Paths
Avoid using any file extensions in the path. Be aware that files inherit the restrictions of parent folders. Library files must be available to users who will be affected by scripts that reference the library file.
You can specify relative paths to modules in subdirectories from the directory of the current module.
In the following example, the Module Loader expects the custom module files lib1.js and lib2.js to be located in the lib subdirectory, the same File Cabinet directory that contains myModule.js.
// myModule.js
define(['./lib/lib1', './lib/lib2'], // myModule has a dependency on modules lib1 and lib2
...
);
Bundle Virtual Paths
Avoid using any file extensions in the path.
Use a bundle virtual path to point to a bundle File Cabinet location. Bundle virtual paths start with a forward slash followed by a period (/.). A valid bundle ID is required in the bundle virtual path.
In the following example, the Module Loader is looking for common libraries in shared bundles.
// myModule.js
require(['/.bundle/101'], // myModule has a dependency on modules with the bundle id 100 and 101
...
);
In certain situations, a virtual path can help when a bundle is moved or the bundle ID changes due to deprecation or copying. At the time of deprecation or copying, SuiteScript 2.x checks the deprecation or copy chain and looks for the file in multiple places. For example, a created bundle is deprecated by a newer version of the bundle, and the newer version is installed in the target account with a different ID. In this case, the scripts using the virtual path of the deprecated bundle in the target account use the new bundle’s ID, because the virtual bundle path automatically resolves to the new bundle.
Be aware that the ID for the created bundle in the source account could not be used to specify a virtual bundle path. The virtual bundle path depends on a file path to an existing bundle. At the time the bundle is created in the source account, no such valid file path is created yet.