Decisions to make

[unional]

Package Discovery

• Distribution channels
  • (committed) npm
  • bower
  • github
  • jspm
  • nuget
  • apm
  • atmosphere (meteor)
• (deferred) Package name alias
  • Alias for different distribution channels vs name in registry
• Versioning
  • Semver ranges in the registry and do intersection
  • Some distribution channels are not following semver
• Server side API
  • e.g.: /versions/:source/:package/:version/latest

Typings Delivery

• Delivery System
  • npm or typings/registry
    Unified "install" #3 typings.json

.typingsrc

• per project
• per user

{
  "defaultSource": "{npm,bower,etc}"
}

Typings content

typings CLI

• typings install <identifier>
  • Default distribution channel by:
    • .typingsrc
    • implicit determine
    • typings sync

Terminology

• source vs distribution channel
• package vs module
• source as source module vs target module/package
• TypeScript terms vs Typings current terms

[blakeembrey]

Some things. I don't know if NuGet can ever be fully supported - right now we do version sorting based on SemVer and I can't see a way around it. On semver range intersections, I couldn't think about how to make this work either. Especially if we want upgrade/outdated type functionality, we need a way to order versions - which right now is done with SemVer, and we need a way to reference versions directly. If we go a non-semver route for versions, how do we know if there is actually an update? I'll give an example, but this was on my mind all day.

Example: User has [email protected]<timestamp> installed. We want to check for updates. How do we know there's a version (1) greater than the current version and (2) compatible with the current version? This needs to take into account that a bigger timestamp does not mean a newer version, since a user could have added definitions for an older version at a later date.

{
  "dependencies": {
    "debug": "[email protected]<timestamp>"
  }
}

Mostly, it comes do to how could we (1) have semantics about the version in typings.json to enable "upgrade" functionality and (2) how can we show the version is compatible. Right now, compatibility is indicated by the fact that there's no new typings.

The only thing I can think of is that we construct the version tag using the updated timestamp and the lower bound of the range automatically. Thoughts? Example: when >=6.1.0 is specified, the version would become 6.1.0-<timestamp> while the compatibility range stays the same. Then, when someone adds >=6.2.0 it would be a bigger version according to update semantics.

[blakeembrey]

On .typingsrc, it's already both per-project and per-user. The rc modules resolves up the tree automatically, so we can use that here.

[unional]

I don't know if NuGet can ever be fully supported

NuGet can handle their updates correctly, so there must be a way to do so. Maybe there are more things to read besides the version alone? nuget.json?

Once that is figured out, then mapping should be possible too. I think we can defer that until later. Just need to aware that API may need to take more than just a version number.