How can I ensure that the parameter passed to a function is of a same type as the parameter of a previous function?

I would like to call a function called createLoadBalancer(name: string), and then call another function called attachInstanceToLb(lbName: string) while ensuring at compile time that the lbName of the second call has been used in the first call.

My initial, naive thought, was to do the following:

type LoadBalancerName = "first" | "second";
const createLoadBalancer(name: LoadBalancerName) = () => { ... }
const attachInstanceToLb(lbName: LoadBalancerName) = () => { ... }

but the issue with that solution is that I can still call

createLoadBalancer('first');
attachInstanceToLb('second');

and TypeScript won't complain.

How can I ensure that the attachInstanceToLb function can only be called with load balancer names that have been used as a parameter when calling createLoadBalancer()?

TypeScript's type system doesn't model arbitrary state changes, and it doesn't model global state changes at all. Generally speaking it sees values as having types, and these types don't really change. Well, there is some ability for the compiler to narrow the apparent type of a value in some scope, but these don't track arbitrary changes. There's no way to tell TypeScript that

createLoadBalancer('first');
attachInstanceToLb('second'); // error
createLoadBalancer('second');
attachInstanceToLb('first');

is bad but that

createLoadBalancer('first');
attachInstanceToLb('first');
createLoadBalancer('second');
attachInstanceToLb('second'); 

is good, because it would involve having function calls have some sort of global side-effects and TypeScript can't track that.

The closest I can imagine getting to this would be to change your functions into assertion functions which can narrow (and only narrow) the apparent type of one of their parameters. So that would mean you'd have to add a parameter to keep track of the state, and give that parameter a type which gets narrower after each call. Here's one possibility:

interface State extends Partial<Record<LoadBalancerName, true>> {}
const state: State = {};

function createLoadBalancer<K extends LoadBalancerName>(
  state: State, name: K): asserts state is Record<K, true> {
  state[name] = true;
}

function attachInstanceToLb<T extends State>(
  state: T, name: keyof T) {
};

So when you call createLoadBalancer(state, val), the type of state is narrowed to something where the property with key at val has a true value:

// const state: State
createLoadBalancer(state, "first");
// const state: Record<"first", true>
attachInstanceToLb(state, "first");
attachInstanceToLb(state, "second"); // error
createLoadBalancer(state, "second");
// const state: Record<"first", true> & Record<"second", true>
attachInstanceToLb(state, "second"); // okay

That sort of works, but it's fragile. If you do some of the calls in one scope and the rest in another, the compiler might fail to see that they happen in the necessary order. And if you find yourselves needing to represent more state, (e.g., after you attachInstanceToLb you can't do it a second time for the same key) you might eventually find yourself unable to represent that state change as a narrowing.

The "right" way to do things like this in TypeScript is to think about refactoring away from representing state changes as side-effects and toward representing state as different values. That means: each call to createLoadBalancer() returns a new object which knows about the specific key, so it's not possible to even represent an incorrect call:

function createLoadBalancer(name: LoadBalancerName) {
  return {
    attachInstance() {        }
  }
}

const lbFirst = createLoadBalancer("first");
lbFirst.attachInstance();
const lbSecond = createLoadBalancer("second");
lbSecond.attachInstance();

Here lbFirst knows about "first" and there's no way to have it attachInstance("second"). And the same with lbSecond. You might not be able to refactor this way, but it will behave much better than arbitrary state changes or assertion functions.

Playground link to code