Add "doc" origin to the boolean, string, number type which was created by JSDoc.

[angelozerr]

This PR add the "doc" origin to the bool, string and number type, to know that boolean, string, number type was created by the JSDoc.

This PR should be improved for @typedef.

This info can be very helpfull for :

• completion to customize it to show only type coming from the JSDoc
• for validation (tern-lint) to check the JSDoc expected type is the same than the actual type.

[marijnh]

This is not a solution to the problem you are trying to solve. You'll have the same issue with other types that the JSDoc module does not own -- types are shared, and stuffing properties in them is a bad idea. You'll also prevent the inferer from noticing that your number type and the built-in one are the same, resulting in types like number|number.

Also, if you can't even bother to make the test suite run before submitting a pull request, please don't submit it at all.

[angelozerr]

This is not a solution to the problem you are trying to solve.

My main need is to improve tern-lint validation by using JSDoc like angelozerr/tern-lint#31

When I wish to validate a node, I have an array of types which comes from JSDoc, JSON Type Definition or from JS code, so I don't know how to know if type comes from JSDoc or other mean.

If you have time, could you give me some directive please, thanks!

Also, if you can't even bother to make the test suite run before submitting a pull request, please don't submit it at all.

I agree with you, I have done that, because I'm experimenting a solution to know the origin of the type. But I will do it next time.

[marijnh]

Tern has no framework for doing what you are trying to do here, and I can't think of a solution that wouldn't require big changes to the way it works.

[angelozerr]

Ok that's very shame -(

Thanks for your answer.

[angelozerr]

@marijnh I disturb you again and I after I stop it. In my case I need to have the result type computed by your jsdocInterpretComments function of doc_comments.js stored in the aval. In other words I need to store a new docTypes field in the aval target :

function propagateWithWeight(type, target) {
    target.docTypes = type;
    var weight = infer.cx().parent._docComment.weight;
    type.type.propagate(target, weight || (type.madeUp ? WG_MADEUP : undefined));
  }

Are you agree to do add this new docTypes field according a new option. If you are OK, I will do a patch.

[marijnh]

That looks harmless enough. If you make it an option to the doc_comment mode, I'd accept such a pull request.

[angelozerr]

That looks harmless enough. If you make it an option to the doc_comment mode, I'd accept such a pull request.

Thanks @marijnh! Before doing that, I must investigate if it will work for my case. I find limitation with this solution when variable is assigned.

/**
 * @type {Boolean}
 */
var test

test = 'hello' // here I can retrieve that test has JSDoc boolean 

/**
 * @type {Boolean}
 */
var test
var test1 = test
test1 = 'hello' // here I can NOT retrieve that test1 has JSDoc boolean 

[angelozerr]

That looks harmless enough. If you make it an option to the doc_comment mode, I'd accept such a pull request.

@marijnh for your information, since I have discovered the strong option (it should be cool if this option will be in the manual), I don't need to know the origin of the type.

I will able to support multiple types validation if #557 could be fixed ( a strong option for JSON Type Definition like JSDoc).