Importing Typescript class from another npm library

[omer727]

Hi,
I'm working on node.js with npm. I've written a TS library and I want to use it in another project by doing npm install.
I'm not sure what will should be the contents in my npm package:
should it be only .js, only .ts, or .js with additional declaration files (d.ts)?

Furthermore if I'm using the third option, what exactly am I writing in the definition file? how exactly am I using it?I'm not sure what's the connection between d.ts and the actual javascript.
I see a lot of different answers but most them didn't help me.

Thanks,
Omer

[mhegazy]

The .js is the executable, and the .d.ts is the type information that goes with it. in C terms, .js is your .dll , the .d.ts is your matching .h file.
you want to distribute matching .js and .d.ts.

on the consumption side, your user would do require("module") and that would load the JavaScript (based on node resolution logic, looking in node_modules and package.json and so forth).

import m = require("module");

To load the types you need an explicit reference to the .d.ts, this is a bug that should be fixed in future releases (issue #247), to do that in your consumer add:

/// <reference path="node_module/module/module.d.ts" />
import m = require("module");

[omer727]

I tried to write like you suggested:
I wrote the following ts class

    class Person {
        name:string;
        toString():string{
            return "the person name is "+name;
        }
    }

than to use it, I tried to compile it using the command
tsc --module "commonJs" --target "ES5" Person.ts --declaration
I took the results (js,and d.ts files) and put them in a different project under node_modules\demo
and wrote the following test:

/// <reference path="node_modules/demo/person.d.ts" />
import Person = require('person');
var p:Person;

console.log(p.toString());

my node_modules\demo\person.d.ts looks like this

declare class Person {
    public name: string;
    public toString(): string;
}

but when I compile using this command:
tsc --module "commonJs" --target "ES5" consumer\test.ts
I'm getting the following output:

C:\tdemo\consumer\test.ts(2,1): error TS2071: Unable to resolve external module ''person''.
C:\tdemo\consumer\test.ts(2,1): error TS2072: Module cannot be aliased to a non-module type.

What am I missing?

[ahejlsberg]

You need to export the class:

class Person {
    name:string;
    toString():string{
        return "the person name is "+name;
    }
}
export = Person;

A file with no imports or exports is not considered a module (but rather it is considered a "global" file that will be included using <script/> tag or some other means).

[omer727]

I tried that but I still have problems with line:2 import Person = require('person');
when I compile the code using the command: tsc --module "commonJs" --target "ES5" test.ts
I get the following output:

C:\tdemo\consumer\test.ts(2,1): error TS2071: Unable to resolve external module ''person''.
C:\tdemo\consumer\test.ts(2,1): error TS2072: Module cannot be aliased to a non-module type.

I didn't find any reference which explains it clearly.
It will be helpful to get a simple example.

[mhegazy]

Here is what i have.

file: demo/person.ts

class Person {
    name:string;
    toString():string{
        return "the person name is " + this.name;
    }
}
export = Person;

file: test.ts

/// <reference path="demo/person.d.ts" />

import person = require("./demo/person")
console.log(new person().toString());

call the compiler on test.ts:

node c:\ts\built\local\tsc.js --m CommonJS test.ts

run it:

node test.js

this the result I am getting:

the person name is undefined

[omer727]

Ok. It works. Thanks a lot!
I guess i need to explicitly require the full path of the .d.ts and js files.

Let me ask you another question.
If I want that person will be in module demo.

demo\person.ts

module demo{
 class Person {
    name:string;
    toString():string{
        return "the person name is " + this.name;
    }
 }
export = Person;
}

so when I'll import the file I'll get the module, and I'll aggregate several classes under one module:
test.ts

/// <reference path="demo/person.d.ts" />
import demo = require("./demo/person")
console.log(new demo.person().toString());

how to do it exactly?
I'm not sure about the details
(The documentation doesn't give enough examples, this is something that require improvement)

[danquirk]

It sounds like you want to export Person rather than export=. Export= will make the module behave like the target identifier. So in this case you could say new demo() and you now have a Person. If instead you do not use export= and add an export modifier to class Person you'll access it through new demo.Person() like you have tried to do here.

[mhegazy]

your module demo is an "internal" module. so that is not going to work with node. This is a tricky issue that ppl have commonly ran into. i would look at the module wiki page first.

[atrauzzi]

This is a crazy amount of work involved that typescript offers no help with to get a basic unit of code sharing/reuse.

[danquirk]

If you have some specific suggestions please do file issues. Modules in JS have been difficult for some time now and they're unfortunately complicated in TS as well. That should be getting better with ES6 modules. In an ideal world you might expect things like an npm JS package to include a .d.ts (we've had suggestions of this sort) and less confusion over what is/isn't an internal/external module and what that really means (we have a suggestion to use namespace instead of internal module to help reduce confusion).

[atrauzzi]

Dan Quirk (@danquirk) - Definitely, I've just opened another ticket with some thoughts. And I think I've probably got another volley of observations as I try to articulate just what makes all of this so difficult.

[bgrieder]

There does not seem to be much tooling (external to the ts compiler) available either. A similar question I asked n StackOverflow is not attracting many answers... (http://stackoverflow.com/questions/31654376/automatically-generating-ambient-module-declarations)

This issue should trigger more attention. The ability to easily write reusable (external) modules - usable both from typescript and javascript - is key to large application and APIs development and maintenance.