As of node@16 the NodeJS.Global interface has been removed in favor of globalThis.

You can declare new global variable in a module file as:

declare global {
  var NEW_GLOBAL: string;
}

And in a non-module file (no top-level import/export) as:

declare var NEW_GLOBAL: string;

Important note: variable must be declared as var. let and const variables don't show up on globalThis.

Here's an approach. I don't know if this is the 'correct' way of doing things, but it works for me with TypeScript 3.7.4.

1. Assuming your source files live in a folder src, create a new folder src/types and create a file global.d.ts in this folder.
2. Author your declarations using one of the following strategies:
   • If you need to import external types into your declaration file, use the following syntax:

import { Express } from 'express';

declare global {
  namespace NodeJS {
    interface Global {
      __EXPRESS_APP__: Express;
    }
  }
}

• If your declaration file does not contain any imports, the above will not work, and you'll need to use this syntax instead:

declare namespace NodeJS {
  interface Global {
    __CONNECTION_COUNT__: number;
  }
}

4. Make sure your global.d.ts file (and any other files you might add to src/types) is picked up by the TypeScript compiler, by adding the following to your tsconfig.json file:

{
  "paths": {
    "*": ["node_modules/*", "src/types/*"]
  }
}

5. Use the global variable as normal inside your code.

// Below, `app` will have the correct typings
const app = global.__EXPRESS_APP__;

You're defining the type for the compiler, but not actually attaching it to the global namespace — window in the browser, global in node. Instead of exporting it from the module, attach it. For isomorphic use, use something like...

function s() { ... }

// must cast as any to set property on window
const _global = (window /* browser */ || global /* node */) as any
_global.s = s

You can also ditch the .d.ts file and declare the type in the same file using declare global, e.g.

// we must force tsc to interpret this file as a module, resolves
// "Augmentations for the global scope can only be directly nested in external modules or ambient module declarations."
// error
export {}

declare global {
  function s<T>(someObject: T | null | undefined, defaultValue?: T | null | undefined) : T;
}

const _global = (window /* browser */ || global /* node */) as any
_global.s = function<T>(object: T | null | undefined, defaultValue: T | null = null) : T {
  if (typeof object === 'undefined' || object === null)
    return defaultValue as T;
  else
    return object;
}

You probably shouldn't be using a global variable for what you're trying to do, but…

to let TypeScript know about your own properties on the global object you need to augment the Global interface in a d.ts file:

export interface Global {
 myProp: string;
}

If all you want is to 'share' stuff across files (i.e. modules) you probably want to export from your modules rather than add to the global object.

globalThis is the future.

First, TypeScript files have two kinds of scopes

global scope

If your file hasn't any import or export line, this file would be executed in global scope that all declaration in it are visible outside this file.

So we would create global variables like this:

// xx.d.ts
declare var age: number

// or 
// xx.ts
// with or without declare keyword
var age: number

// other.ts
globalThis.age = 18 // no error

All magic come from var. Replace var with let or const won't work.

module scope

If your file has any import or export line, this file would be executed within its own scope that we need to extend global by declaration-merging.

// xx[.d].ts
declare global {
  var age: number;
}

// other.ts
globalThis.age = 18 // no error

You can see more about module in official docs

The piece of code you shared is making use of global augmentation https://www.typescriptlang.org/docs/handbook/declaration-merging.html#global-augmentation

// Hint typescript that your global object will have a custom signin function
declare global {
  function signin(): Promise<string[]>;
}

// Assign value to global.signin
global.signin = async () => { /* implementation */ };

Likely one or multiple modules ("mongoose", "supertest", "../app") imported by the test file is using global.signin (or window.signin) at some point (or maybe one of their nested imports is => look for "signin(" in the project). Thus for testing purposes, global.signin needed to be mocked. However just adding global.signin = something would raise a typescript error, because signin is not a standard global variable. This is where declare global comes into play. It hints typescript that in your particular context, a signin function is expected to exist in global scope.

I don't think what you're trying to achieve is doable without some sort of IoC that supports scoped lifecycles. Something like InversifyJS do support scoped lifecycles. I haven't used InversifyJS for Azure Functions before, though, and the samples I could find with my limited Google-foo skills seem experimental at best:

• mgomezarr's example on github
• jakkaj/Jordan Knight's take, also available on github

But the gist of it would be a service which is registered as scoped, and have a public property (either directly or via getter/setter methods) that can store your information (see inRequestScope for registering scoped services in InversifyJS).

Since the http trigger would be the root of the dependency graph in our case, and have the scoped service as dependency, any other dependencies we inject/resolve from our http trigger should share the same instance. Using the explanation on the about page for inRequestScope (the A -> B -> R, -> C -> R sample), "A" for us would be the HttpTrigger, and "R" would be the scoped service, "B" and/or "C" would be other services, like your user.service.ts.

I will note that this seems slightly excessive to implement, if all you want to achieve is to avoid having to parse values between methods (personal take). However, if your project is really large, and you have a lot of dependencies, and some of the values you have to parse around is for a dependency several layers deep, then I can understand why you want to avoid it.