Statically match namespace names using `new Function().name`

I have this bit of code:

import * as express from 'express';
import {RequestHandler} from 'express';

const router = express.Router();

export const register = (v: any) => {
  router.get('/', makeGetFoo(v));
  router.put('/', makePutFoo(v));
};

namespace ApiDoc {
  
  export interface makeGetFoo  {  // <--- i want to share this interface with front-end codebase
    success: boolean
  }
  
  export interface makePutFoo  {  // <--- i want to share this interface with front-end codebase
    success: boolean
  }
}


const makeGetFoo = (v: any): RequestHandler => {
  
  return (req, res, next) => {
    
    res.json(<ApiDoc[makeGetFoo.name]>{success: true});
    
  };
  
};

const makePutFoo = (v: any): RequestHandler => {
  
  return (req, res, next) => {
    
    res.json(<ApiDoc[makePutFoo.name]>{success: true});
    
  };
  
};

my goal is to put the typings in a intermediary file, so that the types can be sourced by the front-end code. Hopefully you understand what I am trying to do.

The problem is I get this:

Cannot use namespace ApiDoc as a type

What I want to do is create a system where the interface name matches the function name so that I don’t have to guess, etc.

[svieira]

@weswigham - Point 1 actually was specified in the 2015 release (unfortunately, you have to search for SetFunctionName to find all the places, though kangax’s ES6 support table has a decent, non-authoritative list of them).

[weswigham]

I was just briefly confused by trying to puzzle out what you’re asking for. You want two things:

1. A strong, literally typed Function.name member. (This is actually really hard for things that aren’t just function declarations - that const x = () => void 0 yields a function with name "x" is by runtime convention, not spec, if I remember correctly, and that declaration/function association is heuristic. Still interesting, though. We may have another issue for this.)

2. The ability to dynamically look up types in a namespace. We can’t use square brackets for that, because we explicitly already reserved it to decompose types (ie, lookup type members), rather than lookup namespace members (and we consider those separate scopes).

Neither is particularly easy on their own (and the second would need a proposal of some kind - and a way to reason about it in higher order (ie, with generics)). You can at least avoid the second issue by writing a single interface:

interface ApiDoc {
  makeGetFoo:  {
    success: boolean
  };
  makePutFoo:  {
    success: boolean
  };
}

instead of the namespace, and then ApiDoc["makeGetFoo"] like in your followup.