Apollo-server: Error when reading typedef from file in V2.6.6
Package Name & Version
The issue is present in apollo-server-express, the latest version (2.6.6).
Latest version where the problem did not occur
My previous version was 2.6.3
Expected Behavior
gql schema can load from file
Actual Behavior
The following fatal error occurs
TypeError: Cannot read property 'some' of undefined
Repo demonstrating the problem
https://github.com/ais-one/apollo-express-test
It's a simple example showing how to replicate the problem
ais-one
All 4 comments
Yeah - This just broke production. This has happened a few times now with Apollo Server. We can't trust minor version bumps at all. Going forward we'll be locking down versions.
TheKidCoder
on 26 Jun 2019
Maybe is this problem => https://github.com/apollographql/apollo-server/pull/2924
mrsunboss
on 26 Jun 2019
jesstelford
on 26 Jun 2019
Thank you @mrsunboss for tracking down the issue and opening the appropriate PR to fix the problem. This subtle but positive triaging, linking and fixing is well received and great for the project, so thank you!
This was introduced by an unguarded property access in https://github.com/apollographql/apollo-server/pull/2762. TypeScript offers us a lot of protections, and seemed to indicate that there was nothing to worry about, but TypeScript is still is no substitute for defensive coding.
Tests help protect all involved here, both on our side, and on the side of our consumers — who should, as a best practice — have integration tests in place to make sure their production expectations and needs are met.
On top of @mrsunboss's #2924, I've added a regression test for this in 32deb9f667a90fcedad5acc22ddb1270cf228a40, a further defense for another explored possibility in 490c93a3ff3335dad5ebd008ebfba7f44ce1dbb1 and updated the ApolloServer constructor types with 77207ffadef1a3cfe3fc164e9a42a3b492974efd, which was _ultimately_ most at fault for allowing this regression to occur, since JavaScript users do still pass string typeDefs (those not wrapped with the gql tag) as a matter of historical fact.
I'll release 2.6.7 soon with the fix.
abernix
on 26 Jun 2019
Related issues
veeramarni
·
3Comments
Magneticmagnum
·
3Comments
dupski
·
3Comments
stevezau
·
3Comments
jminz
·
3Comments
Most helpful comment
Thank you @mrsunboss for tracking down the issue and opening the appropriate PR to fix the problem. This subtle but positive triaging, linking and fixing is well received and great for the project, so thank you!
This was introduced by an unguarded property access in https://github.com/apollographql/apollo-server/pull/2762. TypeScript offers us a lot of protections, and seemed to indicate that there was nothing to worry about, but TypeScript is still is no substitute for defensive coding.
Tests help protect all involved here, both on our side, and on the side of our consumers — who should, as a best practice — have integration tests in place to make sure their production expectations and needs are met.
On top of @mrsunboss's #2924, I've added a regression test for this in 32deb9f667a90fcedad5acc22ddb1270cf228a40, a further defense for another explored possibility in 490c93a3ff3335dad5ebd008ebfba7f44ce1dbb1 and updated the
ApolloServerconstructor types with 77207ffadef1a3cfe3fc164e9a42a3b492974efd, which was _ultimately_ most at fault for allowing this regression to occur, since JavaScript users do still pass stringtypeDefs(those not wrapped with thegqltag) as a matter of historical fact.I'll release 2.6.7 soon with the fix.