Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert index.js to TypeScript #35

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

pbalaram
Copy link

With these changes, we can now use ES7 features.

class CloudSpeechRecognizer {
    constructor() {
        // code here
    }
}

I figure this might help keep things organized, as the codebase grows.

Bonus: You can now run examples/example.js by running the following.

npm run example

.babelrc Outdated
@@ -0,0 +1,3 @@
{
"presets": ["es2015", "stage-0"]
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ashishsc
Copy link
Collaborator

Thanks for the PR! This looks great, but I think we don't need classes. I'd rather move to using typescript and interfaces. That way we can get all the es7+ features and avoid classes

@pbalaram pbalaram force-pushed the master branch 2 times, most recently from 9f8d3e5 to 54f1c89 Compare February 27, 2017 02:11
@pbalaram
Copy link
Author

Sure, TypeScript makes sense. I've converted the core library to use it.
I'm not sure why we would avoid classes, would you mind explaining a bit further?

@pbalaram pbalaram changed the title Enable ES7-style code, using babel Convert index.js to TypeScript Feb 27, 2017
@evancohen
Copy link
Owner

Frankly I could go either way on this, but @ashishsc has strong feeling about code style that I typically defer to. Regardless, the one change I would request is that you include a prepublish script in package.json using

npm run build

That way I never accidentally publish the npm package without building the library first :)

@@ -32,6 +34,8 @@
"stream": "0.0.2"
},
"devDependencies": {
"eslint": "^3.7.0"
"eslint": "^3.7.0",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we'll need tslint instead now.

@ashishsc
Copy link
Collaborator

Thanks for converting to typescript! we <3 you.

As far as I why I don't prefer classes. I like being able to pass the sonus object in as an easy way to mock the methods. Also this will be a breaking change.

However, I come from a functional programming background (internal state makes things harder to test, not that we have any) but @evancohen has more object-oriented experience so since he's fine with classes, by all means we should go with that.

@pbalaram
Copy link
Author

Thank you for the feedback!

@evancohen I've added a prepublish step, which should call npm run build.
@ashishsc I've added tslint, fixed the trivial warnings, and added rules for the more widespread ones.

Copy link
Owner

@evancohen evancohen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. @ashishsc what say you?

}

public pause() {
this._mic.pause();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry one last change, we don't use semicolons, so if you could add the tslint semicolons:never rule, that would be sweet = ) https://palantir.github.io/tslint/rules/semicolon/

Nice job on this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be happy to add this, but I'm curious as to why this is the preference -- would you mind explaining a bit further?

If I understand correctly, the TypeScript compiler automatically inserts semi-colons where they are omitted in the TS source, yielding compiled JS output that always has semi-colon delimited statements.

This in turn introduces the possibility of issues such as microsoft/TypeScript#2575, where it's possible for the automatic insertion to adversely affect the runtime behavior of the code at hand.

Since this is the case, would it make more sense for us to avoid the risks, and require semi-colons?

For reference, this is also the recommended behavior from the TSLint recommended configuration.

https://github.com/palantir/tslint/blob/master/src/configs/recommended.ts

Thanks!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah didn't realize that TS had these issues! Yes we should totally try and protect against these cases. LGTM in that case.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although, it does look like they addressed that issue?microsoft/TypeScript#4788

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct! They did resolve this particular issue, my intent was simply to suggest that we might be able to avoid this class of issues entirely by keeping semi-colons mandatory.

@ashishsc
Copy link
Collaborator

ashishsc commented Mar 27, 2017 via email

@evancohen
Copy link
Owner

evancohen commented Apr 27, 2017

Hey folks! I want to get this merged, but things were left in a bit of an ambiguous state. @ashishsc are we good on the linter settings?

@ashishsc
Copy link
Collaborator

ashishsc commented May 4, 2017

I'm good with what we have currently, we can always change it later. We should just use an autoformatter and reduce bikeshedding at some point. Once pretter finishes their TS support, I'll add that in here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants