Typescript: JSDoc : support @interface and @implements

Created on 30 May 2017  路  11Comments  路  Source: microsoft/TypeScript

TypeScript Version: 2.3.3

Code

In a JavaScript file, with checkJs option :

/**
 * @interface Movable
 */

/**
 * @function
 * @name Movable#move
 * @param {number} distance
 */

/**
 * @implements {Movable}
 */
class Vehicle {}

Actual behavior:

No error.

Expected behavior:

An error should be raised. It's important in checkJs mode as JavaScript doesn't have native interfaces.

JSDoc Suggestion

Most helpful comment

Voting for reopening this issue and support '@interface' and '@implements'

@cyrilletuzi

First because when checkJs mode was released I was very excited to be able to have the power of static types but staying in native JS. But in the end it's really more painful than to be in real TypeScript, especially for that kind of advanced features.

But if pain comes from lack of supported jsdoc features then let's support it, right (why close the issue)?
Or there are any other concerns about ts annotations vs jsdoc annotations?

All 11 comments

hi @cyrilletuzi , any reason for closing this?

First because when checkJs mode was released I was very excited to be able to have the power of static types but staying in native JS. But in the end it's really more painful than to be in real TypeScript, especially for that kind of advanced features.

Second, because there was no reaction, so I supposed my early enthusiasm was really not such a good idea.

But in the end it's really more painful than to be in real TypeScript, especially for that kind of advanced features.

wondering if you can elaborate about your experience with checkJS..

In my case I'm still a bit reluctant to transpile my node.js code or use something like ts-node. Even if its a bit verbose, having the option to define interfaces in .d.ts files and use them in actual js code is really useful for some compile time type checking.

My main use case for checkJs is in Node, but I wouldn't go as far as writing interfaces in jsdoc, it's already quite heavy and messy to just write @typedef for objects, and to manage to have the types for all the libraries used.

Even if its a bit verbose, having the option to define interfaces in .d.ts files and use them in actual js code is really useful for some compile time type checking.

Why is not @typedef not sufficient?

My main use case for checkJs is in Node, but I wouldn't go as far as writing interfaces in jsdoc, it's already quite heavy and messy to just write @typedef for objects, and to manage to have the types for all the libraries used.

Have you considered adding .d.ts for your types and using these in your .js files?

Well, no :/ In my head it was "full JS" or "full TS", but I didn't thought I could mix both worlds. Therefore, jsdoc for interfaces is really not needed.

@mhegazy I did try using .d.ts files. But I couldn't figure out how to use the interfaces defined there on the js files.

did try using .d.ts files. But I couldn't figure out how to use the interfaces defined there on the js files.

were both modules?

Voting for reopening this issue and support '@interface' and '@implements'

@cyrilletuzi

First because when checkJs mode was released I was very excited to be able to have the power of static types but staying in native JS. But in the end it's really more painful than to be in real TypeScript, especially for that kind of advanced features.

But if pain comes from lack of supported jsdoc features then let's support it, right (why close the issue)?
Or there are any other concerns about ts annotations vs jsdoc annotations?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tenry92 picture tenry92  路  146Comments

rbuckton picture rbuckton  路  139Comments

metaweta picture metaweta  路  140Comments

Taytay picture Taytay  路  174Comments

blakeembrey picture blakeembrey  路  171Comments