Types & the dw API

The scripting engine uses TypeScript's language service for JavaScript, TypeScript, and Digital Script. Bundled SFCC declarations describe the platform APIs; indexed modules and generated declarations describe your project. Those types power completion, hover, signatures, diagnostics, and navigation

Bundled SFCC API types

var ProductMgr = require('dw/catalog/ProductMgr');

function getProductName(id) {
    var product = ProductMgr.getProduct(id);
    return product ? product.name : '';
}

module.exports = { getProductName: getProductName };

Invoke completion on ProductMgr or on the returned product. Hover a member for its declaration and documentation; use Go to Definition to inspect the bundled API type. No separate @types installation is needed for this editing workflow

The declarations describe the API version bundled with the extension. They do not discover a sandbox's runtime API dynamically

Give your own code useful types

/**
 * Build a readable label for a product.
 * @param {dw.catalog.Product} product
 * @returns {string}
 */
function getLabel(product) {
    return product.name || product.ID;
}

module.exports = { getLabel: getLabel };

function getLabel(product: dw.catalog.Product): string {
    return product.name || product.ID;
}

module.exports = { getLabel };

Importing the helper through a resolved require() carries its exported signature to the caller. A variable or property that remains any cannot supply the same member checks; annotations help when the engine cannot infer a meaningful type

Collection element types

Generic declarations can preserve the element type of SFCC collections and their callbacks. The extension also provides a typed overlay for the SFRA cartridge/scripts/util/collections helper when its bundled declaration is available

var collections = require('*/cartridge/scripts/util/collections');

/** @param {dw.util.Collection<dw.catalog.Product>} products */
function getProductIds(products) {
    return collections.map(products, function (product) {
        return product.ID;
    });
}

The aim is to keep product connected to the collection's element type inside the callback. A custom replacement of the helper must still have a compatible runtime API; a declaration overlay does not alter the implementation

Types generated from your project

Metadata attributes & preferences

Typed system-object attributes, preference access, custom objects, XML definitions, and usage tracking

Forms & fields

Typed native forms and SFRA wrappers generated from cartridge form XML

Typed hooks

OCAPI, SCAPI, and order hooks get their parameter and return types from hooks.json

Pipeline script dictionaries

@input and @output annotations describe the members passed to execute(args)

Keep editing and runtime behavior aligned

The engine can model require, module.superModule, Digital Script imports, and embedded ISML expressions without executing them. Type-aware editing does not install runtime globals, polyfill JavaScript APIs, or change how SFCC loads a module

Use Module resolution for cartridge paths, Imports & the Rhino engine for runtime constraints, and Diagnostics for current checking and editing limits