-
Notifications
You must be signed in to change notification settings - Fork 572
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
Remove node-fetch
dependency from SDK, introduce @realm/fetch
and allow passing fetch
through AppConfiguration
#6401
Conversation
b429752
to
0c631da
Compare
It turned out to be pretty simple 👍 6f432ab .. I've added two tests, one with an trivial throwing implementation and another passing |
node-fetch
dependency & introduce @realm/fetch
node-fetch
dependency from SDK, introduce @realm/fetch
and allow passing fetch
through AppConfiguration
@takameyer I've requested review since I've added functionality since your initial review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great replacement here, interesting walkthru and PR!
it("is supported", async function (this: AppContext) { | ||
const app = new Realm.App({ id: this.app.id, baseUrl, fetch: nodeFetch }); | ||
const user = await app.logIn(Realm.Credentials.anonymous()); | ||
expect(typeof user.id).equals("string"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming the test interprets a successful login as "passing node-fetch works" and a failed login as the opposite, I'm thinking that testing for a non-null user may be more appropriate here (if at all needed since the login will throw if it fails). For successful logins, the id
will always be a string as far as I know 🙂
expect(typeof user.id).equals("string"); | |
expect(app.currentUser).not.to.be.null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could probably just await the login, instead of actually expecting anything of the result 🤔
The test doesn't actually verify that the fetch
provided will be used, I added another (more general) test for that. The main purpose of this is actually that I wanted to test that the type for the fetch
option would accept the node-fetch
export.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup I agree, the expect is likely not necessary for the test 👍
Co-authored-by: LJ <[email protected]> Co-authored-by: Andrew Meyer <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ship it!
… allow passing `fetch` through `AppConfiguration` (realm#6401) * Removed node-fetch and abort-controller from dependencies * Hoisted dependencies on typescript and @types/node * Started implementing a truely isometric fetch package * Removed the path alias for types * WIP * Fixed Headers types * Adding AbortSignal * Removing types project as reference in root tsconfig.json * assserting AbortSignal types and patching timeout static * Adding AbortController * Exporting Headers and returning Response * ReadableStream WIP * WIP * Deleted @realm/network-transport * Adding textStreaming config to React Native fetch requests. * Adding engines and type param to @realm/fetch * Removing network-transport from mono repo * Using @realm/fetch from "realm" * Using @realm/fetch from "app-importer" * Using @realm/fetch from "realm-web" * WIP * Ensure @realm/fetch is in the bundle of realm-web * Ensure @realm/fetch is in the bundle of realm * Use a utility to wrap response.body in an async iterator * Adding a version to @realm/fetch * Adding engines to realm-web package.json * Fixing react-native fetch implementation * Adding comments to explain the weird emits * Adding a "type-check" script to app-importer * Adding a top-level "react-native" in @realm/fetch's package.json * Prodiving a CJS + ESM node bundle * Renamed fetch script to "build" (since it doesn't bundle) * Bind fetch on node too (as this is loaded on Realm * Debugging url and init separately * Simplified types for ReactNative request init * Implemented RN polyfill for AbortSignal.timeout * Fixed setting statusText instead of status * Using AbortSignal.timeout only if timeout is positive * Adding an AnyFetch type * Enable passing "fetch" through app configuration * Passing baseUrl in the node-fetch test * Providing a fallback for Symbol.asyncIterator if transpiled using Babel * Apply suggestions from code review Co-authored-by: LJ <[email protected]> Co-authored-by: Andrew Meyer <[email protected]> * Inlining configuration.storage * Making cancel() return Promise<void> * Adding ArrayBuffer | TypedArray to RequestBody * Bumping lib of realm-web to es2022 --------- Co-authored-by: LJ <[email protected]> Co-authored-by: Andrew Meyer <[email protected]>
What, How & Why?
This fixes #6393 and makes #6367 obsolete as it removes the
node-fetch
dependency, in favour of depending on thefetch
provided by Node.js at v18 and above.It also replaces
@realm/network-transport
with a private (not to be published on NPM)@realm/fetch
package. The new package exports types reflecting the lowest common API for fetch across our supported platforms and adds platform specific polyfills to the fetch API. This will help ease exposing hooks for end-users to provide their own fetch implementation (ensuring it's easier to support a use-case like that outlined in #6159).☑️ ToDos
Compatibility
label is updated or copied from previous entryCOMPATIBILITY.md
package.json
s (if updating internal packages)Breaking
label has been applied or is not necessary