Skip to content
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

refactor(node): moving to native fetch #1053

Merged
merged 9 commits into from
Jul 29, 2024
Merged

Conversation

erunion
Copy link
Member

@erunion erunion commented Jul 28, 2024

🐳 Context

The amount of dependencies we use to make a fetch call to both the ReadMe and Metrics APIs is a bit off the rails right now:

  • Metrics API requests use node-fetch for the POST request to record a log.
  • ReadMe API requests use api@6 which uses not only node-fetch, by way of isomorphic-fetch, but it also uses oas, @readme/oas-to-har, fetch-har, json-schema-to-ts, but also our OpenAPI definition to make very simple GET requests to retrieve project and version data.
    • Even using api@7 wouldn't be much of a change because that still uses everything listed her but node-fetch. The complexity overhead for these two small API calls is a bit much. api@6 also uses a very old version of our oas library and the work involved to upgrade that here, without just outright moving over to api@7 is non-trivial. It's easier to move off it entirely.1

So I'm refactoring all of this away.

🧰 Changes

  • Moving Metrics API calls from node-fetch for native fetch.
    • We already only support Node 18+ so this shouldn't be considered a breaking change as fetch is readily available to us.
  • Completely ditching api for ReadMe API calls for native fetch.
    • This also allows us to remove our dependency on json-schema-to-ts.
  • Upgrading msw to the latest release as the v2 release better supports native fetch.
  • Removes our testing dependency on form-data as we have access a native FormData API.2
    • Was also able to remove our dependency on multer too because in the tests it was used it wasn't actually being used.
  • Removes our dev dependency on caseless.
    • The thing we were using it for, caseless retrieval of headers in an object, isn't necessary because HTTP headers always come back to us lowercased and we were always searching for them lowercased.
  • Moved @types/har-format to being a dev dependency as we're only using it for types and aren't exporting anything from it for external use.

Footnotes

  1. There's something to be said for dogfooding our own SDK software here but because we are unable to do so in any other SDK language, and api is unoptimized due to its design language requiring consulting an OpenAPI definition before every request IMHO it's not worth it for something as mission critical as our Metrics SDKs.

  2. Not to mention one that actually follows the FormData spec. Don't get me started...

@erunion erunion added enhancement New feature or request refactor Issues about tackling technical debt node Issues related to our Node SDK labels Jul 28, 2024
@@ -1,4 +1,4 @@
import type { GroupingObject } from '../../src';
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GroupingObject doesn't exist in src/index.ts!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

went through and made a bunch of type fixes in #1056

Comment on lines -17 to -19
// We have to explicitly list these config files
// due to the dynamic require in certain envs
"src/config/*.json"
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We haven't had any JSON files on src/config for a very long time.

@erunion erunion marked this pull request as ready for review July 28, 2024 06:43
@@ -1,4 +1,4 @@
import type { GroupingObject } from '../../src';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

went through and made a bunch of type fixes in #1056

## 🧰 Changes

Noticed a bunch of type errors when running `npx tsc -p test/` from the
`packages/node` directory. Not sure if we should do this typechecking in
CI?

## 🧬 QA & Testing

Do you notice any errors when running `npx tsc -p test/` from the
`packages/node` directory?
@erunion erunion merged commit ec05260 into main Jul 29, 2024
41 checks passed
@erunion erunion deleted the feat/native-fetch-support branch July 29, 2024 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request node Issues related to our Node SDK refactor Issues about tackling technical debt
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants