This project is read-only.

Publishing TypeScript code on npm?

Topics: General
Mar 7, 2014 at 8:58 PM
I'm modularising some TypeScript based code and am thinking about publishing the JS modules to npm.

But I would then use the modules in a TS project, so I would like to keep some type info.

I could either bundle the TS code in the npm package, or bundle the the declarations and come-up with a method to expose these to <references> (element in package.json or whatever).

Has anybody done this before?
Mar 8, 2014 at 3:13 AM
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:
/// <reference path="./node_modules/TypedPromises/TypedPromises.node.d.ts" />

import TypedPromises = require("TypedPromises");
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.
Mar 8, 2014 at 4:29 AM
Edited Mar 8, 2014 at 4:37 AM
JavaScript output and definitions seems the cleanest way as it is basically what you do for any npm module (but without having to source definitions yourself).

To make it easier to import in a project we could try for a community standardised typescript field in package.json (and bower.json etc).

Like so, and make it a sub-object so there is room for more fields:
    "version": "0.1.2",
    "name": "typedwidget",
    "main": "./dist/TypedWidget.js",
    "typescript": {
        "definitions": "./dist/TypedWidget.module.d.ts"
Then it is easy to write some tooling to scan your node_modules for this and bundle the references in a .d.ts file (I could add this to TSD too).
Mar 8, 2014 at 10:10 AM
@bartvds would love to see it become a feature request we can vote on.

for reference of folders that will need to scanned
Mar 8, 2014 at 2:22 PM
@basarat Good point!

I created a work item for the linked definitions, with some more explanations and an alternate solution:
Mar 9, 2014 at 11:33 PM

I just found this grunt module, looks like it tries to solve the problem of wrapping the module (like you mentioned):
Jun 13, 2014 at 10:14 PM
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.
Jun 13, 2014 at 10:40 PM
Definitions for commonJS and AMD modules need module definition wrapping with a proper encapsulated module that exports only the visible types:
declare module 'my-module' {
    // stuff here, only exporting visible parts
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).
Jun 13, 2014 at 10:42 PM
Bartvds, I'm experiencing the same problem. I have to manually copy and paste the generated d.ts files into something I can actually distribute. Such a pain!