Implement Currying using Recursion

We have a simple function add(a, b) that returns a + b. Show me how you'd create a curried version of add using recursion in JavaScript.

If you call your curried add with only one argument, what does it return and why?

What happens if you invoke the curried function with all arguments at once versus one at a time?

Our utility curry is used across the codebase, but when a developer passes more arguments than the original function expects, we sometimes get unexpected results. Walk me through how you'd debug the recursive curry implementation and adjust it to safely ignore extra arguments.

We need to expose a curried API for a data‑fetching function fetchData(url, options, callback). Explain how you'd implement this using recursion and discuss any trade‑offs you see in terms of readability and error handling.

During a code review you notice that a curried function loses the original this context when called as a method on an object. How would you modify the recursive curry to preserve this?

You're leading a team building a functional utilities library that heavily relies on curried functions. At scale we see performance regressions when many curried functions are composed. How would you profile the recursive curry overhead and what optimizations could you apply?

Our library must work in both Node.js and browser bundles, and we want the curry helper to be tree‑shakable. What design decisions would you make for the recursive implementation to keep bundle size low and avoid runtime penalties?

We have a mix of synchronous and asynchronous functions that need to be curried. How would you adapt the recursive curry to handle functions that return promises without breaking the call‑chain semantics?

The organization is migrating a large legacy codebase to a functional style, replacing many multi‑parameter functions with curried versions. As a staff engineer, outline a migration plan that ensures backward compatibility, minimizes disruption, and addresses any pitfalls of a recursive curry implementation.

Multiple teams need a shared currying utility that works with TypeScript, provides accurate type inference for any arity, and can be extended with custom wrappers. What architectural approach would you take to make this utility maintainable, performant, and easy to evolve across services?

Consider a scenario where the curried utility becomes a public API used by external partners. How would you design versioning, deprecation, and testing strategies to evolve the recursive curry implementation without breaking existing consumers?