Scopes & Types

A Digital Script file sees what the server gives it: the Script API with its standard library, its own import calls and the modules it requires. The plugin types variables from annotations, loops and E4X, and reports names the server won't have

Host objectsUnresolved namesLoop typesJob step parameters

STstorefrontSandbox 01version2

Timers.ds

1var t = setTimeout(function () {}, 10);

2console.log('total', 1);

3var list = new java.util.ArrayList();

4if (typeof setInterval === 'function') {}

5var p = Promise.resolve(1);

6var next = PIPELET_NEXT;

'setTimeout' is not available on B2C Commerce

'PIPELET_NEXT' exists only in pipelet scripts

'console' is not available on B2C CommerceUse dw.system.Logger.debug⌥⇧↩

storefrontapp_customcartridgescriptslibTimers.dsGlobal scopeLFUTF-8

The server scope

.ds files and server .js files resolve names against the bundled Script API typings and your project's modules. The typings declare the standard library the server runs, so the IDE's ES libraries such as lib.es5.d.ts stay out. Server .ts files keep them, without the browser libraries. A script also sees the same script in the other cartridges, as an override does, see Overrides

• Map and Set resolve, as the Script API declares them
• Browser and Node.js names such as window, document, fetch and setTimeout don't resolve, and are reported as host objects
• Client .js files keep the IDE's usual browser scope

Host objects

Host object B2C Commerce does not have is a warning on the browser, Node.js and Java names the server lacks, such as 'setTimeout' is not available on B2C Commerce:

setTimeout, setInterval, clearTimeout, clearInterval, setImmediate, console, process, Buffer, window, document, XMLHttpRequest, fetch, Packages, java, JavaAdapter and JavaImporter

The Use dw.system.Logger.debug fix turns a console call into a Logger call of the same level: log, debug and trace become debug, and info, warn and error keep theirs

A weak warning comes from the same check: 'module' does not exist in templates in <isscript> code, and the same for exports

Unresolved names and types

All three are errors in the Unresolved name, type or script path color, red with a wave in every bundled scheme. In Digital Script they replace the IDE's weak unresolved warning, and client .js files keep it. An importScript path that names no script takes the same color

Name that nothing declares skips an assignment that creates a global, a typeof operand, host objects, and names in comments and with blocks. In templates it also skips the names any <isset> in the project sets. A noinspection JSUnresolvedReference comment still silences it, and while the IDE indexes the IDE's own warning shows instead

Block const

On B2C Commerce a const declared in a block, such as an if, a try or a loop, holds for the whole function. The plugin scopes it the same way

STstorefrontSandbox 01version2

labels.js

1function shippingName(basket) {

2 if (basket.defaultShipment.shippingAddress) {

3 const address = basket.defaultShipment.shippingAddress;

4 }

5 return address.f

6}

firstNamestring

fullNamestring

storefrontapp_customcartridgescriptscheckoutlabels.jsGlobal scopeLFUTF-8

• A read after the block resolves, is typed and completes, and the constant isn't reported as unresolved or unused
• Cmd+Click, Find Usages and Rename cover every read in the function
• Convert to let and Convert to const aren't suggested while 'let' or 'const' in server code runs, which is on by default. With that check off or without a license, Convert to const isn't suggested inside a loop, where the const would keep its first value, or for a name the function declares twice
• Duplicate declaration doesn't report a var that sibling blocks each declare with their own value

To write var instead, see let and const

Type annotations

Rhino type annotations type variables, parameters and return values:

importPackage(dw.catalog);
importClass(dw.order.Basket);

function product(id : String) : Product {
    return ProductMgr.getProduct(id);
}

var basket : Basket = null;
var item = product('sku-1');

A call of a function with a return annotation gets that type, so item above is a dw.catalog.Product. To switch between annotations and JSDoc, see Intentions

Loop types

A loop variable gets the element type of what it iterates:

Quick documentation on each says what the loop yields, such as "Iterates the values of the map. for (k in m) iterates its keys."

E4X types

After feed. completion offers the element names of the file's XML literals, then the XML methods. After @ it offers only the attribute names. E4X members are never reported as unresolved

Parameters the server passes

A JSDoc @param wins over both. A script-module-step without a function runs execute. These types wait until indexing ends

.ds, .js and .ts together

• require('./helper') finds helper.js, then helper.ds, then helper.json, as the server does
• A .ts source deploys as .js, so require finds foo.ts as foo. A .js beside its .ts wins
• A .d.ts beside a .ds or .js module types what require returns
• require of a .ts with ES exports gives the whole namespace object, never the default alone
• In a server .ts file, a default or namespace import of a .ds or .js module gives its module.exports

Name that changes when a .ts source deploys catches what breaks on upload:

A .js built from its .ts, with __esModule or a //# sourceMappingURL= comment, isn't reported as a clash

Related