Publish to npm?

[ericelliott]

Because npm is the closest thing we have to a standard module repository for JavaScript (including the client-side). It's the largest module registry of its kind for any language. There are about 1/5th as many Bower modules as npm modules.

If that's not convincing enough: http://browserify.org/articles.html

[jeffchan]

👍

[matthew-andrews]

In the mean time there is a workaround for people who want to use fetch with browserify:-
#1

[ahutchings]

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

[jonathanong]

there's already https://www.npmjs.org/package/fetch, so you would have to rename it something else. maybe window.fetch

[ericelliott]

or fetch-polyfill?

[matthew-andrews]

w3c-fetch? like w3c-blob or w3c-xmlhttprequest

[jonathanong]

it's a whatwg spec tho...

[zeke]

cc @andris9, author of https://www.npmjs.org/package/fetch

[andris9]

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

[zeke]

Nice! Who wants to be an owner on the npm package? This is how @andris9 would add you:

npm owner add josh fetch

[tracker1]

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.

[ericelliott]

👍 for npm scripts. =)

[tracker1]

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.

[monkindey]

Can I use npm? It doesn't work

[benlesh]

👍 - 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.

[zeke]

@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.

[josh]

In the not too distant future, you'll be able to publish to @blesh/fetch.

@zeke oh nice!

[matthew-andrews]

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

[necolas]

Still plans to do this?

[matthew-andrews]

@necolas Have you tried npm install isomorphic-fetch?

[necolas]

Please can you npm-ignore the examples and test directories when this is published to npm.

[ericelliott]

@necolas That's a bad idea. They should be devDependencies.

[necolas]

@ericelliott I don't know what you think I wrote.

[rauchg]

What's the status on publishing this? :)

[josh]

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.

[necolas]

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.

[dgraham]

Does node.js support XMLHttpRequest, though?

On Dec 24, 2014, at 9:46 AM, Nicolas Gallagher notifications@github.com 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.

[necolas]

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.

[ericelliott]

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.

[ericelliott]

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.

[josh]

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.

[josh]

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.

[domenic]

I still think this exact repo should be published to npm. npm is a great way to install polyfills.

[ericelliott]

@domenic 👍

[josh]

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.

[josh]

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.

[matthew-andrews]

@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

[hawkrives]

@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.

[matthew-andrews]

@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.

[hawkrives]

Ah.

[necolas]

the fetch package name was offered to you -> #9 (comment)

[matthew-andrews]

Thanks @necolas for the reminder… I've put a note in the PR: #57

[matthew-andrews]

@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.

[hawkrives]

@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!

[tracker1]

@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.

[matthew-andrews]

@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 :).

[ericelliott]

Better to have a single canonical name. whatwg-fetch is fine, IMO.

[bitinn]

For people interested in a node.js implementation:

https://github.com/bitinn/node-fetch

[rauchg]

@bitinn good stuff

[josh]

@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.