Update version detection

[unional]

Spawn from #8 (comment)

Objective

• Determine if the installed typings need to be updated or not

Variables

• semver range
• semver and non-semver
• npm registry or typings/registry

Scenario 1: current

1. User installed npm:domready@a.b.c
2. Look for "a.b.c": "http://...#SHA1"
3. Install typed-domready@SHA1 // Can't help to use name typed-domready instead of npm-domready 😏
4. User update npm:domready@p.q.r
5. Look for "p.q.r": "http://...#SHA2"
6. Install typed-domready@SHA2

Scenario 2: with semver range + typings/registry

1. User installed npm:domready@a.b.c
2. Look at npm/domready.json // TODO: Need better example than A-D

{
  "versions": {
    "A": "...SHA1",
    "B-C": "...SHA2"
    "^D": "...SHA3"
  }
}

a. Read versions in reverse order, assuming later version is newer.
b. Get and use first matched version
3. Same
4. Same
5. Same
6. Same

Known problems to solve

• semver range intersection

[blakeembrey]

So, updates are easy enough. The hard part is deciding what constitutes an update. I'm tempted to push toward the easy solution, which is the new scheme we've described as the install command. E.g. npm!domready. When it lands in typings.json, we append the tag we installed at: npm!domready#1.0.8+20160211010015 (which I've already made the relevant changes to the API to handle this today). Now, we just add support for resolving that scheme to the registry first, source second, when installing. My only reservation on this is registry uptime - right now I've had about 10 minutes down time in the last week but that doesn't block builds, changing this will.

The other options are (1) creating a lookup entry that basically reverses the installation source and then does what's described above or (2) doing a resolution using the relevant APIs for updates (E.g. ask GitHub for later commits. 2 is tough and a lot of work, 1 is nicer but could be confusing. I still prefer option 0 above, but that's my thoughts right now.

Edit: All this ignore semver ranges right now. Opted to defer that for later. If ranges ever are used, the registry scheme will likely change to match.

[unional]

(1) sounds familiar. I think jspm did something similar. Need citation. 😄

[unional]

btw, just for reference (as it might help in this context). jspm differs from npm in the following:

// package.json
{
  "jspm": {
    "dependencies": {
      "bluebird": "npm:bluebird@^3.1.1"  // distribution-channel, package name, and semver range
    }
  }
}

// jspm.config.js
{
  map: {
    "bluebird": "npm:bluebird@3.1.1",  // mapping
    "npm:bluebird@3.1.1": {  // dependency
      "process": "github:jspm/nodelibs-process@0.1.2" // mapping of dependency
    },
    "github:jspm/nodelibs-process@0.1.2": { // dependency
      "process": "npm:process@0.11.2"  // mapping of dependency
    },
  }
}

# folder structure
+ jspm_packages
  + npm
    + bluebird@3.1.1
      + ... package content
    + bluebird@3.1.1.js  // redirection file

// jspm_packages/npm/bluebird@3.1.1.js

// Path is based on the `main` field in `bluebird/package.json`
module.exports = require("npm:bluebird@3.1.1/js/browser/bluebird.js");

[blakeembrey]

Yes, I think I've been stealing the API look from JSPM and tweaking to fit Typings needs - which change slightly as we want highly specific versions and have two "schemes" concurrently (well, the registry could actually be it's own scheme). However, they don't actually need to do the reversal or updates at all, since they're supported by the target consumption sources (E.g. NPM/GitHub) and they are 1-to-1. Typings isn't 1-to-1 with the sources (maybe that's a mistake, can't know yet still).

So the final thing around installation/update is the official syntax. We could expand npm!domready into registry:npm/domready#1.0.8+20160211010015, which registry: is now just another scheme to resolve over - I feel like having that doesn't give any advantage though. Thoughts on how the registry is persisted?