fix: Improved understanding of setImmediate and setTimeout output

[legendAhsan]

Description

In the understanding-processnexttick.md file we have code example output for setImmediate and setTimeout. While that output holds true for ES modules case and have indeterministic behaviour in CommonJS case. I mentioned it to improve the understanding, incase a person tries to run the code and get confused.

Validation

Check List

• [x] I have read the Contributing Guidelines and made commit messages that follow the guideline.
• [x] I have run npm run format to ensure the code follows the style guide.
• [x] I have run npm run test to check if all tests are passing.
• [x] I have run npx turbo build to check if the website builds without errors.
• [] I've covered new added functionality with unit tests if necessary. - Not required

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Sep 13, 2024 11:42am

[legendAhsan]

@mikeesto Can you look into this PR?

[legendAhsan]

@aduh95

import assert from 'node:assert'

let order1223344 = 0;
let order1224433 = 0;
let other = 0
const totalRuns = 999

function runTest() {
  return new Promise((resolve) => {
    const output = [];
    
    console.log('Hello => number 1');
    output.push(1);
    
    setImmediate(() => {
      console.log('Running before the timeout => number 3');
      console.log('Running setImmediate in the check phase => number 3');
      output.push(3);
      output.push(3);
      if (output.length === 7) resolve(output);
    });
    
    setTimeout(() => {
      console.log('The timeout running last => number 4');
      console.log('Running setTimeout in the timers phase => number 4');
      output.push(4);
      output.push(4);
      if (output.length === 7) resolve(output);
    }, 1);
    
    process.nextTick(() => {
      console.log('Running at next tick => number 2');
      console.log('Running process.nextTick in the nextTick queue => number 2');
      output.push(2);
      output.push(2);
    });
  });
}

for (let i = 0; i < totalRuns; i++) {
  runTest().then(numbers => {
    try {
      assert.deepStrictEqual(numbers, [1, 2, 2, 3, 3, 4, 4]);
      order1223344++;
    } catch {
      try {
        assert.deepStrictEqual(numbers, [1, 2, 2, 4, 4, 3, 3]);
        order1224433++;
      } catch {
        console.log({ numbers });
        other++;
      }
    }
    
    if (i === totalRuns -1) {
      console.log({ order1223344, order1224433, other });
    }
  });
}

I feel that the above output you got is because Spawning childs may run like a CJS script while in module it is asynchronous. Put the above code in module file like common.mjs and you will see that it will only increment 1223344 variable.

[aduh95]

I feel that the above output you got is because Spawning childs may run like a CJS script while in module it is asynchronous. Put the above code in module file like common.mjs and you will see that it will only increment 1223344 variable.

It seems to me it has nothing to do with ESM or CJS, rather how busy is the event loop. Anyway, it's good to know that sometimes it's deterministic I guess, but as I've shown in https://github.com/nodejs/nodejs.org/pull/6994#pullrequestreview-2335997716, it's not always the case.

[bmuenzenmeyer]

Core Collaborators are ultimately responsible for approving content, not the website team, so I'd like @aduh95 to provide the final say on this.

[aduh95]

As I said earlier, it would be wrong to use "is the source parsed as ESM/CJS" as a confounding variable for how those functions would behave. The exact same functions are exposed, therefore they behave exactly the same, and it would be wrong to document otherwise, and probably confusing for readers.