impliedEvals

Reports using string arguments in setTimeout, setInterval, setImmediate, execScript, or the Function constructor.

✅ This rule is included in the ts logical presets.

JavaScript’s eval() function is generally discouraged because it executes arbitrary strings as code, making programs harder to analyze and creating potential security vulnerabilities. Several other APIs similarly evaluate strings as code:

• setTimeout() and setInterval() accept a string as their first argument
• setImmediate() accepts a string as its first argument
• execScript() (Internet Explorer only) accepts a string
• The Function constructor creates functions from strings

These “implied evals” have the same problems as eval(): they’re difficult to analyze statically, prevent many optimizations, and can introduce security risks if the string contains untrusted content.

Examples

❌ Incorrect

setTimeout("alert('Hello');", 1000);

setInterval("counter++;", 100);

const code = "console.log('executed');";
setTimeout(code, 0);

new Function("a", "b", "return a + b");

window.setTimeout("doSomething()", 100);

✅ Correct

setTimeout(() => {
  alert("Hello");
}, 1000);

setInterval(() => {
  counter++;
}, 100);

setTimeout(myCallback, 0);

const add = (a: number, b: number) => a + b;

setTimeout(handler.bind(context), 100);

Options

This rule is not configurable.

When Not To Use It

If you have a specific use case that requires dynamic code evaluation and you’ve carefully considered the security implications, you might disable this rule for those specific instances. For example, certain build tools or code playgrounds may legitimately need to use these APIs with string arguments. Consider using Flint disable comments for those specific lines rather than disabling the rule entirely.

Further Reading

• MDN: eval()
• MDN: setTimeout()
• MDN: Function constructor

Equivalents in Other Linters

• ESLint: no-implied-eval@typescript-eslint/no-implied-eval
• Oxlint: typescript/no-implied-eval