Skip to content

JSDoc : support @interface and @implements #16142

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cyrilletuzi opened this issue May 30, 2017 · 11 comments
Closed

JSDoc : support @interface and @implements #16142

cyrilletuzi opened this issue May 30, 2017 · 11 comments
Labels
Domain: JSDoc Relates to JSDoc parsing and type generation Suggestion An idea for TypeScript

Comments

@cyrilletuzi
Copy link

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.

@yuit yuit added Domain: JSDoc Relates to JSDoc parsing and type generation Bug A bug in TypeScript labels May 30, 2017
@mhegazy mhegazy added Suggestion An idea for TypeScript and removed Bug A bug in TypeScript labels May 30, 2017
@pulasthibandara
Copy link

hi @cyrilletuzi , any reason for closing this?

@cyrilletuzi
Copy link
Author

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.

@mhegazy
Copy link
Contributor

mhegazy commented Oct 4, 2017

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..

@pulasthibandara
Copy link

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.

@cyrilletuzi
Copy link
Author

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.

@mhegazy
Copy link
Contributor

mhegazy commented Oct 5, 2017

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?

@mhegazy
Copy link
Contributor

mhegazy commented Oct 5, 2017

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?

@cyrilletuzi
Copy link
Author

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.

@pulasthibandara
Copy link

@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.

@mhegazy
Copy link
Contributor

mhegazy commented Oct 7, 2017

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?

@art-in
Copy link

art-in commented Nov 23, 2017

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?

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Domain: JSDoc Relates to JSDoc parsing and type generation Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

5 participants