Skip to content

impliedEvals

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

✅ This rule is included in the ts logical and logicalStrict 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.

function setTimeout(handler: TimerHandler, timeout?: number, ...arguments: any[]): number (+2 overloads)
setTimeout
("alert('Hello');", 1000);
function setInterval(handler: TimerHandler, timeout?: number, ...arguments: any[]): number (+2 overloads)
setInterval
("counter++;", 100);
const
const code: "console.log('executed');"
code
= "console.log('executed');";
function setTimeout(handler: TimerHandler, timeout?: number, ...arguments: any[]): number (+2 overloads)
setTimeout
(
const code: "console.log('executed');"
code
, 0);
new
var Function: FunctionConstructor
new (...args: string[]) => Function

Creates a new function.

@paramargs A list of arguments the function accepts.

Function
("a", "b", "return a + b");
var window: Window & typeof globalThis

The window property of a Window object points to the window object itself.

MDN Reference

window
.
function setTimeout(handler: TimerHandler, timeout?: number, ...arguments: any[]): number (+2 overloads)
setTimeout
("doSomething()", 100);

This rule is not configurable.

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.

Made with ❤️‍🔥 around the world by the Flint team and contributors.