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

Removes reference to node typings and stubs dom interfaces #1228

Closed
wants to merge 2 commits into from
Closed

Removes reference to node typings and stubs dom interfaces #1228

wants to merge 2 commits into from

Conversation

chrisradek
Copy link
Contributor

@blakeembry
I'm only posting a few of the updated service models here since they are updated so frequently.
I removed all instances of

///<reference types="node" />

I tried to include a tsconfig.json with the SDK that specified dom in compilerOptions.lib, but I still got XMLHttpRequest (and related) errors in my test app if I excluded dom.

It looks like the route some libraries have taken is to create empty interfaces. Then, if the user includes dom the interfaces are merged. I've done this, however this also reduces the effectiveness of type-checking. Short of creating separate definitions for the browser (difficult since this is a combined project), I'm not sure there's a better way to do this.

Anyway, would love to get some feedback if you have time.

Note: The first commit has most of the changes (I reverted the streams one for now), I uploaded all the updated definitions in case anyone wanted to test against their existing projects.

@coveralls
Copy link

coveralls commented Nov 15, 2016

Coverage Status

Coverage remained the same at 88.111% when pulling f2b6348 on chrisradek:fix/typescript-config-issues into c8ecca0 on aws:master.

@blakeembrey
Copy link

Unfortunately TypeScript doesn't support browser resolution, I have an older issue in the TypeScript repo regarding this as that'd be the best solution for browser type separation. Was there an issue with the streams for now? I haven't used the SDK a ton with TypeScript, but the places you're using these types should mostly be configured based on input options right? Would it make sense to leave it semi-configurable to the user through generics to avoid the messy parts?

Now I think about it, default generic types may also be used here for narrowing the return type, but that can be an unrelated enhancement I'll comment when TypeScript supports it.

@chrisradek
Copy link
Contributor Author

@blakeembrey
Thanks for the feedback!
The stream support is fine, I just wasn't ready to include them with this PR yet, but I can update the PR with them now.

If you don't have any concerns with mocking the interfaces, I'll go ahead and push this (and the streams) change. Really appreciate the support you've given!

@jeskew jeskew closed this Mar 9, 2017
@lock
Copy link

lock bot commented Sep 28, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.

@lock lock bot locked as resolved and limited conversation to collaborators Sep 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants