Typing module.hot for TypeScript

[edemaine]

module.hot from hot-module-replacement is undeclared from a TypeScript perspective. I could manually declare it as follows:

interface MeteorModule extends NodeModule {
  hot?: {
    accept(): void;
    reject(): void;
    dispose(callback: (data: any) => void): void;
    data: any;
    onRequire(callbacks: {
      before(requiredModule: MeteorModule, parentId: string): any;
      after(requiredModule: MeteorModule, data: any): void;
    }): void;
  }
};
declare var module: MeteorModule;

(I think I got everything right, but it's worth double checking.)

I'm unfamiliar with contributing to DefinitelyTyped, and perhaps the PR should come from a Meteor dev?

Modeling after types/node/globals.d.ts, it looks like we need a new file in types/meteor called global.d.ts with the declaration above, and then users' tsconfig.json will need to change from

    "types": ["node"],

to

    "types": ["node", "meteor"],

Is this correct?

@zodern

[radekmie]

Typing module.hot is a good idea! We've also started using it here and there and for now we simply relied on some hand-crafted types, similar to yours.

A few notes though:

1. As the docs and code say - it's decline, not reject.
2. Use unknown instead of any. It's safer and if needed, one can cast it anyhow.
3. According to the Module.prototype.require implementation, both before and after properties of the callbacks argument of onRequire are be optional.
4. I'd actually suggest hot-module-replacement.d.ts to match the package name, just like the other files.

With these changes, you can file a PR to DefinitelyTyped and any of the package owners (including myself) will be able to review it. Just remember to add tests as well, so we can merge it without DefinitelyTyped maintainers!

Also, in most cases, you don't need the types property in tsconfig.json at all. By default, all @types packages are included.

---

It looks like this return is not needed, as _onRequire doesn't return anything.

[edemaine]

Thanks for all the improvements and tips! I ended up having to tweak the definitions a fair amount to avoid conflicts with Node, and to allow for the data field to be typeable by the user. (I also realized that the data argument in after is different from the other uses of data: it's the return value of before`.)

DefinitelyTyped/DefinitelyTyped#58014

[edemaine]

FYI, this is now done and released!