Some fixes

[milahu]

fix #5
maybe fix #4

[futurGH]

Thanks for the contribution! This looks great for the most part; frankly more effort than I put into what was really just a throwaway script I decided to publish.

[futurGH]

Suggested change

	/**
	* Generate @returns documentation from function return type
	* the new jsDoc is stored in functionNode
	*/
	/** Generate @returns documentation from function return type and attach it to functionNode */

Good idea to include this info, though it doesn't need to be on a separate line. Same goes for the other instances where this line was added.

[milahu]

oh come on .... ^^

[futurGH]

Suggested change

	`internal error: protectCommentsHeader is missing in output\n\n` +
	`protectCommentsHeader: ${JSON.stringify(protectCommentsHeader)}\n` +
	`result: ${JSON.stringify(result.slice(protectCommentsHeader.length + 100) + " ...")}`
	`Internal error: generated header is missing in output\n\n` +
	`protectCommentsHeader: ${JSON.stringify(protectCommentsHeader)}\n` +
	`result: ${JSON.stringify(result.slice(protectCommentsHeader.length + 100) + " ...")}`

Likely less confusing to avoid mentioning the variable name in the error message; why does the header need to be JSON.stringif[ied]?

[milahu]

helpful for debugging, when ts-morph/typescript returns an unexpected value
we want to remove exactly what we added

[futurGH]

Sorry, I was referring to JSON.stringify(protectCommentsHeader). Since it's a defined constant variable where we know its content, in what scenario would the JSON.stringify call produce a more desirable output than just including the variable without the wrapping function call?

[milahu]

exact diff

[milahu]

just a throwaway script

yeah ... i wanted to throw this at patch-package to remove typescript, but keep types in jsdoc comments

but ultimately, the typescript syntax is better, and compiling is fast enough
(also there is deno to run typescript directly)
(also javascript has no nested block comments, and triple slash jsdoc comments are not implemented)

i also tried to patch ts-morph to make every TypedNode also a JSDocableNode
but i had no success in monkey-patching the import
probably we would need to patch the ts-morph source, as in dsherret/ts-morph#193

[futurGH]

Ah, I wasn't sure if the lack of JSDocableNode was intentional on ts-morph's end when I wrote this. I don't foresee much change to this codebase, so I think we're fine with the custom intersection type and perhaps less-than-ideal assertion given that it seems to work well enough. I might take another look at that if the assumption that every node ts-to-jsdoc touches is JSDocable starts causing errors, though.

[milahu]

lack of JSDocableNode was intentional on ts-morph's end

they implement a narrow spec of jsdoc (blocks: functions and classes)
but vscode can also parse jsdoc for statements

/** @type string */
let declaredVar;

declaredVar = 1;

// vscode settings.json
{
  "js/ts.implicitProjectConfig.checkJs": true
}

[milahu]

can we haz merge?

im not planning to do much more on this, as i dont need ts-to-jsdoc for now

[futurGH]

Sorry! I haven't had the time to take a look at this PR on my own machine yet — I think we can do without the tests for now considering that there still appears to be some work to be done there and I don't have the time to work on tests much myself. I'll try and merge in the rest soon.

[milahu]

thanks! : )