Zero Configuration
How Intellij SFCC delivers full code intelligence with no tsconfig, jsconfig, npm install, or type packages
Most language tooling for SFCC asks you to wire up a tsconfig.json, install a @types/ package, add a jsconfig.json, or run a generator before anything works. Intellij SFCC asks for none of that.
Open a folder that contains cartridges and the language server configures itself.
What "Zero Config" Means
How Detection Works
When the extension activates, it discovers the cartridges in your workspace and writes two things automatically:
Cartridge discovery
The extension scans the workspace for cartridges (folders that contain a cartridge/ directory, plus configured cartridge paths). This is the same cartridge model used across the extension.
File associations
For each cartridge, server-side files are mapped to the SFCC language IDs so the language server picks them up:
| Pattern | Language |
|---|---|
**/cartridge/**/*.js | sfcc-javascript |
**/cartridge/**/*.ts | sfcc-typescript |
*.ds | digitalscript |
**/cartridge/client/**/*.js | javascript (left as-is) |
**/cartridge/static/**/*.js | javascript (left as-is) |
These associations are written into your workspace so detection is consistent for everyone who opens the project.
A generated .vscode/cartridges.json
The extension writes a .vscode/cartridges.json describing every cartridge and its path. This file is the bridge that lets tooling know which files are "SFCC-owned."
Coexisting With VS Code's Built-In TypeScript
VS Code already has a TypeScript/JavaScript language service. To avoid two engines fighting over the same file, Intellij SFCC installs a small TypeScript Server plugin (sfcc-ts-plugin) into VS Code's built-in service.
The plugin reads .vscode/cartridges.json, recognizes SFCC-owned files, and steps aside for them - so the dedicated SFCC language server is the single source of truth for completions, diagnostics, and navigation on your cartridge code. Plain front-end JavaScript (under client/, static/, node_modules/) keeps using VS Code's normal service.
This happens transparently:
- The plugin is registered by the extension; you do not edit any
tsconfig.jsonto enable it. - It works with the workspace TypeScript version when one is present.
Because the SFCC server owns cartridge files, you will not see duplicate diagnostics from VS Code's built-in JS/TS service on those files. If you ever see two sets of squiggles, make sure the front-end folders (client/, static/) are excluded - they are by default.
The Payoff
Because everything is automatic, the experience is the same whether you are:
- Cloning a brand-new SFRA storefront,
- Opening a legacy SiteGenesis project full of
.dsfiles, - Or jumping into a single cartridge with no package.json at all.
In every case, open the folder and you immediately get dw.* completion, navigation, and diagnostics.