Resubmitting #318

[Martii]

• Show the raw npm ls JSON data for the server

Applies to #296

This appears to be the only way it can be done for listing the current dependencies. I haven't found any native API to Node.js that does this... so I'm willing to give this a whirl.

[cletusc]

var pkg = require('./package.json');

pkg.dependencies.forEach(function (dep) {
  // tada
});

We should really be using actual version numbers for our dependencies rather than *. Right now any of our deps can update (to a potentially breaking release) and we are screwed. If we use version numbers, there is no need for npm list for versions and you could just use the above code.

[Martii]

pkg.dependencies.forEach(function (dep) {
// tada
});

Let's try it the merged way first. I'd like to the see the output first and then we'll see if manually hunting in each package is a viable option. This already considered method probably won't cover GitHub references either since those sometimes don't have package.json files in them (then I may get to do $ git rev-parse --short HEAD but I doubt that's on our drones but I could be wrong). ;) ... and that's aDep with a twist of aDependency for those wanting explicit naming. :)

---

Who knows if anything gets shifted/modified too. Saw a few properties locally that weren't in their respective package.json files too. I had no clue that the version was appended with a deploy release number until we all saw it.

---

We should really be using actual version numbers for our dependencies rather than *.

Well let me dig up a popular package, say `async', and I'll post what their package.json is like:

{
  "name": "async",
  "description": "Higher-order functions and common patterns for asynchronous code",
  "main": "./lib/async",
  "author": {
    "name": "Caolan McMahon"
  },
  "version": "0.9.0",
  "repository": {
    "type": "git",
    "url": "https://github.com/caolan/async.git"
  },
  "bugs": {
    "url": "https://github.com/caolan/async/issues"
  },
  "licenses": [
    {
      "type": "MIT",
      "url": "https://github.com/caolan/async/raw/master/LICENSE"
    }
  ],
  "devDependencies": {
    "nodeunit": ">0.0.0",
    "uglify-js": "1.2.x",
    "nodelint": ">0.0.0"
  },
  "jam": {
    "main": "lib/async.js",
    "include": [
      "lib/async.js",
      "README.md",
      "LICENSE"
    ]
  },
  "scripts": {
    "test": "nodeunit test/test-async.js"
  },
  "readme": "*clipped for brevity since this property is huge*",
  "readmeFilename": "README.md",
  "homepage": "https://github.com/caolan/async",
  "_id": "[email protected]",
  "_from": "async@*"
}

Looking at this most popular one they don't use absolute versions.

[cletusc]

Looking at this most popular one they don't use absolute versions.

They are also using devDependencies, not dependencies. They don't rely on a dep to be distributed during install. For the deps they rely on during development, they have tests to verify behavior; we do not have tests.

I am assuming the overall goal of this is to see which version of a dep we are running, in which case we should know beforehand (by explicitly setting them).

[Martii]

in which case we should know beforehand (by explicitly setting them).

-1. This defeats the whole point of node (or any other packaging system with version control). Very rarely do I see any package.json use absolutes for any dependencies. Btw it's deployed now so you can go look. :) We can decide in team biz if we want to store any values like this to be used programmatically but I definitely wanted to see what was going on behind the curtain.

[cletusc]

This defeats the whole point of node (or any other packaging system with version control).

This defeats the whole point of semantic versioning. By specifying * as the version, that's telling npm that you'll accept anything, no matter what. Whatever is latest on npm is what you will get, this includes alpha, betas, major releases, prerelease, whatever is newest on npm. By specifying 1.* or 1.2.*, that means you are opting to get only new features or bugfixes, but not releases that can break backwards compat. As is, a PR could work today, but be broken tomorrow because one of our deps decided to release a known to break release (major) and we just accepted it.

My $0.02 is that we should be explicit with version numbers to at least the major release.

[Martii]

we should be explicit with version numbers to at least the major release.

That I could probably agree with assuming all node projects and gh projects use major.minor.build systems (I'd have to look up npm's requirements on this and also our cloudflare friends versioning is an issue that I am not particular fond of since those can be someone totally random instead of the project maintainers). Imho node is still in it's infancy so we might have a few bumps for a while. Open an issue for that and we'll see what everyone else thinks about it. :)