{"record":{"id":"22d101def64d8128","repo":"oxc-project/oxc","slug":"template-placeholders-will-not-interpolate-in-regu","errorCode":null,"errorMessage":"Template placeholders will not interpolate in regular strings","messagePattern":"Template placeholders will not interpolate in regular strings","errorType":"validation","errorClass":"OxcDiagnostic","httpStatus":null,"severity":"warning","filePath":"crates/oxc_linter/src/rules/eslint/no_template_curly_in_string.rs","lineNumber":9,"sourceCode":"use oxc_ast::AstKind;\nuse oxc_diagnostics::OxcDiagnostic;\nuse oxc_macros::declare_oxc_lint;\nuse oxc_span::Span;\n\nuse crate::{AstNode, context::LintContext, rule::Rule};\n\nfn no_template_curly_in_string_diagnostic(span: Span) -> OxcDiagnostic {\n    OxcDiagnostic::warn(\"Template placeholders will not interpolate in regular strings\")\n        .with_help(\"Did you mean to use a template string literal?\")\n        .with_label(span)\n}\n\n#[derive(Debug, Default, Clone)]\npub struct NoTemplateCurlyInString;\n\ndeclare_oxc_lint!(\n    /// ### What it does\n    ///\n    /// Disallow template literal placeholder syntax in regular strings. This rule ensures that\n    /// expressions like `${variable}` are only used within template literals, avoiding incorrect\n    /// usage in regular strings.\n    ///\n    /// ### Why is this bad?\n    ///\n    /// ECMAScript 6 allows programmers to create strings containing variables or expressions using\n    /// template literals. This is done by embedding expressions like `${variable}` between backticks.","sourceCodeStart":1,"sourceCodeEnd":27,"githubUrl":"https://github.com/oxc-project/oxc/blob/e1e7af627c8843ab64044ed466b128fcc21a035b/crates/oxc_linter/src/rules/eslint/no_template_curly_in_string.rs#L1-L27","documentation":"`no-template-curly-in-string` reports regular string literals ('...' or \"...\") that contain template-placeholder syntax `${...}`. Placeholders only interpolate inside backtick template literals, so a regular string with `${variable}` is almost always a forgotten backtick — the string silently holds the literal text. The rule scans string literal nodes for this pattern.","triggerScenarios":"`const msg = \"Hello ${name}\";`, `'Result: ${a + b}'`, log or SQL strings written with single/double quotes but template syntax inside — anything matching `${...}` inside a non-template StringLiteral.","commonSituations":"Converting an old concatenation to template literals and missing one pair of quotes; copying SQL or shell snippets with `${var}` from configs into JS strings where no interpolation is wanted; editors auto-quoting pasted template strings.","solutions":["If interpolation is intended, switch the quotes to backticks: `` `Hello ${name}` ``.","If the literal `${...}` text is intended (e.g. emitting a template for another engine), escape or restructure so intent is clear, e.g. store the placeholder without braces or use a comment, and suppress with `// oxlint-disable-next-line`.","Search the repo for the same mistake: `rg \"['\\\"]\\\\$\\\\{\" src/`."],"exampleFix":"// before\nconst greeting = \"Hello ${user.name}, welcome back\";\n\n// after\nconst greeting = `Hello ${user.name}, welcome back`;","handlingStrategy":"validation","validationCode":"# find ${...} inside regular quotes\nrg -n \"['\\\"]\\\\$\\\\{\" src/","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Use backticks the moment a string needs interpolation.","For strings that intentionally contain ${...} for another engine, add a disable comment.","Grep for the pattern during review of i18n/log/SQL string changes."],"tags":["eslint","oxlint","no-template-curly-in-string","template-literals","strings","interpolation"],"backgroundTag":"template-literal-misuse","analyzedSha":"e1e7af627c8843ab64044ed466b128fcc21a035b","analyzedAt":"2026-08-20T07:01:07.079Z","contentChangedAt":"2026-08-20T07:01:07.079Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}