Overview

The dedicated language server that powers code intelligence for SFCC server-side scripts - JavaScript, TypeScript, and Digital Script

Intellij SFCC ships a dedicated Language Server (LSP) built specifically for Salesforce B2C Commerce. The Scripting LSP is the part that handles server-side code - it turns VS Code into a full-featured SFCC IDE with autocomplete for the dw.* API, cartridge-aware require() resolution, go-to-definition across the cartridge overlay, real-time diagnostics, hover docs, signature help, and symbol search.

It is always on and requires zero configuration. There is no tsconfig.json, jsconfig.json, npm install, or type package to set up - open an SFCC project and everything works.

Looking for ISML templates? See the ISML LSP section. The two share one language server, so scripting intelligence even reaches inside ${ } expressions and <isscript> blocks.

What It Covers

The Scripting LSP understands every server-side script and the project files that drive intelligence for them:

Language IDFilesWhat you get
sfcc-javascript**/cartridge/**/*.jsFull type-aware completion, navigation, and diagnostics
sfcc-typescript**/cartridge/**/*.tsThe same, written in TypeScript
digitalscript*.ds (Digital Script)First-class support - treated like a script file, no config
isml**/cartridge/templates/**/*.ismlFull script intelligence inside ${ } and <isscript> - see ISML LSP
jsonhooks.json steptypes.json caches.json api.jsonSchema validation plus key/name completion and navigation
properties*.propertiesResource bundle key indexing for Resource.msg()
yamlCustom API / SCAPI schemasEndpoint and operation indexing
xml*.xml metadataDrives generated types

ISML counts as script, not just markup. The engine reads inside ${ } expressions and <isscript> blocks, so dw.*, require(), and your pdict get the same intelligence there as in a controller - the full detail is in Scripting in ISML below. The exception is front-end bundles under cartridge/client/ and cartridge/static/: those are intentionally left as plain JavaScript, since the Scripting LSP only takes over server-side code.

Language Features

Every server-side script gets the full set of language-intelligence features, powered by a real TypeScript engine running over the bundled dw.* types and types generated from your own project metadata:

Code completiondw.* API members, require() paths, SFRA routes, hook names, template paths, and resource keys, all context-aware.
Go to DefinitionJump across the cartridge overlay to APIs, required modules, routes, hooks, templates, metadata, and property keys.
Find All ReferencesEvery usage of a symbol, route, hook, or resource key, gathered across all cartridges.
Hover & Quick InfoInline dw.* type signatures and your own JSDoc, rendered as you point at a symbol.
Signature HelpLive parameter hints while you fill in a function call.
DiagnosticsReal-time, type-aware errors plus SFCC-specific warnings as you type.
Quick FixesCmd / Ctrl + . code actions such as add-missing-import, surfaced on the lightbulb.
Inlay HintsInferred parameter names and types woven inline into the code.
Code LensActionable links above hooks, routes, step types, custom APIs, and resource keys.
Symbol SearchOutline, document symbols, and Cmd / Ctrl + T workspace search across scripts, hooks, routes, custom APIs, and step types.

Code Lens

Beyond the editor basics, the plugin renders actionable Code Lenses above the SFCC artifacts that wire your cartridges together, so the indirection between configuration and code is one click away in both directions:

HooksOn a hook implementation, a lens names the system or custom hook it handles and jumps to its declaration in hooks.json.
Routes & ControllersEach endpoint gets Open Endpoint, Copy Endpoint URL, and an N usages lens that peeks every caller across cartridges.
Step TypesA lens on a step function links back to its entry in steptypes.json.
Custom APIsLenses jump between api.json, the OpenAPI schema, and the implementation script in any direction.
Resource BundlesEvery key in a .properties file shows N usages and N localizations, each opening a peek.

Scripting in ISML

ISML templates are treated as real scripts, not just markup. Everything inside ${ } expressions and <isscript> blocks runs on the same engine as a .js controller, with full go-to-definition, find references and usages, hover, completion, and diagnostics for the dw.* API, required modules, and your pdict, <isset>, and <isloop> variables, which are all modeled as real, typed scope. See the ISML LSP for tag completion, custom tags, template navigation, and formatting.

Explore the Scripting LSP

On this page