Keep @types/node types at v8.
#2344
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While there are newer types available for newer Node.js APIs, the `8.x` range still gets most of the important updates. I believe it'll be safer to limit the types to the version which we intend on developing for most directly, which is Node.js 8. Node.js 10 has newer APIs but until we can drop Node.js 8 support (which is not at all anytime soon), we should try to stick to the `8.x` API types.
abernix
added a commit
that referenced
this pull request
Feb 20, 2019
Follows-up on #2344 with the appropriate changes to the `package.json` as well.
|
Also, see 0f75909. |
abernix
added a commit
that referenced
this pull request
Feb 20, 2019
…rred. This is necessary after the changes in 0f75909 and #2344, as the `AddressInfo` type didn't become available until a future version of `@types/node`. Regardless, it seems to me that this should be inferred without any problem and we don't actually rely on the `AddressInfo` type, and instead are only looking for an interface which has `port`, `address` and `family`, as the inferred return value from `http.Server.prototype.address()` does.
abernix
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
Mar 12, 2019
In the same spirit as apollographql/apollo-server#2344, this should hopefully _gently_ help us not use types which aren't available in all of the versions of Node.js which we currently target.
trevor-scheer
pushed a commit
that referenced
this pull request
May 6, 2020
In the same spirit as #2344, this should hopefully _gently_ help us not use types which aren't available in all of the versions of Node.js which we currently target.
trevor-scheer
pushed a commit
that referenced
this pull request
May 14, 2020
In the same spirit as #2344, this should hopefully _gently_ help us not use types which aren't available in all of the versions of Node.js which we currently target.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While there are newer types available for newer Node.js APIs, the
8.xrange still gets most of the important updates via back-ports on theDefinitelyTypedrepository. I believe it'll be safer to limit the types to the version which we intend on developing for most directly, which is Node.js 8. Node.js 10 has newer APIs but until we can drop Node.js 8 support (which is not at all anytime soon), we should try to stick to the8.xAPI types.We will drop Node.js 6 support in the next major version of Apollo Server since it will end its "Long-Term Support" coverage in April 2019.
Hopefully this will auto-close #2302. 😉