It is common in such commercial agreements to provide source code or to escrow source code with a third party service with conditions that trigger release of th

It is common in such commercial agreements to provide source code or to escrow source code with a third party service with conditions that trigger release of the sources (eg bankruptcy or sale to another company that discontinues the product). So it is possible they have the full source. It is also worth considering that the JS engine likely hasn't changed much (if at all) in the past 15 years. Its bugs and limits are well-known at this point. It is also an interpreter which makes it slower* but less subject to vulnerabilities that impact the host. Honestly that's probably the correct choice for a spacecraft where reliability and safety is more important than performance. Don't get me wrong: JavaScript is a big ball of WAT and nonsense we've spent way too much effort improving but I don't blame them for making the choice so long ago and sticking with a known quantity rather than risk introducing new problems by changing things. * I once worked on a project that used IronJS to run JS in the .Net runtime. It took advantage of the runtime's JIT but was a lot of not terribly optimized F# code. I built a V8 bridge and was very excited for the increase in perf... but it got slower. It turned out most customer-written JS code spent most of its time using the API which was backed by C# code and that meant lots of bridging. At the time I left they were still using IronJS because it was faster for their workloads. It taught me the importance of testing your actual workload and taking a whole-system approach to perf.