This library's goal is to be able to take as input a jsdoc annotated source JavaScript file (or many files) and output a single TypeScript Declaration File (.d.ts).
It is distributed as a JSDoc3 template. Running jsdoc with this as the template should result in a TypeScript Definition File.
You can install this module from npm:
$> npm install tsd-jsdoc
To use this module, simply specify it as the template for your normal jsdoc generation.
For example, from the command-line you can do:
$> jsdoc -t node_modules/tsd-jsdoc -r .
Or add this to your JSON configuration:
{
"opts": {
"template": "./node_modules/tsd-jsdoc"
}
}
This library provides very little validation beyond what jsdoc provides. Meaning if you have invalid jsodc comments, this will likely output an invalid TypeScript Definition File.
Additionally there are things that jsdoc allows, that TypeScript does not.
One example would be a member variable marked with @constant
. While that is valid
jsdoc, it is not valid TS:
class MyClass {
const member: number; // ERROR: A class member cannot have the 'const' keyword.
}
So there a few cases like this where the jsdoc is massaged into valid TS.
This syntax is used to link to another module's docs. If you use it to describe the code, it will be ignored.
For example, this JavaScript:
const Loader = require('resource-loader');
/**
* @class
* @extends module:resource-loader/Loader
*/
function MyClass() {
Loader.call(this);
}
MyClass.prototype = Object.create(Loader.prototype);
Will generate this declaration:
class MyClass {
}
Instead you can include their jsdoc commented source or write your own jsdocs to
describe Loader
and then just use @extends Loader
.
Any method or member that has the same name as one in the parent of a child class
will be ignored in the Child class, unless it is a method with different parameters
that is not marked with the @override
tag.
For example, this JavaScript:
/**
* @class
*/
class Parent {
constructor() {
/**
* A property.
*
* @member {boolean}
*/
this.someprop = true;
}
/**
*/
amethod() {}
/**
*/
bmethod() {}
}
/**
* @class
* @extends Parent
*/
class Child extends Parent {
constructor() {
/**
* The property again
*
* @member {boolean}
*/
this.someprop = false;
}
/**
* @override
* @param {object} opt - Does stuff.
*/
amethod(opt) {}
/**
* @param {object} opt - Does stuff.
*/
bmethod(opt) {}
}
Will generate this declaration:
class Parent {
someprop: boolean;
amethod(): void;
}
class Child extends Parent {
bmethod(opt): void;
}
Tags that describe the code, but support is not implemented are:
@default
- No TS equivalent@deprecated
- No TS equivalent (issue)@event
- No TS equivalent@exports
- Everything is exported since it is a definition file.@external
- Not Yet Implemented@fires
- No TS equivalent@listens
- No TS equivalent@override
- No TS equivalent (issue)@this
- Not Yet Implemented@throws
- No TS equivalent
Additionally, tags that are just metadata and don't actually describe the code are ignored. These are:
@author
@classdesc
@copyright
@description
@example
@file
@license
@requires
@see
@since
@summary
@todo
@tutorial
@version
All other jsdoc tags should work fine.
ClosureCompiler has a couple tags beyond the built-in jsdoc tags that can improve your TypeScript output. Here is a complete list of the tags from CC that are supported in this template:
@template
- For generics