Issue 1:
There should be a way to add typings for specific version of ts(e.g. 2.1). The tests should run on ts 2.1 and packages should require typescript 2.1 in their package.json.

So what is the best way to do it?

Issue 2:
It makes sense to not want to break existing users with a "^" dependency on something like @types/react, but it hinders the very users and organizations that help the TS ecosystem. The introduction of Partial<> and co in particular is a big game changer, and many users would benefit from updates to react and lodash in particular.

The current policy has been stated as waiting 30 days before allowing new features into DefinitelyTyped to avoid breaking people. While I disagree with the policy, I think it we as a community can do better to support those on the bleeding edge.

Considering the situation, I'd like to propose a few options.

Option A, do nothing. There are work arounds if you want to start moving fast, such as hacking paths and typeRoots in your tsconfig. I have documented one such solution here: https://medium.com/@ericlanderson/using-custom-typescript-definitions-with-ts-2-x-3121db84015d#.tvqw3rmth

While this works, its a hassle.

Option B: Someone (maybe me) forks DefinitelyTyped and allows changes for the latest and greatest right away. I could publish this as something like "types-edge" in npm and provide documentation for how to configure your tsconfig to allow for it to work.

While this works, it half forks the community, and creates a burden on myself to keep up to date with DefinitelyTyped. It also hinders discoverability. I think this hurts the ecosystem, but its better than everyone manually forking type definitions.

Option C: DefinitelyTyped and Microsoft support the development of these edge versions on a branch within DefinitelyTyped (lets call it "edge" or even use "master"). Microsoft could then register the org @types-edge and publish the edge branch. The DefinitelyTyped and Microsoft people could then as a group keep merging types-2.0 (which should really be called "stable" in this world) into edge, while allowing the community to grow and move quickly. If desired, there could also be a "nightly" branch and a corresponding @types-nightly (I would have personally liked this as the second Partial<> and keyof got merged, I started using it immediately). This would also mean the types are already being updated and ready to go when the next TS release happens.

There could also be a release of typescript 2.1.1 pretty quickly that adds "./node_modules/@types-edge" to the default list of for the paths and the typeRoots in tsconfig.

I think this is the best short-term solution.

Option D: Add macros to TS. (Yeah this is dirty). But the macros could allow things like #if typescriptVersion >= 2.1.0 and allow additional definitions to be placed into the type files. This would still require the 30 day grace period before it could be introduced (maybe in TS 2.2?) but would future proof this problem and allow just a single npm org for publishing types. Its also not backwards compatible, but it would be the easiest to maintain in DefinitelyTyped.

Option E: Add additional meta-data support to package.json to declare types with a minimum version. This could look something like:

{
"...": "...",
"types2": {
">=2.1.0": "index-2.1.0.d.ts"
}
}

Newer versions of typescript can look at this instead of types and choose the highest version that maps.

This would be a PITA to support, IMHO. You could do it with branches in DT, but now we have to support forward merging changes to types-2.0 to types-2.1 and then types-2.2, etc. Or you have to keep the different versions in the same branch and remember to change them all when adding new functionality.

Another way to do this, which I have no idea if it would work given future changes to TS are unknown, is write scripts that convert the latest typings into older versions. For example, pretty much every typing that would want Partial<T> could just be mutated at the time the publisher runs to replace it with T. Pick is probably any in the old world. ReadonlyArray support wouldn't have been broken cause it could just be Array. This would require custom scripts for each new release but it might not be awful.

There are probably other ways to do it, but these are the ones that came to me today. I would really love to hear the opinions of a bunch of people: @andy-ms, @ahejlsberg, @pspeter3 @vsiao @johnnyreilly, @jkillian, and more.

Thanks