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.
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?
Most helpful comment
Voting for reopening this issue and support '@interface' and '@implements'
@cyrilletuzi
But if pain comes from lack of supported
jsdocfeatures then let's support it, right (why close the issue)?Or there are any other concerns about
tsannotations vsjsdocannotations?