Open to new Collaborators (2018)

[bitinn]

(Updated 2018.10)

As node-fetch is being used in more environments, notably through package like react-native, I think it's time we add a few more collaborators to address spec compliance and various use cases: such as #437 (abort support).

The reason being: I am occupied with other projects and isn't contributing much commits lately. @TimothyGu is our biggest help but even he can't keep up-to-date with all issues alone.

If you either:

• Are interested in Fetch Spec standardization process.
• Use node-fetch in your production environment (through package like react-native, isomorphic-fetch or directly).
• Actively develop modules around node-fetch.

Please reply to let me know if you are interested in being a collaborator or even a major release maintainer.

@TimothyGu also has the npm publish right for node-fetch, I consider him the gatekeeper for v2 development, please try you best to help him out (PR, tests, answering questions).

Thanks for reading!

[ahmadnassri]

you have my sword! 🗡️

[bitinn]

@ahmadnassri I would love to add you!

Please take no offence in here: could you let me know if you actively use it in production or develop modules for it? Also hopefully you consider yourself to be semi-available for code/issue maintenance :)

[ahmadnassri]

@bitinn

no offence taken, fully understand and appreciate the pressure of responsibility for core libraries. 👍

to answer your question:

• heavily use node-fetch in production for telus.com

• semi-available, i dedicate few of weekday hours for OSS, weekends for my personal projects 😉

no real need to add me in straight away, happy to look through code/issue maintenance and clear up some of the backlogged items off yours and @TimothyGu's plates

[zkat]

I might be interested in at least partly helping with this. I'm currently working on replacing request with node-fetch in https://npm.im/pacote, and if it works out the way I hope, I'll have a pretty strong vested interest in keeping this lib in good condition.

I'm thinking of adding hookable cache support, since that's pretty important for my use case. :) #68 has some good ideas in it that I might try my hand at implementing.

[bitinn]

@zkat Thx! It would be very cool to have some inputs from module developers, let me know if you do manage to replace request smoothly :)

On the subject of hookable caching, Timothy seems to have a similar idea, see if #229 (comment) is what you have in mind?

[devsnek]

@bitinn I would love to contribute in the future.

I use node-fetch in discord.js which gets a fair bit of usage, and I have abstracted it in my own snekfetch package.

I think my main prerogative would be making this module have more extendability, like exposing streams and whatnot

P.S. i would also like to drop babel, just because imo it isn't very necessary, but i will completely understand if you guys don't want to do this.

[zkat]

I'm working on an subresource integrity patch. Code's written but I gotta figure out how streams are dealing with errors. node-fetch seems to drop errors on the floor for piped streams? :\ anyway I'll figure it out, and I figure since subresource integrity is pretty standard, it's fine to use my ssri lib for it. That's what make-fetch-happen is using for its own integrity support.

[bitinn]

node-fetch seems to drop errors on the floor for piped streams?

This is probably not a good thread for it. But as far as I know all stream related error should be catchable with catch.

[bitinn]

@GusCaplan Thx for letting us know!

I think my main prerogative would be making this module have more extendability, like exposing streams and whatnot.

I think we talked about it before, I am not sure which part you are referring to, but we will answer that in another thread.

[bitinn]

Hi all,

If you are still interested in contributing and maintaining releases of node-fetch, please reply to let me know. I will add you as a GitHub collaborator and/or npm package owner.

I should note that maintaining node-fetch is no easy feat, Fetch Spec constantly changes, often in a breaking manner.

Also, I am sorry to say that I won't be driving 2.x releases as I am occupied with other projects; I haven't touched Node.js in the last 6 months, which made my already stone-age knowledge of modern JavaScript even more outdated.

Personally, I haven't had a good reason to use 2.x because I was satisfied with 1.x releases. So I am looking for some capable hands to deliver the more spec compliant 2.x that many developers always wanted.

Last but not least, I thank @TimothyGu for putting so much efforts in this library. But even his time is limited, evidently, we haven'd had a release of 2.x since January.

Sorry for the spam! But if you are in on the node-fetch 2.x train, and are happy to work with a changing spec and wildly different use-cases (From Facebook to the company behind Monument Valley), let me know!

All the best,
David Frank

[fxfactorial]

Where in RN is node-fetch used? For the packagers?

[jkantr]

@bitinn I do use node-fetch in more than one critical top-level application in production (directly), and also frequently use it as my go-to http client abstraction when tutoring others on general Node.js concepts, so I have pretty complete experience with using the majority of node-fetch's features and functionalities.

I have limited experience at the 'library' level of development but in general I think I'm comfortable with mucking about the codebase as it stands and managed to write a PR with working tests (with Timothy's handholding) for a feature improvement recently.

So I'm willing to help out with future maintenance if I can be used.

[bitinn]

@jkantr Thx Jared! I have seen you working with Timothy, so I am happy to add you to our collaborator team.

Issues with pending pr labels are some good places to start:

• They have clear objectives.
• I consider them to be easier, because they are less controversial and require smaller changes.

[jimmywarting]

I would like to be a collaborator (or more precise: a moderator)

• Editing others comments for the better.
• Fixing syntax highlighting (improving their posts)
• Maybe closing other issues/PR.
• Labeling issues/PR

Not looking for making any code changes

[bitinn]

@jimmywarting Thx, I have added you.

A few thing I would love some help on:

• Reviewing issues/PRs.
• Readme rewrite (simplify where we can and better doc structure for new users).

(If you change others' comment please make sure you leave a note there, cheers!)

[gr2m]

Hi there, I’m the maintainer of the JavaScript Octokit, GitHub’s official JavaScript tools to interact with their API. I recently migrated @octokit/rest to use node-fetch (https://github.com/octokit/rest.js/pull/764).

I’m no expert with the fetch spec but I’m sure I can help out with investigating problems that people run into, some of which I expect to be Octokit users :)

I maintain several other Open Source projects such as nock, semantic-release and Hoodie and am happy to help make and keep the project easy to maintain and contribute to.

One thing I would suggest is to move it into its own organization, so we have more people manage people who can contribute to the project and be able to give more granular access.

[bitinn]

@gr2m Welcome to the team, both of your PRs are nicely done!

About the org change, I know you have raised it in Twitter DM, however I remain unconvinced for now:

• I personally didn't intend for node-fetch to grow very large (still below 500 lines in codecov and with 0 dependency), or have many de facto sub-modules (like koa).

• Granular access control, like linting I personally think it's one of those things the devs care more than the users. Unless we have a strong case, I think having Timothy holding control to npm publish right is good enough?

If you are into more discussion or other members have bigger goal, let's take it to another issue?

[garthk]

G'day! I'm a senior engineer for Anditi consolidating all our outbound request patterns around fetch, and recently published fetch-hooks so I can also fetch data:, file:, s3:, and other URIs. If you're open to PRs to make parts of node-fetch easier to re-use from other code, or to fix all text() from stream bodies being decoded as UTF-8 regardless, I'm open to filing one or two.

[bitinn]

We are definitely open to idea for plug-in to hook into node-fetch, there were a previous PR on that but closed because we couldn’t decide on the best approach. You might want to open a new issue for this discussion first. As for how far we agree to decouple, I think it depends, for example text() will only decode UTF-8, that’s a spec requirement, and you might work with textConverted API instead (to be honest, I think you are better of working with res.body stream, because node-fetch is not designed to handle everything, and working with a stream gives you more control) When I think of plug-in I mostly think of things like a cookie store that hook into fetch process somewhere, say, on response resolve. You might think of a good way to hook your custom protocol support before request too. My goal is to keep node-fetch lightweight so please also take that into account. (From my phone)

…

On Mar 21, 2018, at 12:12, Garth Kidd ***@***.***> wrote: G'day! I'm a senior engineer for Anditi consolidating all our outbound request patterns around fetch, and recently published fetch-hooks so I can also fetch data:, file:, s3:, and other URIs. If you're open to PRs to make parts of node-fetch easier to re-use from other code, or to fix all text() from stream bodies being decoded as UTF-8 regardless, I'm open to filing one or two. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bitinn]

closing in favor of #567