ASK HN: How to engineer a JavaScript to Python migration?

Line by line, don't overthink it.

Programmers have an unhealthy aversion to repetitive tasks. Sometimes you just have to do work-work. Happens all the time in other industries,

clock in at 9 do the same thing for 2 hours, take a break, do the same thing for 2 hours, lunch, 2 hours break, 2 hours, go home.

Repeat this for weeks if necessary, you can plan it out and predict when it will be done, if need be ask for more resources.

Was it Larry Wall that said "it's easier to port a shell than a shell script"?

I've done similar inter-language changes, and I have always found it easier to not change the language of the business logic. (Unless the change gives you something really big - for me I often port stuff to numpy because I need the vectorized code, but that's only for very specific problems).

If I had this task, the place where my brain would go would be to find a way to compile JS into C and then use C calling conventions to call the functions from Python. Keep the JS code around so that if you need to change anything, you change it in JS and then recompile to C.

I don't know the JS space very well, but can you get a JS interpreter that lives in Python? That way you can call JS functions from Python?

I don't like transpiling, there's always enough differences between the languages that something bad happens. When I've run into issues like this, since I'm an "old guy", I tend to try to get everything into C calling conventions and use that as my base interface.

Worst case, there has to be some good JS interpreter that can give you a C interface that you could call from Python. So you'd have Python -> C -> JS and your business logic can still live in JS (if your port is because of efficiency and you need compiled code, then you can ignore me.)

A comment would be useful about what people disagree with so much. OP starts with "I was tasked with migrating a legacy workflow system..." rather than tasked with converting the code, so it may be useful to bring other alternatives to the table.

There are type system gotchas. My favorites have to do with integers in place of JS's double-only numerics, the treatment of undefined and nulls, especially in arrays.

The LLM's are just fine at AST translation, though they might inject their quirky preferences if you don't watch them carefully. Suggestion: use the LLM's, but interactively, to translate one script at a time, starting with the simpler ones. Tell the LLM to explicitly call out potential issues. Manually review each, and incorporate the issues and preferences you learn into the prompt. If all goes well, the process will quickly converge on a cut and paste job, but don't be tempted to fully automate it if it's a hundred scripts -- different matter if it's thousands.

110% this. Resist the urge to make changes until everything is moved over. Any system 'enhancements' may also be viewed as bugs/defects, and reduces trust, requiring lengthier validation.