Make apollo-env a standard TS package
#1611
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
This commit removes all of the extraneous work being done for compiling apollo-env's global `fetch` types. To accomplish this, `apollo-env` was converted to a standard TS project using references, just as the other packages are implemented within this repo.
4 tasks
trevor-scheer
commented
Oct 22, 2019
abernix
approved these changes
Oct 22, 2019
| // ): Promise<Response>; | ||
| // } | ||
|
|
||
| export type RequestAgent = HttpAgent | HttpsAgent; |
There was a problem hiding this comment.
I'm not sure we use this anywhere, but I think it's okay to leave it for now.
|
|
||
| // export type RequestRedirect = "follow" | "error" | "manual"; | ||
|
|
||
| export type ReferrerPolicy = |
There was a problem hiding this comment.
I also don't think we use this anywhere, but let's leave it for now.
|
|
||
| // export type BodyInit = ArrayBuffer | ArrayBufferView | string; | ||
|
|
||
| export { |
There was a problem hiding this comment.
We could alternatively just import these directly from node-fetch, but this is a great improvement right now.
|
I'm not sure what is going on with the azure pipelines fail here... all the jobs pass. Feel free to ignore that |
I think earlier node versions may need the apollo-env polyfill. It works on my machine with node v8 but this is a CI test.
caydie-tran
pushed a commit
that referenced
this pull request
Nov 8, 2019
* Make apollo-env a standard TS project This commit removes all of the extraneous work being done for compiling apollo-env's global `fetch` types. To accomplish this, `apollo-env` was converted to a standard TS project using references, just as the other packages are implemented within this repo. * Cleanup extraneous env-ci at the top-level * Add polyfill setup step for jest * Remove unused script I think earlier node versions may need the apollo-env polyfill. It works on my machine with node v8 but this is a CI test. * Add apollo-env as a setup file for packages that use the polyfill * Remove apollo-env from swift codegen dependencies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The purpose of this PR is to simplify the build step of the tooling monorepo by implementing
apollo-envas another project reference just as the others are.apollo-envhas been a notoriously bad citizen of this monorepo, especially for developers who aren't familiar with the quirks of this particular setup. It's removed hours of productivity even for those who are well acquainted with said quirks. For example, the need for frequentnpm run clean && npm ciis really a requirement for development, but is an unexpected quirk and serious time sink - and this really just marks the simplest case.This cleans up all things
apollo-envto the best of my ability:apollo-envas a project dependency when it is unusedapollo-envbefore everything elsefetchtypesThe last bullet is a major question mark to me - as my understanding of this whole workaround is for the sake of these handwritten types. I don't see the value that they add, but I'll defer to those with more knowledge of the history here @martijnwalraven and possibly @abernix.
TODO:
*Make sure changelog entries note which project(s) has been affected. See older entries for examples on what this looks like.