Giter Site home page Giter Site logo

Comments (62)

aoberoi avatar aoberoi commented on October 10, 2024 8

I would really love to see JSDoc comments in the emitted .js. I consider updating the comments in .ts files a "nice to have" feature, but not truly necessary, since documentation generators could be run on the emitted .js instead.

I believe solving this issue would really further the TypeScript team's story about being able to adopt the language incrementally and its compatibility with the existing JavaScript ecosystem (as opposed to forking the community and building separate tools).

from typescript.

geekley avatar geekley commented on October 10, 2024 8

Agree that this should be done by typescript compiler as part of the compilation process, there's no sense in trying to implement this using some external tool or additional compilation step.

Any improvements in this area are valid, even if not all TS types/constructs have a JSDoc equivalent, it's fine adding just the simple ones that do at first. The emitted JSDoc can slowly improve over time without worrying about backwards compatibility, since it's just a comment in a generated file.

I was unsure if I should open a new issue but ... I'd like to propose a few things:


I propose an option like "emitTypeAnnotations": "JSDoc" in tsconfig.
Obviously, those emitted comments shouldn't be affected by "removeComments": true.

We should make this (at first) specifically ONLY about emitting TS types -> JSDoc /**@type{T}*/ annotations where : T is present in source TS. No new type info needs to be added (what can be inferred in TS can also be inferred in generated JS anyway). It's just for type info from TS that would be lost in transpilation - mostly things not inferred, like parameter types, etc. Types already inferred in TS (e.g, return values), don't need to be added to JS.

Only later we could think about optimizations, like:

  • you may not need to add it if a JSDoc from TS will already be copied to the generated JS with the type information (e.g. @param)
  • you may not need to add it if it would be inferred (when : T in TS was redundant).

💻 Use Cases

  • Better error-checking in JS without needing configuration to relax strictness in type-checking.
  • Less dependency on source maps, .d.ts, online APIs, etc., when inspecting only a generated JS (e.g. from some library).
  • Easier to migrate from TS projects to pure JS; specially while https://github.com/tc39/proposal-type-annotations is not implemented (that could take forever).
    • When this proposal is implemented, you can reuse the setting like "emitTypeAnnotations": "ESNext"
  • Much more useful emitted JS wrt. compatibility with other type systems (Flow, Closure) and existing tools.

📃 Motivating Example

let ctx: vscode.ExtensionContext;
export async function activate(context: vscode.ExtensionContext) {
}

Could simply become something like:

/**@type{vscode.ExtensionContext}*/ let ctx;
async function activate(/**@type{vscode.ExtensionContext}*/ context) {
}
exports.activate = activate;

Then ship just the JS. No source maps, no .d.ts, etc.

🔍 Search Terms

emit jsdoc type generated

from typescript.

jvilk avatar jvilk commented on October 10, 2024 6

Most importantly, for me: Propagate type information into existing JSDoc comments. This would allow me to use existing JSDoc documentation generators to produce nice looking HTML documentation for my TypeScript libraries without respecifying type signatures in JSDoc comments.

(Of course, constructing a mapping between TypeScript types and JSDoc types might end up being nontrivial, especially where interface types are concerned.)

from typescript.

rick-agilifly avatar rick-agilifly commented on October 10, 2024 6

I like the fact that TypeDoc supports a good number of the Typescript features and we use it within our own projects. That said, I think it would behoove (dating myself here) Microsoft to possibly assist Sebastian in updating Typedoc or at least help integrate it with JSDoc ( perhaps as gulp components for both sides ). As Typescript continues to gain traction I think it will show the JS community at larger that this is a worthwhile tool and needs an investment in the tooling ( much like has already happened in gulp)

from typescript.

develar avatar develar commented on October 10, 2024 6

As TypeDoc has a lot of errors and cannot compile fully correct project, ts-jsdoc was implemented. (https://github.com/develar/ts2jsdoc). It allows you to use any jsdoc template. And reuse all features that jsdoc has. No need another special tool for TypeScript (e.g. JSDoc supports interfaces).

generated jsdoc annotated js file

generated docs

Only public TS API is used, any compilable project is supported. Currently, tested only for node modules. And function (callback) types are not supported (planned).

from typescript.

leidegre avatar leidegre commented on October 10, 2024 5

I would like to add that the Google Closure Compiler might be able to leverage such JSDoc tags to produce a smaller file size. Since I know the topic of minification has been discussed before with respect to the superior type information available to TypeScript, this would seem like a two birds with one stone opportunity.

from typescript.

mixtur avatar mixtur commented on October 10, 2024 4

+1 to herrernst
It would be nice to have JSDoc in emitted code, not because it would be easier to read later, but because such code can be feed to Google Closure compiler.
Generating already optimized code is another alternative.
Sorry for bad English.

from typescript.

mindplay-dk avatar mindplay-dk commented on October 10, 2024 4

I believe this feature would weigh in huge, as far as convincing established JS projects to "upgrade" their codebases to Typescript, since, effectively, this would eliminate the need to hand-write JSDoc annotations, while resulting in JS code (for plain JS consumers) of the same quality - or higher, for that matter, since Typescript annotations as well as code all gets checked at compile-time. In other words, this would save time and increase quality.

As things stand, without this feature, some JS project maintainers may well hold back, because they don't want to lose their establish plain JS consumer base, a lot of whom depend on annotations for IDE support.

(of course, IMO they should all "upgrade" to Typescript, but I'm obviously opinionated ;-)

from typescript.

alexeagle avatar alexeagle commented on October 10, 2024 4

wow issue #10 so few digits

I see comments here about emitting docs for Closure Compiler, without much mention that for complex types the translation between the two type systems is non-trivial and lossy. Now that TypeScript will have nullability it's improved a bit.

@martine on our team works on Tsickle which produces closure-compiler-compatible TypeScript code that can down-level to ES6 with goog.module module syntax, and has a (presently incomplete) typed mode to carry forward the type information. https://github.com/angular/tsickle

from typescript.

mahnunchik avatar mahnunchik commented on October 10, 2024 4

I would like to have JSDoc comments in generated js.

from typescript.

sebastian-lenz avatar sebastian-lenz commented on October 10, 2024 3

I've created a documentation generator that can directly parse *.ts files and that understands TypeScript elements like classes or types. Maybe you would like to check it out:
https://github.com/sebastian-lenz/typedoc

from typescript.

jvilk avatar jvilk commented on October 10, 2024 3

The best TypeScript doc generator I've found is TypeDoc, but it doesn't have nearly the same level of community support as JsDoc. TypeDoc is maintained by one person, who may be a bit overwhelmed with the level of interest given the rate of unanswered bug reports.

The rest of the TypeScript documentation tools I've found are orphaned, as they either:

  • Forked the TS compiler, which results in a lot of maintenance work as internal compiler interfaces evolve / new language features are added.
  • Wrote/use a custom TS parser, which results in maintenance work as the language syntax evolves.

Assuming JsDoc has reasonably complete ES6 support, it seems like it would make the most sense for a TypeScript documentation tool to output JsDoc to take advantage of all of the tooling centered around that format. And if that's enough to get reasonable Closure compiler support, I'm sure many would be quite happy!

from typescript.

Oceanswave avatar Oceanswave commented on October 10, 2024 2

+1

from typescript.

JasonKleban avatar JasonKleban commented on October 10, 2024 2

@RyanCavanaugh - Can I ask what is the current state of this? Preserving type information through to jsdoc-consuming documentation generators is a sticking point for my team's adoption of Typescript in a environment that requires supporting non-typescript project groups.

from typescript.

piranna avatar piranna commented on October 10, 2024 2

Is there any progress on this? I would be very interested on add/augment JsDoc comments on Javascript files with types inferred by Typescript :-)

from typescript.

 avatar commented on October 10, 2024 1

Yup, annotations for the google closure compiler are a must for me. Having to do it manually really limits the advantages of typing. If you get your manual declarations incorrect, it can lead to incorrectly optimized results.

As far as the "needs proposal" tag goes.. do this please :) -- https://developers.google.com/closure/compiler/docs/js-for-compiler

from typescript.

mhegazy avatar mhegazy commented on October 10, 2024 1

@hraban you are right, we will need to 1. parse jsdoc in .ts files, 2. Emit the jsdoc correctly from the AST and 3. Augment the jsdoc with type information if the jsdoc already exist.

1, is fairly trivial and so is 2. 3 needs some synthetic nodes to be created, but should not be thst complicated either (I belive it should be done as a syntactic transformation and only for explicit type annotations and not infered types).

If this is something you would like to contribute, I would be happy to help out as much as possible.

from typescript.

DrMiaow avatar DrMiaow commented on October 10, 2024 1

I would be using more TypeScript, but I need the full functionality of JSDoc. I am actually in the process of converting one of my experimental projects from TypeScript to ES6 simply because I need JSDoc documentation more than I need the features of TypeScript.

from typescript.

Shubham-raut avatar Shubham-raut commented on October 10, 2024 1

+1

from typescript.

jmatthiesen avatar jmatthiesen commented on October 10, 2024

Making sure I understand you correctly - you'd like to see the type information from TypeScript persisted into JSDoc comments in the generated .js files from your TypeScript, right? Can you give an example of a documentation generator you currently use?

from typescript.

jvilk avatar jvilk commented on October 10, 2024

you'd like to see the type information from TypeScript persisted into JSDoc comments in the generated .js files from your TypeScript, right?

Correct.

Can you give an example of a documentation generator you currently use?

I am not using a documentation generator at the moment (because it would be infeasible/frustrating to maintain type information in two locations as the code evolves), but I would like to use something like JSDoc: http://usejsdoc.org/

from typescript.

jvilk avatar jvilk commented on October 10, 2024

Your tool looks really nice! I'll have to see how it holds up to my code.

I figure it would be more elegant to avoid needing to maintain a separate project if we could find a decent mapping from TypeScript types and JSDoc annotations, but maybe that is a rathole in-and-of-itself.

from typescript.

fsoikin avatar fsoikin commented on October 10, 2024

We have a similar tool, but with a bit broader scope. It uses a template engine to generate output, which makes it perfectly usable for generating docs. Granted, there is more work for you (have to write the templates), but then you can make the output nicely customized.

Check it out: http://github.com/erecruit/TsT

from typescript.

herrernst avatar herrernst commented on October 10, 2024

As the issues on Codeplex are now closed, I'd like to link to the JSDoc request there: http://typescript.codeplex.com/workitem/1596
IMHO, JSDoc annotated output would not only be good for documentation generators but also for other tools.

from typescript.

electricessence avatar electricessence commented on October 10, 2024

+1

from typescript.

mirhagk avatar mirhagk commented on October 10, 2024

In addition to the JSDoc comments, it may be worth looking into also supporting the exports and externs for the Google Closure Compiler
https://developers.google.com/closure/compiler/docs/api-tutorial3

EDIT: Emitting export and externs for Google Closure is mentioned in #8

from typescript.

zzo avatar zzo commented on October 10, 2024

+1 for closure-style type comment annoataions

from typescript.

evil-shrike avatar evil-shrike commented on October 10, 2024

+1 for emitting jsdoc tags with type info as much as possible.

from typescript.

hraban avatar hraban commented on October 10, 2024

I'd like to take a jab at this. Can somebody from the TS project weigh in on the expected amount of work this would require? From an outsider perspective this looks suspiciously easy.

Do you foresee any major roadblocks? Or do you expect this to be as easy as it looks (slightly amend the last "code generating" compiler phase)?

from typescript.

CyrusNajmabadi avatar CyrusNajmabadi commented on October 10, 2024

Hey @hraban, this should not be too much work. You'd basically just need to:

  1. Add a compiler option for this.
  2. Fix up the emitter to respect the option.
  3. The Emitter should likely generate this information for everything we emit, and it should either augment an existing comment we are writing out, or it should add a new comment if none already exists.

from typescript.

TobiaszCudnik avatar TobiaszCudnik commented on October 10, 2024

There's also the difference with nullability. For the full closure compiler
support you may want to infere the assertions and if conditIons.

On Friday, April 17, 2015, CyrusNajmabadi [email protected] wrote:

Hey @hraban https://github.com/hraban, this should not be too much
work. You'd basically just need to:

  1. Add a compiler option for this.
  2. Fix up the emitter to respect the option.
  3. The Emitter should likely generate this information for everything
    we emit, and it should either augment an existing comment we are writing
    out, or it should add a new comment if none already exists.


Reply to this email directly or view it on GitHub
#10 (comment).

Tobiasz Cudnik
Software Developer @ Voiceworks
http://voiceworks.com

from typescript.

mhegazy avatar mhegazy commented on October 10, 2024

@TobiaszCudnik I would consider this a different feature. I would also argue this has to be only supported for explicit types only not infered ones.

from typescript.

danquirk avatar danquirk commented on October 10, 2024

Note IntelliJ's generation of JS Doc comments includes information about inferred types (in particular, inferred function return types).

from typescript.

mhegazy avatar mhegazy commented on October 10, 2024

Doing only declared types allows to implement this as a syntactic transformation, which is a. simple, and b. works for single file emit. It also allows users to manage what there public API (assuming that this is what it is used for).

from typescript.

hraban avatar hraban commented on October 10, 2024

Hey guys! I'm sorry but I am absolutely swamped at the moment. It's in the back of my mind, but on hold for a while. Definitely interested to see whatever happens once this gets picked up, though!

from typescript.

ustims avatar ustims commented on October 10, 2024

This is very outdated, but probably could be helpful: https://github.com/evanw/typescript-closure-compiler

from typescript.

hraban avatar hraban commented on October 10, 2024

Hello everyone,

I've been looking around the relevant code recently and going through the comments here.

I agree with the "we should extend existing JSDoc comments" point, eventually. It makes the most sense from an integration-with-current-tools perspective, and it would be a nice selling point, as the resulting JS would then be JSDoc consumable with automatic type annotations from TS.

This leads to situations like:

/**
 * Determine the logarithm of a number to a specific base
 *
 * @param b The base of the logarithm
 * @param {weirdType} g The number to determine the logarithm of
 * @return The logarithm of g in base b
 */
function logB(b: number, g: number): number {
    return Math.log(g) / Math.log(b);
}

Where, ideally, you would want this as the output:

/**
 * Determine the logarithm of a number to a specific base
 *
 * @param {number} b The base of the logarithm
 * @param {weirdType} g The number to determine the logarithm of
 * @return {number} The logarithm of g in base b
 */
function logB(b, g) {
    return Math.log(g) / Math.log(b);
}

In that case, we'd need not only a proper JSDoc parser, but also a JSDoc serializer.

Right now, JSDoc is not even parsed, at all, in .ts files, only in .js. We can enable it for .ts files, but that still leaves the problem of "changing" the comment before output; the comments are just copied verbatim from the source file, not rebuilt from a "jsdoc AST" as it were (even though they are properly parsed that way).

So this would seem non-trivial. What are your thoughts on this, so far?

There are a few ways around this, just to "get started", some quick and dirty solutions to get more than what we have right now, with less effort than the above. One option is to completely ignore nodes with existing JSDoc comments, hidden behind an appropriate flag, e.g. --generate-missing-JSDoc. It's not pretty (disincentivizes creating JSDoc by users), but it's a start. Ideally this will get us closer to a full solution.

What do you think? Did I misunderstand something from the code, perhaps? I'm curious to hear what people who are more familiar with the code structure have to say about it.

Regards

Hraban

from typescript.

DanielRosenwasser avatar DanielRosenwasser commented on October 10, 2024

@mhegazy, isn't @aozgaa working on something similar?

from typescript.

hraban avatar hraban commented on October 10, 2024

@DanielRosenwasser Ouh, if that's the case then it's good to know now :) I sent Arthur an e-mail to ask him about it.

@mhegazy:

  1. If all you want is information that is used by the compiler, then this is indeed trivial. Remove the if-guard at if (isJavaScript(fileName)) { addJSDocComments() } in parser.ts, and you have augmented the AST with JSDoc.
  2. However, addJSDocComments is incomplete. It ignores JSDoc elements that are not param, return, returns, type or template. If you use the parsed AST to serialize a JSDoc comment, you will lose all other tags. I think (?). Is that okay?
  3. I'm not religious about it, just fmi: why do we not want inferred types?

Thanks for offering help, I'm exploring what needs to be done for this and I might take you up on that offer. :)

from typescript.

mhegazy avatar mhegazy commented on October 10, 2024

@aozgaa is working on jsdoc tooling in the language service. so this is up for grabs.

@hraban

However, addJSDocComments is incomplete. It ignores JSDoc elements that are not param, return, returns, type or template. If you use the parsed AST to serialize a JSDoc comment, you will lose all other tags. I think (?). Is that okay?

I do not know, what other tags we need? do you have a list in mind? i think we should be adding them as we go, or just add a catch all generic tag that would be available in the tree but ignored by tooling cause they do not understand them. @CyrusNajmabadi would have better ideas here.

I'm not religious about it, just fmi: why do we not want inferred types?

  1. simplicity, no checker/ type involvement. 2. fits what we have been doing so far, of no type-directed emit. and 3. works when you are using ts.transpile, i.e. as a single file syntactic transformation and 4. (more of me pontificating) i think if you did not bother to put a type annotation, it should not be in your API, if you want it to be, may be you should think about it and explicitly specify it.

from typescript.

hraban avatar hraban commented on October 10, 2024

re: the other tags: if we make a whitelist of tags we parse to AST and rebuild the final JSDoc from that AST, the rest is lost in the output. This effectively cripples the JSDoc dialect (which is now 100%) to only those tags; the rest will be removed by tsc. This doesn't sound ideal?

from typescript.

mhegazy avatar mhegazy commented on October 10, 2024

that is why i am saying parse them, keep them in the AST, but not report errors for them for instance.

from typescript.

hraban avatar hraban commented on October 10, 2024

Understood.

I think your reason nr 4 is pretty sensible, considering sometimes automatic types are inferred quite aggressively. E.g. let vals = [{value: 3}, {value: 4}].map(x => x.value) being number[] could just be a coincidence, and maybe a future value will be "foo".

Roadmap:

  1. Parse JSDoc in .ts files
  2. Create a wild-card JSDoc node that holds unknown directives
  3. Rebuild JSDoc from the parsed AST (and verify that it's semantically equivalent)
  4. Add type info to JSDoc AST where missing from original JSDoc but specified explicitly in type annotations.

Everyone agree?

How do I create unit tests to test the " syntactical transformation" part?

from typescript.

mhegazy avatar mhegazy commented on October 10, 2024

@CyrusNajmabadi any objections/suggestions

we also need a new command line arguments for generating documentation in the output.

the test cases for ts.transpile are in here: https://github.com/Microsoft/TypeScript/blob/master/tests/cases/unittests/transpile.ts

from typescript.

CyrusNajmabadi avatar CyrusNajmabadi commented on October 10, 2024

@mhegazy

1, is fairly trivial and so is 2. 3 needs some synthetic nodes to be created, but should not be thst complicated either (I belive it should be done as a syntactic transformation and only for explicit type annotations and not infered types).

I agree with '1' and '2'. I'm not sure that '3' needs us to go so far as producing Synthetic nodes or anything that complicated. I would just take the AST for the DocComment and emit that with some specialized emit logic. It would basically emit the comment mostly as is, with some specialized logic around dealing with certain tags. For example, for an @param tag, we would:

  1. See if it already had a {...} type expression. If so, we wouldn't do anything special.
  2. If now we would just try to find the corresponding parameter for that @param tag.
  3. We'd then find out its type.
  4. Finally we would emit that type using JSDoc type exprssion notation in the doc comment we were producing.

I'm not sure I see the need for any sort of synthetic node stuff to handle this.

Note: It's also not that necessary to include the JSDoc AST in the full AST. Instead, you could just parse the JSDoc AST on-demand in certain places in the emitter. This is what we do, for example, when classifying .ts files. When we encounter a .jsdoc comment, we parse it then and there and then do not keep it around afterwards.

from typescript.

CyrusNajmabadi avatar CyrusNajmabadi commented on October 10, 2024

@hraban

However, addJSDocComments is incomplete. It ignores JSDoc elements that are not param , return , returns , type or template . If you use the parsed AST to serialize a JSDoc comment, you will lose all other tags. I think (?). Is that okay?

This is not quite accurate. The JSDoc parser doesn't ignore or lose JSDoc elements. It just doesn't create specialized nodes for JSDoc elements that it doesn't consider special. It will always at least create a tag no matter what you end up putting after the @ . This is handled in the handleUnknownTag branch of this code:

                    let tag = handleTag(atToken, tagName) || handleUnknownTag(atToken, tagName);
                    addTag(tag);
                }

So you could still preserve tags without any problem as they will be in the AST.

Create a wild-card JSDoc node that holds unknown directives

Already handled with the raw SyntaxKind.JSDocTag kind :)

I hope that helps!

from typescript.

evil-shrike avatar evil-shrike commented on October 10, 2024

Let me add some thoughts.
Generating and/or updating jsdoc for emitted js isn't enough. There are interfaces in TS which should become @typedef doclets in jsdoc comments in js.
BTW currently if I add a @typedef doclet before an interface in TS (even not in .d.ts) it will be stripped out in emitted js.

from typescript.

hraban avatar hraban commented on October 10, 2024

@evil-shrike what are your thoughts on making that a new issue altogether? We could split this up, and make this issue just about annotating e.g. function parameter types and variable types. Then we grow from there. What do you think?

from typescript.

evil-shrike avatar evil-shrike commented on October 10, 2024

I don't mind, but my point is related to "annotating function params".
It's common practice to use interfaces for params:

export class Area extends lang.Observable {
    /**
     * @constructs Area
     * @extends Observable
     * @param options
     */
    constructor (options: Area.Options) {}
}
module Area {
    export interface Options {
        title?: string;
        hidden?: boolean;
    }
}

What type for options params should be specified?
As it's typescript code it's logically to use Area.Options but it'll become meaningless in js.
Currently I have to repeat all Area.Options properties in jsdoc:

    /**
     * @constructs Area
     * @extends Observable
     * @param {Object} options
     * @param {String} [options.title] Area title 
     * @param {Boolean} [options.hidden] true to create a hidden area (can be shown later with `show`)
     */
    constructor (options: Area.Options) {}

If this type is being used in several places I'll have to repeat the comment every time. And still I have the interface undocumented in TS, so I have to repeat doc one more time for the interface:

    export interface Options {
        /** Area title */
        title?: string;
        /** true to create a hidden area (can be shown later with `show`) */
        hidden?: boolean;
    }

Too much work.

As I understand you're considering generating jsdoc comments as if no interface exists (as in the example above, without introducing a new entity as @typedoc). Right? This's better that nothing indeed. But then please consider using documentation from TS's interface properties.

Also it's unclear for me what correct behavior of the compiler would be in a case when I put TS type information for a @param in TS-code:

@param [Area.Options] options

Replacing with in-place flat structure (options.title, options.hidden) would be incorrect as I could put @typedef somewhere in js on my own and I'll lost the relation with typedef.

I believe that the problem here is that it's not stated clearly what jsdoc comments in TS code is (are?). Is it for TS or for JS only? If it's for TS then it should become part of language spec.

p.s. as for issue splitting, please feel free to move any my comments or ignore them ). I'm not sure I can correctly specify a new issue.

from typescript.

levinmr avatar levinmr commented on October 10, 2024

+1 for emitting closure compiler annotations

from typescript.

eggers avatar eggers commented on October 10, 2024

+1

from typescript.

kevin-smets avatar kevin-smets commented on October 10, 2024

Any progress for this issue? Or is there a recommended way for now to take a stab at generating docs? (looking into typedoc for now).

We're investigating the migration of some big projects to TypeScript and obviously, documentation is a big part of this, so I'm just wondering. Thanks!

from typescript.

RyanCavanaugh avatar RyanCavanaugh commented on October 10, 2024

This isn't in our near-term roadmap.

I'm not sure what the state of the art in other tools that might able to do this is, either.

from typescript.

christru avatar christru commented on October 10, 2024

+1

from typescript.

evmar avatar evmar commented on October 10, 2024

Related: #7393 is the smaller feature request, specifically to expose the compiler's JSDoc parser API for tools like documentation extractors.

Tools like TypeDoc currently must have their own separate parser for JSDoc on top of the TS API:
https://github.com/TypeStrong/typedoc/blob/2e855cf8c62c7813ac62cb1ef911c9a0c5e034c2/src/lib/converter/factories/comment.ts#L78

from typescript.

claytonsilva avatar claytonsilva commented on October 10, 2024

+1

from typescript.

kimamula avatar kimamula commented on October 10, 2024

I am trying to solve this with custom transformers, as it looks like that the feature exists exactly for solving this kind of problem.

However, I cannot find how to mutate ts.JSDoc with custom transformers.
There's no method like ts.updateJSDoc().
ts.updateMethod(), for example, does not accept a parameter of ts.JSDoc type.
https://github.com/Microsoft/TypeScript/blob/1db4f96fd14fc3de5ae3704e925afd6474cfb8f5/src/compiler/factory.ts#L582
I also tried to directly mutate ts.JSDoc which is obtained by iterating over children of ts.MethodDeclaration, which had no effect in the emitted JavaScript.

Is it possible to mutate ts.JSDoc with custom transformers?

from typescript.

mindplay-dk avatar mindplay-dk commented on October 10, 2024

How is the parity of JSDoc with TS these days, feature wise? How accurate could the emitted types be?

from typescript.

piranna avatar piranna commented on October 10, 2024

We should make this (at first) specifically ONLY about emitting TS types -> JSDoc /**@type{T}*/ annotations where : T is present in source TS. No new type info needs to be added (what can be inferred in TS can also be inferred in generated JS anyway). It's just for type info from TS that would be lost in transpilation - mostly things not inferred, like parameter types, etc. Types already inferred in TS (e.g, return values), don't need to be added to JS.

I think inferred types would make sense, but agree can be seen somewhat superfluous, so I would left it as an option.

from typescript.

GuestSneezeOSDev avatar GuestSneezeOSDev commented on October 10, 2024

Still an issue?

from typescript.

mahnunchik avatar mahnunchik commented on October 10, 2024

@GuestSneezeOSDev yes

from typescript.

piranna avatar piranna commented on October 10, 2024

How can we help to move this forward?

from typescript.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.