Refactoring

[wehrstedt]

I have done some refactoring, because the code was pretty hard to read. It is not completely finished, but resolving the membership of the parsed items, which was one of the ugliest parts of the code, is now much more readable.

I have testet this with some typescript definition files of my projects. @whitlockjc, can you do me a favour and verify that these changes doesn't break anything in your projects? I have published a beta version to npm, you can install it with yarn add @otris/jsdoc-tsd@1.0.5-beta.0.

After you have tested these changes, I will start to solve the issues you have created.

[MichalCz]

Hi, I'd also happily add to this if any help is needed. Scramjet's website and docs heavily rely on this package.

BTW, did you happen to update the outdated mem repo?

[wehrstedt]

Im exited to hear this, any help is welcome.

Can you maybe check that these changes doesn't break your project as I mentioned above? After that, I will organize the existing issues. If you wan't you can contribute then.

[MichalCz]

Will check today.

[MichalCz]

Ok, so it seems I'm now missing all the manually defined interfaces.

Repro:

git clone git@github.com:signicode/scramjet.git
cd scramjet
npm i
npm i -D ../jsdoc-tsd # I assume you already have a copy
npx gulp tsd

And I get something like this:

[17:46:44] Invalid typedef. Typedef has no type: {"comment":"/**\n     * Options for createModule\n     *\n     * @typedef CreateModuleOptions\n     * @memberof module:scramjet~\n     * @prop {DataStream} StreamClass defines what class should the module assume\n     */","meta":{"filename":"index.js","lineno":95,"columnno":4,"path":"/workspaces/scramjet-dev-container/work/scramjet/node_modules/scramjet-core/lib","code":{}},"description":"Options for createModule","kind":"typedef","name":"CreateModuleOptions","memberof":"module:scramjet","properties":[{"type":{"names":["DataStream"]},"description":"defines what class should the module assume","name":"StreamClass"}],"longname":"module:scramjet~CreateModuleOptions","scope":"inner","___id":"T000002R000016","___s":true}

Now I'm not saying this is an error - maybe there is no type, but please confirm.

Otherwise - no changes in scramjet.d.ts - so it's good.

Oh and please update that mem. ;)

[wehrstedt]

And I get something like this:

Before my changes, if no type was passed, I assumed that it will be implicit a @typedef {object}. I changed this because its not clear to which type it should be mapped in typescript. But you are right, it's valid jsdoc, because the type is optional (see here). I will create an extra issue for that after this is merged, because this is a bigger task if you want to support this completely.

Oh and please update that mem. ;)

Do you mean this package?

[MichalCz]

Ok. I'll add the @type there and see how that works.

Oh and please update that mem. ;)

Do you mean this package?

Yes. It's outdated and has some security issue - it's a memory leak, so there's very little damage - it's only about the status.

[MichalCz]

Just a quick report - after the changes it worked well.

[wehrstedt]

Yes. It's outdated and has some security issue - it's a memory leak, so there's very little damage - it's only about the status.

Hmm.. it't not a direct dependency of this project. Seems like it comes from os-locale which is required by yargs

[MichalCz]

BTW, @wehrstedt while we're at this - maybe I'd push my proposal for extends support.

I use it in my repo like this: https://github.com/signicode/scramjet/blob/master/jsdoc2md/plugin-tsd.js#L48. I'm not proud of that hack. ;)

[wehrstedt]

BTW, @wehrstedt while we're at this - maybe I'd push my proposal for extends support.

Sorry, I didn't understand this. Never worked with jsdoc plugins. You made this workaround because this jsdoc template doesn't support extend?