Publish to npm? about fetch HOT 56 CLOSED

👍

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.

@rauchg See #46.

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.

@qubyte

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.