Windows pipeline keeps freezing on 'Start' job

[nathanjhood]

As title.

I left the workflow running yesterday and clogged in this morning to see the Windows job failed after 5 hours of run time!

Just tried a re-run and had a similar stalling behaviour on the same step, same runner machine, etc.

My first thought is perhaps the positional args are not Win-friendly... but, the other steps such as yarn dev do pass.

A few things to do:

• clone the app on my Win machine and hope it reproduces the error
• carefully consider a setTimeout on the main CLI program
• verbose/debug logging mode for CI runs via env vars VERBOSE and DEBUG

[nathanjhood]

Just tried on the Windows machine. Some wierd behaviour:

• forgot about the hashbangs; obviously running the scripts directly using that mechanism may not be the most interoperable solution (hence the CLI)
• neither the dev nor start commands work on this machine, although both fail with the same issue here, which is not the same failing behaviour as the pipeline
• spawnSync appears to be the possible culprit of the issue, good old Windows paths having space character support causing the following error:

C:\<***>\esbuild-scripts [main ≡]> node ./dist/cli.js build
parseEnv('.env')
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

It might be the parsed cwd step failing. Need to do some debugging. Either way, the callback logic is getting messy and needs a rethink.

[nathanjhood]

Got it - so, by attempting to execute the file directly via hashbang, the Windows platform (when using Bash, per the pipeline, unlike above) attempts to open the script as some sort of media file type.

****@**** MINGW64 ~/esbuild-scripts (main)
$ yarn start build
yarn run v1.22.22
$ ./dist/cli.js build

The above results in the JS file being opened in my code editor, due to being associated with those file extensions :)

Using Bash on Windows; pointing Node at the script re-creates the error from Powershell:

****@**** MINGW64 ~/esbuild-scripts (main)
$ node ./dist/cli.js build
parseEnv('.env.local')
parseEnv('.env')
'C:/Program' is not recognized as an internal or external command,
operable program or batch file.

Obviously, Bash does not wish to parse the Windows-style path syntax.

[nathanjhood]

Located the problematic var:

joinedRtArgs

These are the flags and args that were originally passed to the underlying node instance; for example, when running a script via tsx these would be something psuedo-like this:

[
  'C:\\Program Files\\nodejs\\bin\\node.exe',
  '--require',
  'C:\\<path\\to\\project>\\node_modules\\tsx\\loader\\index.cjs',
  '--import',
  '<more stuff like the above, with possible broken paths...>'
]

I had already wondered whether these args should be tested somehow and parsed a bit further, but the logic could get unwieldy. The idea is to pass whatever runtime you're already using to run the chosen script with; with it's passed-in args and flags in tact.

This seems a bit messy, but parseArgs's tokenizing feature should make quite easy work of this. If the token is an --import or --require, optionally first use fs.existsSync to confirm the dependency is on disk (else, exit with a you need to yarn install first message ) and then parse it with path.resolve, to get the required format.

This is where the Promises and callbacks might turn out to be a regret. Let's see.

[nathanjhood]

Think I got it... thanks to this

Seems to be a spawn-specific thing. Adding extra string quotations and setting shell: false and we're passing on Powershell and Bash at home - when calling via tsx or node.

Let's see what the pipeline does.

[nathanjhood]

Still frozen when calling directly (instead of via node/tsx)... investigating.

[nathanjhood]

Turns out it's a fairly common thing with shebangs, Windows, and cmd.exe and the parser being called at runtime...

Pause for thought:

• dev and start are not 'real' commands that we need worry about; they are just for me to validate that things are working somewhat as expected, along the way
• instead, this package just exports itself via the bin entry in package.json, under the name esbuild-scripts, so that consumers can simply call esbuild-scripts build in their package.jsons
• the build part in their command is actually aliasing src/scripts/build.ts - not the build command in this package.json...
• so the concern is slightly moot, since this situation "never happens" in the real world; but, it was totally worthwhile to find this near-close fragility in the dev chain - it will surely rear it's head again before long

Remedy:

• explicitly call node/tsx in our package.json - it's only for pipeline testing anyway...
• "hit 'n hope" that we don't need to pass to consumers the requirement to explicitly call node/tsx in their package.jsons - react-scripts does this ok, so I have some faith

To validate the former, I'll need to consume this repo as an npm package, and it's not quiet in shape for that enough until I finish paths.ts

If the Windows pipeline succeeds by calling node/tsx directly, I will consider this a closed issue. It can be revisited if ever it turns out to be problematic later.