[3.x] Update Node 20.12.2, Npm 10.5.0 and Typescript 5.4.5 (Dev bundle 20.12.2.0)

[nachocodoner]

OSS-386
OSS-385

---

Summary of this PR here

Fix on Windows tests

After the 20.12.2 node.js updates, calling spawn with a .cmd or .bat file requires the shell: true option. This PR adjusts our usage accordingly.

Update

Tests are fixed on Windows as seen on this picture:

However, it doesn't finish properly reaching this code, and it times out at the end.

And locally, I can't seem to reproduce the same, locally it finishes properly.

Trying to debug the code around spawn of child processes, since maybe one is never stop after last adjusts. But hard to verify it since locally behaves differently.

[netlify]

✅ Deploy Preview for v3-meteor-api-docs canceled.

Name	Link
🔨 Latest commit	977f775
🔍 Latest deploy log	https://app.netlify.com/sites/v3-meteor-api-docs/deploys/66462d4dcf38e40008c50fdd

[Grubba27]

you need to build a new dev bundle btw

[StorytellerCZ]

Node 20.13.0 is out:
https://github.com/nodejs/node/releases/tag/v20.13.0

[StorytellerCZ]

The latest release of Node has some reverse on Windows stuff:
https://github.com/nodejs/node/releases/tag/v20.13.1

[nachocodoner]

Thanks! Once CI responds sucessfully after recent Windows environment failures, we can proceed to 20.13.1. There are still unresolved issues with using the shell: true option for spawn scripts in a Windows environment, this has not been reverted, then self-test Meteor must continue to pass successfully.

The current problem is that CI environment don't consistently give the same success as local environment. We consider migrating to GitHub Actions using a custom runner to have greater control over the environment and see the check green at last.

[nachocodoner]

Tests pass 🟢!

To summarize what happened in this PR:

• In the Node 20.12.2 upgrade there is a breaking change on Windows environment requiring to adapt meteor tool on Windows and the spawn of processes with shell: true. Check how another library had to adapt the breaking change similarly.
• One of our CI checks started to fail, and even after fixing the breaking change, the next error araised was a timedout consistently. Some of the next work then we do is to ensure our CI tests signal green, the same way happened locally in my Windows machine. The phases on this work:
  • AppVeyor check. It triggered timeout, the process was reaching the limits. No plan to upgrade since we transit generally to GitHubActions.
  • GitHub action migration using their runners. One test didn't pass green, a specific test when testing the client part in headless mode. Likely a limitation on Github runners so we prefered to opt for other solution.
  • GitHub action migration using custom runner on a AWS machine. Having more control on the machine setup and replicate what we got locally. After several config attempts, it passed ok at last.