tslint give no warning when use await in a for...loop.

[mrdulin]

Bug Report

• __TSLint version__: "tslint": "^5.5.0"
• __TypeScript version__: "typescript": "^2.7.0-dev.20171108"
• __Running TSLint via__: VSCode

TypeScript code being linted

// code snippet
const fetch = () =>
  new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(Math.random());
    }, 1000);
  });

const getRandomNum = async () => {
  for (let i = 0; i < 3; i++) {
    const res = await fetch();
    console.log(res);
  }
};

getRandomNum();

with tslint.json configuration:

{
  "extends": "tslint:recommended",
  "rules": {
    "object-literal-sort-keys": false,
    "object-literal-key-quotes": [true, "as-needed"],
    "quotemark": [false],
    "trailing-comma": [
      true,
      {
        "multiline": "never",
        "singleline": "never"
      }
    ],
    "ordered-imports": [false],
    "no-console": [false],
    "max-line-length": [true, 150],
    "no-consecutive-blank-lines": false,
    "no-empty": false,
    "no-empty-interface": false,
    "no-trailing-whitespace": false,
    "only-arrow-functions": [false],
    "space-before-function-paren": false,
    "curly": false,
    "no-namespace": false,
    "no-reference": false,
    "no-var-requires": false,
    "comment-format": [false],
    "arrow-parens": false
  }
}

Actual behavior

tslint give no warning

Expected behavior

should like eslint, give warning like this:

[eslint] Unexpected `await` inside a loop. (no-await-in-loop)

[suchanlee]

why would you expect tslint to give you warnings in this case?

[suchanlee]

I don't think it's the responsibility of tslint to keep track of where and how you use your awaits. The above is valid code and depending on what the context is it may or may not be correct. tslint helps with readability, maintainability, and functionality errors, none of which I believe include this particular issue.

Closing but happy to revisit if you feel strongly otherwise.

[dgreene1]

~For future readers, for of supports blocking for each promise to resolve.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of~

~So use that instead of for or foreach~

Better answer: For future readers, I think it’s valuable to clarify why the eslint community chose to consider the scenario above an error. Please see that explanation (here)[https://eslint.org/docs/rules/no-await-in-loop]. But to be brief:

Performing an operation on each element of an iterable is a common task. However, performing an await as part of each operation is an indication that the program is not taking full advantage of the parallelization benefits of async/await.

Usually, the code should be refactored to create all the promises at once, then get access to the results using Promise.all(). Otherwise, each successive operation will not start until the previous one has completed.

As for me, I tend to follow the approach of bundeling all of the Promises in a loop and then passing that array of promises to a Promise.all so that I can the user can get a response faster.

But for those times when you do need the api calls to line up behind each other then yes the approach described by the OP is valid. Which is why the tslint community has chosen (so far) to not implement a rule that prevents it.

[jordanbtucker]

@dgreene1 Why do you recommend using for...of over for? They both block with await in same way.

[dgreene1]

@jordanbtucker, you are correct. I’ve updated my comment above.

I think I had been taking the promise.all approach so often that I forgot that the regular for does the trick. So when I saw that tslint wasn’t picking up the “issue” I assumed that it had to do with the choice of loop. After looking up the original issue I realized that the lint rule the OP was asking for had more to do with a reminder that calls can often be parallelized.

Anyway, thank you for the correction @jordanbtucker.