-
Notifications
You must be signed in to change notification settings - Fork 32
Introduce apollo-fetch-polyfill package #30
base: master
Are you sure you want to change the base?
Conversation
7baac63
to
0144994
Compare
0144994
to
4542918
Compare
@ctavan sorry I missed this! I'll take a look this week! |
4542918
to
5bf97d8
Compare
Cool! I would really appreciate your feedback! I just rebased this branch against the current upstream/master. As soon as you've found the time to look into this I'm more than happy to finish up this PR, especially with respect to the test-isolation-issue and potentially adding more documentation. |
@jbaxleyiii now that Apollo Client 2.0 Beta is out, how do you want to proceed with the fetch-polyfill situation? I still believe that providing an |
Hi Guys! Please roll-out this packages. Beta version of apollo-client can't work on react-native because stuck with |
5bf97d8
to
e4b4772
Compare
@giautm I have updated this pull request to use |
@jbaxleyiii sorry for bumping this again. What holds us back from merging this? I'd be more than happy to get this into a mergeable state. I just saw that Any objections of porting the test-suite of |
e4b4772
to
8c7f6e9
Compare
3aff27a
to
8f932b3
Compare
I have update the test-suite to use jest, still have to figure out why lerna is not happy yet… |
8f932b3
to
897b2f3
Compare
Hmm, since lerna hoists the
In that case Any idea how to solve this? |
897b2f3
to
c00de71
Compare
I have set |
105461a
to
9693f44
Compare
@evans I understand you may want to discontinue to support this package. I still rebased this PR to the current master and I hope it should be good to merge. I'll leave it up to you if you want to publish this as 1.0 or not. |
7af6702
to
72e2cd6
Compare
@ctavan Thank you for rebasing! I would like to have a lightweight client that is easy to use with middleware for auth. Whether it stays |
This leads to trouble with ts-jest not being able to reliably locate the ts-jest/preprocessor.js module.
As opposed to mocha, jest runs each test file in a separate process. Therefore we no longer need to worry about the polyfill, which is included in one test, polluting the global namespace for the other test.
Drop the global isomorphic-fetch polyfill from the main `apollo-fetch` package and provide a convenience package that simply re-exports `apollo-fetch` and includes the `isomorphic-fetch` polyfill.
72e2cd6
to
411a1ca
Compare
Rebased again to resolve conflicts due to renovate bot updates. |
Drop the global isomorphic-fetch polyfill from the main
apollo-fetch
package and provide a convenience package that simply re-exports
apollo-fetch
and includes theisomorphic-fetch
polyfill.TODO:
apollo-fetch
test in isolation.See #23 for discussion.
I had a bit of trouble with the
apollo-fetch
tests: I want to simulate an environment wherefetch
is present and therefore importisomorphic-fetch
in the original tests. This has the bad side-effect, since mocha runs all tests in one process, that theno-polyfill.ts
, where I want to explicitly test the behavior if thefetch
API is not present, does not work as expected if it is executed together with theapollo-fetch.ts
test, since the environment is already polyfilled… Any idea of how to improve this situation? Maybe switch toava
(whichapollo-fetch-upload
andapollo-fetch-polyfill
already use) because it seems to have process isolation?Currently the added test is also not contained in the coverage command.
Apart from that I'm curious about any additional feedback.