Live Template variable substitution fails silently in HTML files

The short answer

Nothing in the file type itself blocks an environment-variable lookup. What changes between HTML and JavaScript is almost always one of two things: the variable's expression evaluates to null in the HTML context, or the environment variable simply isn't visible to the IDE process. In both cases WebStorm does not report an error — it substitutes the variable's Default value (or an empty string) and inserts the template anyway. That silent fallback is by design, so the fix is to make the default value loud rather than to hunt for an error message that doesn't exist.

What actually controls resolution

Live Template variables have no native "read an environment variable" function. The standard approach is an expression such as:

groovyScript("System.getenv('FOO')")

That expression is file-type-independent — it runs in the IDE's own JVM and doesn't care whether the target file is HTML or JS. So if it works in a .js file but comes back empty in .html, check these in order:

1. Template context. The template only expands at all if its "Applicable in" contexts include HTML. If you broadened the context recently, the template now inserts in HTML but an expression that depends on code context (anything inspecting the PSI, caret position, or language) can return null there.
2. The expression itself. If it mixes a language-aware function with the env lookup, the language-aware part is the usual suspect. Keep the expression a pure groovyScript on System.getenv or System.getProperty.
3. How WebStorm was launched. Environment variables are inherited from the IDE's parent process. A variable exported in ~/.zshrc is present when you start WebStorm from a terminal but often absent when it's started from the macOS Dock, Windows Start menu, or a desktop launcher. This produces exactly the "works sometimes, silent blank other times" pattern.

Diagnostics: what exists and what doesn't

There is no verbose logging switch or preview mode for Live Template variable expansion — unresolved expressions are deliberately swallowed so a bad template can never block editing. The practical diagnostic is a sentinel default:

1. Open Settings → Editor → Live Templates and edit the variable.
2. Set Default value to a visible marker, e.g. MISSING_ENV_FOO, instead of leaving it blank.
3. Expand the template in both an HTML and a JS file. If you see the sentinel, the expression returned null — the lookup failed, not the file type.
4. To isolate the launch-environment cause, expand the same template after starting WebStorm from a terminal (webstorm . or the platform equivalent) versus from the GUI launcher, and compare.

Configuration recommendations

• Give every variable an explicit, human-readable default — that is the only "warning" mechanism the feature offers.
• Define contexts explicitly per language rather than one broad context, so a null-prone expression can't leak into file types where it can't evaluate.
• Keep env lookups in their own variable with a single-purpose groovyScript expression.

Caveats

The exact fallback semantics (empty string vs. default value vs. a leftover $VAR$ marker) have varied across IDE versions, so verify on your installed build rather than assuming. If the sentinel still appears after confirming the variable is visible to the IDE process, the two details that would pin it down are the exact variable expression and your WebStorm version — those determine which fallback path applies.