JavaScript Module Hierarchies

The use of import names as opposed to file-system location to resolve to MLE modules is described.

A typical Node.js or browser-based workflow requires a module import to be followed by its location in the file system. For example, the following line is a valid module import statement in Node.js:

import * as myMath from './myMath.mjs'

Used with Node.js, this statement would import myMath's contents into the current scope.

However, because MLE JavaScript modules are stored in the database, there are no file-system paths to be used for identification. Rather, MLE uses import names instead that resolve to the desired module.

Note:

As soon as a module import is detected by the JavaScript runtime engine, strict mode is enforced.

Topics

Parent topic: Overview of Importing MLE JavaScript Modules

Resolving Import Names Using MLE Environments

Rather than file-system locations, MLE uses so-called import names instead. Import names must be valid JavaScript identifiers, but otherwise can be chosen freely.

Example 5-1 Use an MLE Environment to Map an Import Name to a Module

This example shows how you might use an import name for code referencing functionality in module named_exports_module, which is defined in Example 5-2.

MLE in Oracle Database requires a link between the import name, namedExports, and the corresponding MLE module, named_exports_module, at runtime. Just as with import names, you can choose any valid name for the MLE environment. A potential mapping is shown in the following snippet. See Example 5-6 for a complete definition of module mod_object_import_mod. 

CREATE OR REPLACE MLE ENV named_exports_env
    imports ('namedExports' MODULE named_exports_module);
/

CREATE OR REPLACE MLE MODULE mod_object_import_mod LANGUAGE JAVASCRIPT AS

import * as myMath from "namedExports";

function mySum() {...}
/

Parent topic: JavaScript Module Hierarchies