Migrating to TypeScript? about openapi-codegen

[sledorze]

@MikeRalphson
You must (for a definition of it) try Typescript, it really improves the dev experience.
Also, (biased & personal) I tend to discard non Typescript projects as I find using Typescript is a good indicator of verifiable quality (not saying non Typescript projects are all of bad quality, here).

[MikeRalphson]

Pros? You tell me :)

Cons:

• I don't know typescript, though I am interested in it
• What if it goes the way of coffeescript?
• I don't like build steps, they take away one of the best things about javascript
• Javascript is a dynamically-typed language, and that's one of the reasons I choose to use it
• Third-party typings for dependencies are not always up-to-date and cause spurious warnings/errors
• Apparently breaking changes between Typescript v2.6.1 and 2.8.x which should not happen
• The pool of TypeScript programmers (and thus contributors) is smaller than the pool of Javascript programmers

That said, I'm always looking for feedback and collaborators.

[sledorze]

@MikeRalphson you'll find some bugs with typescript for sure (tons).
However I've heard that using Typescript as js + annotations delivers less than directly using *.ts files (More effort, much pain, lots of false errors, less value).
Not sure the best is to make an idea of what TS could bring to a project just from that approach.

[MikeRalphson]

It does seem to be a lot more popular than coffeescript based on google trends.

I meant, coffeescript was all the rage at one time, and was going to be the future of typed javascript, but now it's practically dead.

I may try Typescript on some new project to try it out, but at the moment, nothing above is compelling me to move this project to it.

[MikeRalphson]

@sledorze Improves in what way(s)? I'm struggling to find numbers on what percentage of npm packages use Typescript, but I think you may be ignoring some quality packages there. 😁

[MikeRalphson]

@chauey apart from reformatting some ifs, and a sprinkling of anys, I can see very few differences between the .js and .ts source here. Is this really enough to get much of the benefit(s) of using Typescript? Plus a command-line build step (npm script) would also be required.

Maybe a good first step would be adding Typescript-checking declarations to the Javascript source? E.g.:

// @ts-check

and fixing the resultant warnings.

[MikeRalphson]

Update: I've added // @ts-check to the Javascript source.

Pros:

• It appears to have found one actual bug.

Cons:

• All the other warnings/errors look like noise to me.

An example (and another 'Con'), typings held externally to dependent packages get out of date and throw spurious warnings. See https://github.com/debitoor/safe-json-stringify

[MikeRalphson]

@sledorze doesn't look like it's going to be "tons" based on what tsc has found so far. But as you say, probably more false positives and less real insight than if the codebase had been written in Typescript from the start, or was properly converted.

[chauey]

Main things I can think of:

• static type checking, class based objects
• autocomplete/intellisense
• ideally will produce less-bugs/better-quality

May enjoy more this way after trying it.
Can cast things to "any" if don't want the typing.
It does seem to be a lot more popular than coffeescript based on google trends.

I've used things like generics, inheritance and interfaces also, and looking into union types at the moment. Would not want to use these without TypeScript. It is easier and less/cleaner code also.

A video I found about TypeScript
https://www.youtube.com/watch?v=rAy_3SIqT-E

Main website: https://www.typescriptlang.org/index.html

After using Typescript, it's hard to go back, but I don't use non-Typescript much so I can't readily list all the pros and cons. Hope you have time to give it a try, you may like it.

Thanks

[chauey]

Was playing with some code, and wondering if "default" and "nullable" are valid properties of "param" here. And also if "form" is a valid "param.in" value. These are the type of potential bugs it may help find I believe.

I'm still weighing pros and cons also, trying it out

[chauey]

I pushed some updates to https://github.com/chauey/openapi-codegen/tree/typescript-conversion, experimenting.

converted the OAS 3.0 schema to typescript interfaces, created classes for it, added the typing for an operation parameter, then casted or checked "instanceof" of the variables/properties.

For this code to run correctly, I'm guessing the JSON/YAML OpenApi doc would be need to be parsed into the correct objects if using "instanceof" codes. More testing and learning needed...

I have never used union types and instanceof before... very cool

[MikeRalphson]

@chauey you may be interested in these projects

• https://github.com/metadevpro/openapi3-ts
• https://github.com/Apicurio/oai-ts-core

I'm really interested in specific reasons for moving this project to TypeScript, not general information about it as a language which I'm fine finding for myself.

I will take a look at the potential issues you spotted.

[MikeRalphson]

@chauey are you by any chance still interested?

[chauey]

@MikeRalphson interested, yes, but I do not know when I would be able to get around to it with current workload. Can't commit, so please proceed without me, maybe someone(s) else can take a shot at it ;)

BTW: I wonder if this would come in handy to add types https://github.com/urish/typewiz

[MikeRalphson]

Closing due to inactivity - but please feel free to reopen the issue if necessary.