Function @'returns' is not exported in generated method item

[soft-decay]

Adding this to examples/Button.svelte:

/**
 * Computes the answer to your question.
 *
 * @param {string} question - a question about life, the universe, everything
 * @returns {number} the answer to all your questions
 */
export function computeAnswer(question) {
   return question.indexOf("?") >= 0 ? 42 : 23;
};

and running yarn generate-examples produces this in examples/Button.json (only showing relevant part) :

// ...
// Last item of data
{
    "keywords": [
        {
            "name": "param",
            "description": "{string} question - a question about life, the universe, everything"
        },
        {
            "name": "returns",
            "description": "{number} the answer to all your questions"
        }
    ],
    "visibility": "public",
    "description": "Computes the answer to your question.",
    "name": "computeAnswer",
    "args": [
        {
            "name": "question"
        }
    ],
    "static": false
}

The keyword "returns" exists, but it is not parsed. I found that the v3-parser already has a parseKeywords(keywords, event) method, which would also work for function declarations, the only difference being that 'event' uses params and function uses args, which is odd. Shouldn't functions also use a params key? Maybe put both in the method item and deprecate args? The return key could look something like this with the proposed modifications:

"return": {
    "doctype": {
        "kind": "type",
        "text": "number",
        "type": "number"
    },
    "type": "number",
    "desc": "the answer to all your questions",
    "description": "the answer to all your questions"
},

I'll create a PR for this so you can review the changes. Do you want me to open a different issue for the function params/args parsing or should I include it here? I could also link that issue to the same PR if this is better for you.

[alexprey]

Hi! Thanks for your colloboration on this library, I'm very glad to see issues and PR from you.
I already check your PR, thanks for that too!

I'm recheck code of function argument parsing and see that currently v3 parser parse only argument names w/o types and description. So, I think it can be a new issue.

I saw that you worry about different naming about params and args naming for event and methods. Formal that is not matter, but if we introduce a bracking changes with PR about return parsing, so, it's OK to rename args to params to keep API consistent.