In my
TypedPromises library, my npm prepublish step compiles the file to JavaScript and also outputs TypeScript definitions using the -d flag. I include both the compiled JavaScript and the definition file in the package install so anybody who wishes to use the
TypeScript definitions can do so. However, I also have to include an extra file
TypedPromises.node.d.ts to declare the module. To use the module, a consumer of the module must do the following:

This is a little more work than I'd like, but it seems to work well enough. I wish there was someway to tell the TypeScript compiler to just look in node_modules. If there was some standard, TypeScript modules could always just put their definition file in
the same place in their module and the compiler would know where to look.

The problem with the d.ts file wrapping the module as demonstrated is that any package that decides to use it now will compile not just their own source code, but also your package's source code along with it. I've already been using this approach and
this is the issue I've had. If there was a way, instead, for the TypeScript compiler to somehow generate this d.ts file for a Node.js package, that would be idea.

Even the typescript package on npm doesn't have a proper module export. Maybe when they start talking about how to expose an API we can see how they do it, but for now, I'm kinda' lost.

One big problem when trying to hack this is how when you write TS code using external module pattern you get a huge pile of individual definition files which you need to process and transform into a single module.

So far the low-tech methods to automate this fail to do this reliably as even those individual files are not correct declarations for external modules and de-duplicating is impossible (the limitations around single exports mess it up).