Converting Q to Typescript

[mboudreau]

Hey everyone,

I've been contemplating in rewriting Q into Typescript so that the project has better type declarations directly from the source, as well as the goodness of types while coding and the safety of compiling our code to the lower common denominator.

I've been successfully using Typescript for a year now with great success in multiple projects and it's been a pleasure to code with as it catches errors sooner. I'd like to do the same for this project as the current typings on @types/q aren't great and would like it to be more compatible/interchangeable with js promises since it would help me with certain projects.

What are the thoughts of the contributors? I would hate to take on this endeavor but don't want to waste time doing so if it's never going to be merged to master.

Cheers.

[kriskowal]

I do not have strong feelings either one way or the other, provided:

• most existing collaborators sign off on the change. If @domenic or @benjamingr are weakly against the change, I’m strongly against the change.
• no breaking changes
• no changes to tests
• comprehensive testing in all supported browsers (they go back a long way)
• q.js continues to be usable in all the same environments and deployment scenarios, including as a script tag, as a Node.js / CommonJS module, and as an AMD module
• q.js must not have the string "es6". I’d rather not place bets on what Node.js / ES6 module interoperability is going to look like for the next ten years.

I would like to reserve a veto on the change if I see something alarming that I haven’t thought about.

[mboudreau]

Sounds reasonable to me and don't see any issues hitting all those targets.

…

On Tue, Feb 20, 2018 at 11:55 AM Kris Kowal ***@***.***> wrote: I do not have strong feelings either one way or the other, provided: - most existing collaborators sign off on the change. If @domenic <https://github.com/domenic> or @benjamingr <https://github.com/benjamingr> are weakly against the change, I’m strongly against the change. - no breaking changes - no changes to tests - comprehensive testing in all supported browsers (they go back a long way) - q.js continues to be usable in all the same environments and deployment scenarios, including as a script tag, as a Node.js / CommonJS module, and as an AMD module - q.js must not have the string "es6". I’d rather not place bets on what Node.js / ES6 module interoperability is going to look for the next ten years. I would like to reserve a veto on the change if I see something alarming that I haven’t thought about. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#827 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjA5Fe5yB3tngtmdmGLnP1KfZP3EZXCks5tWhgSgaJpZM4SLRxM> .

[benjamingr]

What are the thoughts of the contributors? I would hate to take on this endeavor but don't want to waste time doing so if it's never going to be merged to master.

Honestly, I think promise libraries should aim to put themselves out of business and I hope that in 4 years bluebird, Q and other libraries I maintain don't have as many users. IMO Q played a crucial role in improving how we write code in JavaScript and pushed the web forward - but part of that was paving the way for native promises - which we should probably focus on.

The Chrome (and Firefox, Edge and Safari) team has put a lot of effort into making native promises fast and usable (with long stack traces, performance and instrumentation). I'd recommend involvement in the spec (JavaScript), the engines (V8 or SpiderMonkey) or the platform (Node.js or WHATWG) over writing more promise libraries.

That said - open source in your free time is a "whatever you enjoy working on" deal. If you want to rewrite Q in TypeScript be my guest - Q is very readable compared to native promises or other promise libraries (like bluebird) and I still think it's very useful for educational value. I'm not sure it'll land as "master" but it could be an interesting branch.

On the other hand, if you want to ship Q with a bundled .d.ts file that sounds like a much easier thing to do than a rewrite.