Comments (56)
π
from fetch.
In the mean time there is a workaround for people who want to use fetch with browserify:-
#1
from fetch.
I needed to add "name", "version", and "main" fields to package.json in order to use fetch with browserify.
The changes are available here: https://github.com/ahutchings/fetch/blob/8a3829b6aed03f52e0589b538bc814d1b88f126c/package.json
from fetch.
there's already https://www.npmjs.org/package/fetch, so you would have to rename it something else. maybe window.fetch
from fetch.
or fetch-polyfill?
from fetch.
w3c-fetch? like w3c-blob or w3c-xmlhttprequest
from fetch.
it's a whatwg
spec tho...
from fetch.
cc @andris9, author of https://www.npmjs.org/package/fetch
from fetch.
I'm willing to give up the npm name fetch
as I have no plans to update/upgrade the current module. You'd just have to use versions starting from v1.0.0 to not break the scripts using v0.x
from fetch.
Nice! Who wants to be an owner on the npm package? This is how @andris9 would add you:
npm owner add josh fetch
from fetch.
Since fetch
is already taken, I think whatwg-fetch
would work...
Also, switching from make to use the npm scripts (via the scripts in the package.json) would be nice.
from fetch.
π for npm scripts. =)
from fetch.
note, it should also have a module.exports conditional check in the main module itself.
if (typeof module !== 'undefined' && module.exports) {
module.exports = fetch;
}
should be exported regardless of if the shim is applied.. this way it can be used as a straight module in the rest of the code.
from fetch.
Can I use npm? It doesn't work
from fetch.
π - Too bad "fetch" is already taken. I really think npm packages should have been namespaced somehow. Maybe using the organization that created the package for example "github/fetch" and "andris9/fetch". Oh well, hindsight and whatever.
from fetch.
@Blesh the name is taken, but the author offered to give it up. See above comments.
To your point about namespaces:
- npm supports installation directly from github, so you can
npm install github/fetch
today and it will pull from github - npm, Inc is working on scoped modules. In the not too distant future, you'll be able to publish to
@blesh/fetch
.
from fetch.
In the not too distant future, you'll be able to publish to @blesh/fetch.
@zeke oh nice!
from fetch.
Hi all, I've made a little wrapper that allows fetch to be used in Node & Browserify called isomorphic-fetch
(and it's published on NPM registry with that name). https://github.com/matthew-andrews/isomorphic-fetch
from fetch.
Still plans to do this?
from fetch.
@necolas Have you tried npm install isomorphic-fetch
?
from fetch.
Please can you npm-ignore the examples and test directories when this is published to npm.
from fetch.
@necolas That's a bad idea. They should be devDependencies
.
from fetch.
@ericelliott I don't know what you think I wrote.
from fetch.
What's the status on publishing this? :)
from fetch.
I think someone else should just fork this and maintain whatever npm/browserify differences and publish to npm. I'll link it up from our README.
from fetch.
If you remove private:true
and publish as-is, it will work as a client-side polyfill for most use cases via an unassigned require('fetch')
. This is how we're using it, following a direct install of the repo (npm install github/fetch
) and using exact git-tags for versioning.
from fetch.
Does node.js support XMLHttpRequest, though?
On Dec 24, 2014, at 9:46 AM, Nicolas Gallagher [email protected] wrote:
If you remove private:true and publish as-is, it will work as a polyfill for most use cases via an unassigned require('fetch'). This is how we're using it, following a direct install of the repo (npm install github/fetch) and using exact git-tags for versioning.
β
Reply to this email directly or view it on GitHub.
from fetch.
Well, you've said you're only interested in providing a client-side polyfill. You can already install this module via npm, just not via a package name and not using a version range.
from fetch.
Does node.js support XMLHttpRequest, though?
This question isn't really relevant to the usefulness of fetch in npm. There are a very large number of browser-only packages in the npm repository, and that's fine. npm is the repo for all things JavaScript. It's 5 times the size (and usefulness) of the bower registry. Lots of people use it mostly for client-side work with Browserify.
from fetch.
Hi all, I've made a little wrapper that allows fetch to be used in Node & Browserify called isomorphic-fetch (and it's published on NPM registry with that name). https://github.com/matthew-andrews/isomorphic-fetch
π
from fetch.
Ideally, the same codebase and API would run in Node.JS and the browser, with the exception that no global would be exposed in Node.JS. The functionality could be backed by request
directly, or by using node-xmlhttprequest
and making a few other tweaks to try to reuse most of the codebase. It doesn't really matter to me as long as the API is the same.
For the browser, like @necolas mentioned, just having the current codebase in NPM would be highly helpful.
In general, for polyfill projects on NPM I prefer they never touch globals directly. One could do something like:
window.fetch = require('fetch');
from fetch.
from fetch.
@rauchg Expanding on that, I wrote an ugly little wrapper around this polyfill that stops it touching window
. It is a function that takes Promise
and XMLHttpRequest
constructors as arguments to return a fetch
function. You could feed it node-xmlhttprequest
to get the result you want in Node. That said, it would be better for this library just not to touch window
. The wrapper uses a new Function
, which I'm not happy about.
from fetch.
I dig it!
from fetch.
To expand, I think it's a very good idea to expose a function that returns the fetch
polyfill, especially in Node.JS.
The main reason is that we'd have to start adding non-standard properties to the object passed to fetch
for the inevitable need of more flexibility and configurability. Things like custom SSL options, a different Agent
object, etc.
From a practicality standpoint, however, I wonder if it makes sense to pass the XMLHttpRequest
instance though.
One reason is that node-xmlhttprequest
already exhibits the lack of customizability mentioned above. I reported it to them here, because we use it extensively in engine.io-client and socket.io-client.
Their interim solution is to configure a single XMLHttpRequest
class globally, which is not ideal if several instances with different options need to co-exist.
Maybe it's better to abandon the idea of sharing the code that depends on XMLHttpRequest
, and internally use mikeal/request
for node. The options passed to require('fetch')()
are then passed onto mikeal/request
.
All in all, what's important is that require('fetch')()
has the exact same API as the spec, in both environments.
from fetch.
Maybe it's better to abandon the idea of sharing the code that depends on XMLHttpRequest, and internally use mikeal/request for node.
π
All in all, what's important is that require('fetch')() has the exact same API as the spec, in both environments.
Agreed.
from fetch.
The main reason is that we'd have to start adding non-standard properties to the object passed to fetch for the inevitable need of more flexibility and configurability. Things like custom SSL options, a different Agent object, etc.
Exactly why all this would be better done in a separate library that targets node.js directly rather than building on top of XHR.
from fetch.
I think I'm just going to close this issue out.
This repo is going to remain a browser polyfill assuming a browser environment.
Definitely checkout https://github.com/matthew-andrews/isomorphic-fetch and maybe they'll be a node-fetch build on top of node's http lib. I'd be happy to link those up in the readme.
Thanks.
from fetch.
I still think this exact repo should be published to npm. npm is a great way to install polyfills.
from fetch.
@domenic π
from fetch.
We'll definitely need an alt name on npm since fetch is taken. Hopefully something makes it clear that require('fetch')
will not will in node.js.
from fetch.
Also pro if someone could setup travis' npm releasing http://docs.travis-ci.com/user/deployment/npm/ so I don't have to be bothered forgetting the extra step.
from fetch.
@josh, I've made a tool npm-prepublish that allows you to use GitHub releases & npm publish via Travis together seamlessly.
the way it works is you first remove the version
property from package.json
then run npm install --save-dev npm-prepublish
and set up the travis.yml
file so that it will do an npm publish
with npm-prepublish
as a before_deploy
script (which puts the version number from the tag into the package.json
) [all this is documented poorly βΒ sorry, I will improve βΒ on npm-prepublish
's repo].
Basically, you don't have to do the irritating/easy to forget npm version blah && git push && git push --tags && npm publish
dance.ust go to github, create a github release and the rest will just work.
Here's a worked example:-
Financial-Times/n-express@v2.2.1...v2.2.2
from fetch.
@matthew-andrews Travis also has a feature to push a new NPM release whenever there's a new git tag automatically.
I should be able to submit a pull request for that later today.
from fetch.
@hawkrives I use that. The problem is if you use the default Travis/npm approach you can't use GitHub releases otherwise the version number in package.json
and the version in the git tag
drift out of sync, you must use npm version
on the command line to update the version
property in package.json
.
My module eliminates this unnecessary step and requirement to release via the command line.
from fetch.
Ah.
from fetch.
the fetch
package name was offered to you -> #9 (comment)
from fetch.
Thanks @necolas for the reminder⦠I've put a note in the PR: #57
from fetch.
@hawkrives I owe you an apology. It turns out they were happy with the edit-package.json-and-bower.json-update-the-version-number-git-tag-git-push---tags workflow after all and that the changes you described were exactly what they wanted. I'm sorry for discouraging you from making a pull request that did that.
from fetch.
@matthew-andrews No worries. Your take, and the ensuing thread, cleared up some good ambiguities; I apologize for being slightly short with you.
Also, that's an epic hyphenated word in that post. Keep up the good work!
from fetch.
@josh how about browser-fetch-polyfill
or browser-polyfill-fetch
?
Being explicit in that it's a browser polyfill for fetch in the naming... regarding publishing to npm.
from fetch.
@tracker1 it's published now as whatwg-fetch
. We could publish it twice under two different names but if that works for you it would be simpler to keep it as it is :).
from fetch.
Better to have a single canonical name. whatwg-fetch
is fine, IMO.
from fetch.
For people interested in a node.js implementation:
https://github.com/bitinn/node-fetch
from fetch.
@bitinn good stuff
from fetch.
@bitinn nice! I was waiting for someone to write just that. Mind opening a PR to cross link it from our README? I totally think anyone wanting to use fetch in just node.js should be using your lib instead.
from fetch.
Related Issues (20)
- π’ π Weβve made some exciting improvements to our [REST API documentation](https://docs.github.com/en/rest) and we'd love to know what you think about the new layout! Let us know π HOT 1
- Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the [contributing guidelines](https://github.com/github/docs/blob/main/CONTRIBUTING.md). HOT 1
- This repository is moving from the github org HOT 2
- Owner [email protected]
- 2018 license appachie com [email protected]
- Refused to get unsafe header "set-cookie"
- Owner
- changelog is missing for latest releases HOT 1
- File fetching broken since commit 0c1d2b9 HOT 3
- Create a Security Policy HOT 1
- Enable OpenSSF Scorecard Action HOT 3
- `Set-Cookie` headers should not be combined / Support `Headers.getSetCookie()` method
- Hash pin actions used on workflows and enable depenadabot
- code is working in chrome, not in firefox HOT 2
- Overriding feature detection HOT 2
- suggestion to use str.indexOf(searchString) === 0 for better compatibility HOT 2
- UMD Releases don't exist HOT 1
- Linkedin uses status code 999 which leads to RangeError HOT 4
- Response does not resolve until body fetched
- Response.body is always undefined HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fetch.