no-sync
Disallow methods with a name that ends in Sync
deprecated
fs.readFileSync() and its relatives block the thread until the work is done. In a server, no other request gets handled in the meantime.
The rule only goes by the name. It reports every object.somethingSync, called or not, no matter what the object is. It doesn't catch a function that's imported by name, such as import { readFileSync } from "node:fs".
ESLint has deprecated this rule. Use n/no-sync instead, which reports those calls too.
Examples#
example.js1 problem
import fs from "node:fs";
function handle(request) {
const page = fs.readFileSyncUnexpected sync method: readFileSync.("index.html", "utf8");
return new Response(page);
}example.jsNo problems
import fs from "node:fs/promises";
async function handle(request) {
const page = await fs.readFile("index.html", "utf8");
return new Response(page);
}This blocks the thread too, but the rule doesn't catch it:
example.jsNo problems
import { readFileSync } from "node:fs";
const page = readFileSync("index.html", "utf8");Options#
| Option | Default | What it does |
|---|---|---|
allowAtRootLevel | false | Allow sync methods outside of functions, where they run once as the file loads. |
example.jswith
{ "allowAtRootLevel": true }No problemsimport fs from "node:fs";
const config = JSON.parse(fs.readFileSync("config.json", "utf8"));example.jswith
{ "allowAtRootLevel": true }1 problemimport fs from "node:fs";
function loadConfig() {
return JSON.parse(fs.readFileSyncUnexpected sync method: readFileSync.("config.json", "utf8"));
}When not to use it#
In a script or a command-line tool, nothing else is waiting for the thread, and the sync methods are simpler.