Use node ecosystem

[tracker1]

Since you are already publishing to Bower, which requires node, I would suggest the following adjustments.

• Expose your shim as a module.
  • Option 1: Wrap your shim in a Universal Module Definition
  • Option 2: Use common-js (node-style), and browserify
• Replace your shell script test runner with an environment that can run from within node
  • Suggest switching from qunit to mocha
  • Have a setup and teardown script to run your server for integration tests
• For node users, have an implementation that exposes the API, but uses node's http, or a simple wrapper around request
• Replace Makefile with npm tasks that run from package.json (example below)

Example package.json for scripts

{
  "private": true,
  "name": "fetch-client",
  "version": "0.2.1",
  "main": "./fetch.js"
  "scripts": {
    "post-install": "bower install"
    "browser-tests": "./test/run.sh",
    "lint": "jshint *.js test/*.js",
    "clean": "rimraf ./bower_components ./node_modules"
    "build": "npm run clean && npm install",
    "test": "npm run lint && npm run browser-tests"
  },
  "devDependencies": {
    "bower": "1.3.8",
    "jshint": "2.5.2",
    "node-qunit-phantomjs": "0.2.2",
    "rimraf": "*"
  }
}

npm install
will follow up with bower install (npm will resolve the execution path from node_modules)

npm test
will run linting and your existing test script

npm run build
will clean and re-install

I added the rimraf to remove the dependency.

Note, if you're open to pull requests, I'd be happy to do the initial changes to remove the dependencies on tools outside of node (namely the makefile, and shell script)

[josh]

I get that node users prefer this flow, but what would be the benefit?

FWIW, browserify already works since its just a polyfill, not a module with any exported symbols.

[josh]

If anything, going in the opposite direction would be preferred to me.

We can remove the bower install dependency from the dev chain and just use curl to fetch down the polyfill scripts we're depending on. Or just check them in.

[josh]

How does the test tooling this repo uses affect you're actual application integration of the polyfill?

[josh]

Replace your shell script test runner with an environment that can run from within node

Maybe you're confused, this polyfill is for running in browser environments, not node. Which is why we want to test in PhantomJS.

[tracker1]

@josh

Honestly, my suggestions were mainly out of the fact that this is a JS project, that already needs node (for bower, phantom-js, your test environment, etc) and could, via some minor adjustments use that same environment without any need for additional tooling, and work cross platform. Windows and OSX don't have make and windows doesn't have bash without additional software... with minor adjustments you could remove those dependencies in favor of a node (already required) solution.

I'm now using browserify with most of my logic being the same for server (node) and client (browser) rendering, so tools that support both modes of operation and are published in npm are (imho) better than those that aren't. It also is a trend that is seeing a lot of growth.

[dgraham]

I'm going to close this out since it's working well so far. I appreciate the suggestion to use more node ecosystem tools, but we can rely on make being available. The development flow is pretty simple right now.