search

alexa-js / alexa-app

A framework for Alexa (Amazon Echo) apps using Node.js
https://www.youtube.com/watch?v=pzM4jv7k7Rg
MIT License
1.03k stars 212 forks source link

Typescript Implementation and Typings #148

Open RobertTheProfessional opened 7 years ago

RobertTheProfessional commented 7 years ago

Any need for a Typescript implementation of this library? I rewrote the library in Typescript for a work project and removed the try/catches and implemented Promise rather than returning functions. There have been a few updates to the library since I've rewritten it but I can get source up to speed pretty quickly.

dblock commented 7 years ago

I see people do typescript everywhere around me. I guess we should look at how much better that is vs. what we have, what problems it solves, etc. Curious what other people active in this project like @mreinstein and @tejashah88 think.

tejashah88 commented 7 years ago

While I don't normally use TypeScript on a daily basis, it would be nice to have such a library. The only issue that I foresee is maintaining similar changes between this library and the TS one.

dblock commented 7 years ago

I think @RobertTheProfessional is proposing replacing alexa-app by a TypeScript library and compile that down to JS that runs on node. I am by no means saying that's what we should do, but I find arguments in https://github.com/artsy/emission/issues/18 or https://github.com/orta/systems-theory compelling.

mreinstein commented 7 years ago

totally opinion based, but I am absolutely not interested in typescript.

RobertTheProfessional commented 7 years ago

@tejashah88 My TypeScript implementation practically mirrors the functionality of the current JavaScript implementation with a few improvements on top; but the exclusion of the AudioPlayer functionality. I can roll back a few of my specific enhancements and finish adding the AudioPlayer code to ensure that it compiles down to a near perfect match.

@dblock @mreinstein At the very least I can generate the Typings from the TypeScript implementation for the purpose of autocomplete. Personally, TypeScript with alexa-app has been a great help in the development of my larger Node-RED plugin and quick proof of concepts, since it can be converted between ES5, ES6 and ES7 by configuring the compiler options.

mreinstein commented 7 years ago

I'm certainly not going to tell you how to run your own projects; feel free to use whatever you find useful which makes you productive.

This project will never adopt typescript because:

a) the best written javascript modules are written in javascript. Transpiled source that produces js is never as high a quality as hand written, carefully tuned js written by people.

b) I believe the premise of typescript is flawed (that the only way to write large scale projects is with strong typing.)

c) I don't want to have to know both the transpiler language and the target language.

d) javascript has a much larger pool of talent to pull from.

e) I don't want an additional compile step to complicate the build process unless it provides a lot of value.

dblock commented 7 years ago

While I disagree with pretty much everything @mreinstein says above, I do think the advantages of TypeScript for a server-side node project are limited to tooling.

I'd definitely appreciate TypeScript definition for alexa-app and related in DefinitelyTyped.

tejashah88 commented 7 years ago

I agree with @dblock as far as introducing a "sister" project is concerned. However @mreinstein does bring a few good points.

What would be nice is to add that project to the alexa-js org, so that anyone that wants to work with the TypeScript version of alexa-app will have that option available. Maintaining it would be as simple as updating the library whenever alexa-app has a new version available.

dblock commented 7 years ago

I'll move any decent project related to the alexa-app ecosystem into the alexa-js org, but do note how DefinitelyTyped has become the center of where the typings go.

mreinstein commented 7 years ago

definitely fine with bringing in typescript based alexa projects, as long as they don't start impacting existing stuff (e.g., I'm not interested in massive refactorings of alexa-app, alexa-app-server, etc. for the sake of typescript interoperability.)

And I know no-one is suggesting doing this anyway. This is more about project philosophy. These modules work, they solve problems, and I'm really reluctant to make big changes for the sake of making changes. The problem it sets out to solve is "done" for the most part. I would rather we spend our time collectively making new things and (hopefully) tackling loftier problems, not revisiting these modules ad-infinum.

RobertTheProfessional commented 7 years ago

Fair enough, I'll throw the TypeScript project and Typings up in the near future and get in contact once things are stable.

Also @mreinstein There isn't really a learning curve for TypeScript, you could rename your .js to .ts and it'd work completely the same, the extra whistles on top are optional. I believe a few of your concerns would probably clear if you gave it a try

dblock commented 7 years ago

Thanks @RobertTheProfessional.

Also wanted to plug this post from my team on adopting TypeScript, React, React Native, GraphQL, Jest, Yarn, ... all in 2016 going 2017.

dblock commented 7 years ago

I am going to reopen this since it comes up again, to make it discoverable and for everyone to add their 2c.

ajcrites commented 7 years ago

@dblock re: typings, I don't think you need to use DefinitelyTyped anymore. Instead you would just include a corresponding .d.ts file in this library.

I also agree with @mreinstein on most points, but I think it is primarily opinion based. I don't see a benefit to changing the source of this library to TypeScript except as an exercise.

RobertTheProfessional commented 7 years ago

@dblock Just wrapped up my conversion from ES5 to TypeScript. I currently have the files transpiled to ES5 in the /lib folder but changing to ES6 compilation is as simple as reconfiguring the tsconfig.json file.

@ajcrites In my environment converting to TypeScript allows for extending and manipulation of the classes without having to touch the actual codebase. The main reason for this was to combat the versioning issues that would occur when new features or changes were made to the library. With extended classes I can override certain functionality without having to tinker with the source constantly. Still, everyone's use case is different.

Let me know what you think.

https://github.com/RobertTheProfessional/alexa-app

ajcrites commented 7 years ago

@RobertTheProfessional well done with this; I do like how it looks and how it is organized.

There is nothing that TypeScript is doing in particular that you wouldn't be able to do with the current implementation. If you wanted to update or extend functionality you could do so by updating properties on alexa, alexa.response, etc. directly. You could even use ES6 classes to extend from these objects ... in fact TypeScript classes could do the same thing, I think. I'm not familiar enough to know how well they would interoperate.

I do like the idea of splitting up request and others into separate files to organize things a bit, though.

dblock commented 7 years ago

I think I am with what @ajcrites says above, but I think the exercise is interesting.

RobertTheProfessional commented 7 years ago

@dblock @ajcrites Completely fair assessment! Overriding the properties of the object directly is an option but it's looking like I'm a sucker for syntactic sugar in large and complex projects. Depending on the roadmap and breaking features of this library, it may be a better idea for me to wrap this project in ES6 classes or TypeScript rather than a complete rewrite.