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

feat: remove dom dependency #108

Merged
merged 19 commits into from
May 28, 2020
Merged

Conversation

brikou
Copy link
Contributor

@brikou brikou commented Sep 12, 2018

Fix #26 supersed #100

should be merge after #107 as based on it ping @divyenduz 😛

@brikou
Copy link
Contributor Author

brikou commented Sep 12, 2018

for more information see microsoft/TypeScript#23893

@jasonkuhrt jasonkuhrt changed the title [RFR] Remove dom dependency feat: remove dom dependency May 28, 2020
Copy link
Owner

@jasonkuhrt jasonkuhrt left a comment

Choose a reason for hiding this comment

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

Thanks @brikou!

@jasonkuhrt jasonkuhrt merged commit be27ac6 into jasonkuhrt:master May 28, 2020
@schickling
Copy link
Contributor

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

jasonkuhrt added a commit that referenced this pull request May 29, 2020
closes #15
closes #26
Relates to #100
Relates to #108

This approach was originally implemented by @kallaspriit in #100.

This approach ships TypeScript types inline with this library rather
than relying on global fetch types in lib.dom.d.ts.

The benefits of this approach are:

1. It avoids consumers (direct or indirect) needing to add `dom` to
   their lib setting in tsconfig. This can be very confusing for Node
   projects and adds legitimate room for error since it allows any DOM
   globals to be used in the Node app which is almost certainly wrong.
2. The file-directive approach (see #108) fails in two ways:
    1. If consumers customize lib config but leave out `dom` things
       break just the same.
    2. It adds dom globals which is bad but now in a very
       unexpected/hidden way.
3. It aligns well with our ponyfill (not polyfill) approach.

The downsides of this approach are:

1. We aren't benefiting from improvements in the TS lib types. So
   improvements to fetch typing for example would not pass through to
   graphql-request users transparently. It would require a new release
   of graphql-request.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Close to working with TypeScript, but not quite -- Error: "Cannot find name RequestInit"
3 participants