strong-soap transitive uuid 13/14 (dist-node ESM) hangs deno/Windmill consumers

[sieteunoseis]

Summary

A transitive uuid dependency (via strong-soap) can resolve to uuid 13.x / 14.x, whose exports map points the Node condition at ./dist-node/index.js (ESM). Deno-based consumers behind a caching npm proxy — specifically Windmill deno scripts — hang forever trying to load that dist-node/index.js, so the job never starts and is killed at the instance job-duration limit (~600s).

Root cause

• cisco-axl depended on strong-soap via ^5.0.8.
• strong-soap@5.0.8 requires uuid ^13.0.0; 5.0.9/5.0.10 reverted to uuid ^11.1.1.
• uuid layout by version:

  uuid	Node export	deno/Windmill proxy
  8.3.2	dist/index.js (CJS)	✅
  11.1.1	dist/cjs/index.js	✅
  13.x	dist-node/index.js	❌ hangs
  14.0.0	dist-node/index.js	❌ hangs

Symptom in Windmill: the only recurring Download log line is .../uuid/13.x/dist-node/index.js, and main() never runs.

Fix (shipped)

v2.1.2 exact-pins "strong-soap": "5.0.10", which uses uuid ^11.1.1 (CJS dist/cjs layout). This makes resolution deterministic — no stale resolver or future strong-soap patch can pull uuid 13/14.

Why keep this open / future risk

strong-soap draft PR loopbackio/strong-soap#1232 proposes bumping uuid ^11.1.1 → ^14.0.0. uuid 14 keeps the dist-node/index.js layout, so if that lands and we loosen the pin (e.g. back to a range), the hang returns. Track until upstream uuid usage stabilizes on a deno-proxy-friendly layout before relaxing the exact pin.

Notes for consumers

• Windmill deno scripts: ensure the lockfile resolves uuid to 11.x/8.x.
• Switching the consuming script to the bun runtime sidesteps the deno npm proxy entirely.