Use NPM as the registry

[blakeembrey]

Little background: https://twitter.com/IgorMinar/status/700452928197275648

This is a proposal I have dismissed in the past because of a number of flaws, but I've spent a lot more time thinking about it more critically this time. I'm opening this in hope of having a discussion and discovering possible flaws or enhancements for using a different approach with Typings. I realise some features will go away in this implementation, but if the cons outweigh the pros it's a likely implementation I'll attempt for 1.0.

The proposal: Use NPM as the registry and kill feature duplication of Typings.

Summary:

• Use the @typings namespace on NPM to publish type definitions of NPM packages
  • The implementation would involve using the current registry (https://github.com/typings/registry) and a modified typings.json file - when a type definition is added to the registry, we create an NPM package with the version and publish to NPM (E.g. express will be republished as @typings/express)
• The generated package should mirror the real JavaScript files that exist in the mirrored package (E.g. express/<path>)
  • To do this, copy .d.ts files and generate .js files that just module.exports = require('express/<path>')
  • See concern below, how does this change with ES6 interop?
• Usage is just a small change from require('express') to require('@typings/express')
• The typings CLI will likely still exist, but it'll be a thin layer over the top of existing registries mapping commands
  • E.g. typings install express --save maps to npm install @typings/express@latest --save --save-exact
  • There'll be only a couple of "native typings" commands - likely one that helps with testing and one that does the packaging for NPM
• The typings.json file used by the Typings registry repo would use version as a semver range, and that would map to { "dependencies": "<name>": "<version>" } when generating the package.json

Issues/Questions:

• How do "ambient" typings continue to be distributed?
  • My thought would be to make the package name a stringification of the package name with a prefix
  • (Related to the below point about scoped packages)
  • E.g. node either becomes @ambient-typings/node or @typings/ambient-node (which means option two affects regular imports to avoid possible real/ambient name collisions)
• How does one type a scoped package?
• What about ownership of type definitions?
  • I think this one is mostly resolved already, but could use comments on the approach (described in summary)
• How does the ES6/CommonJS distribution occur with TypeScript/JavaScript-future compat?
• Can this approach be used for other package manages that exist?
  • Ones that resolve to GitHub repos - Bower, Duo, JSPM, etc.
• What about non-NPM or private packages?
  • Possibly we expose a typings package command that'll do the same thing as building for NPM

Pros:

• Kills a lot of implementation duplication
• Less expenses - only need a worker to deploy to NPM
• It's possible this pattern can be expanded to other registries
  • Registering typed Bower packages using a similar stringification pattern - typings-<bower-dep>, however not all registries have dedicated namespaces which is a con

Cons:

• Lose some of the features that have been useful for adopters of TypeScript
  • For example, JSPM support - Typings acted as a polyfill for some time thanks to the way it worked
• No "browser" field resolution (Arguably need to lobby for this in the TypeScript compiler anyway)
• Drops support for DefinitelyTyped
• No non-registry typings support (E.g. can't distribute generic-reuse typings)
• Versioning is a little messier - multiple type definitions could type the same NPM version, one type definition can type multiple NPM versions
  • Likely use "build versions" as a suffix each time the typing is changed - E.g. 4.6.2-6
• Not possible to have multiple versions at the same time
  • E.g. looking at typings as a matrix between (NPM version, compiler version) and it's 2x type definitions

Afterthought: It's also possible to implement a similar system without the actual NPM registry in use, where things become a hybrid solution. typings install express installs from the registry repo (instead of NPM) but sets up node_modules/@typings/express for you. This would work better with other package managers and maintain consistency. Typed dependencies can be keyed in package.json. Pros/cons?

[unional]

IMO I don't see too much of a benefit out of it, unless your plan is to retire typings/registry in the future.
I still think the typings is 1-1 map to the source, not the distribution channel.

This solution would make the coupling between the source and distribution channel even more, and the syntax/structure could be inconsistent for different distribution channels.

For example, if I use some libraries directly by downloading them, or purely rely on CDN, I don't need a local package.json and node_modules. and I don't have to manage those extra files and require co-worker to do npm install at all.

One concrete example would be ExtJS. Its commercial version is not open sourced and not available through any distribution channel. I have to download it and reference it locally. In that case typings/registry would be the only solution (I think).

In order to support this scenario, typings still need to implement all logics, thus there is no saving.

By the way, does npm support name mapping? I only know jspm does. 😜

[johnnyreilly]

My initial thought was "yay brilliant idea". Having read your pros and con's I'm not so sure.

Drops support for DefinitelyTyped

This is a massive problem. My gut feeling is that the future for TypeScript is a Registry and non-ambient type definitions. The reality is there are many projects reliant on DT and they're unlikely to take the leap to Typings if DT becomes closed to them.

Separate to that, it seems that usage of Typings may become more complicated as a result. I've only just had my first cup of coffee but I didn't really follow the usage of Typings in speculative npm-land. Looks non-intuitive to my tired eyes.

Not possible to have multiple versions at the same time

Also a big loss. How would that affect users who have to stick with Angular 1.2.x for instance? That's not me but there will be many in that boat. (And similar)

[IgorMinar]

Here is my counter proposal: https://goo.gl/fWsqax that doesn't suffer from many of your cons. I discussed this design with @mhegazy in December 2015 and both of us agreed that it was doable but needed to be fleshed out and implemented.

[billti]

We should set up another call to discuss a way forward here. We've been looking at changes we can make in the language and toolset to ease this problem (e.g. see microsoft/TypeScript#7125 ), and have some ideas along this line. Are you folks free some time next week (perhaps Mon or Tue)?

[blakeembrey]

@billti Sounds good. I have seen those and excited for those changes. I'm available either of those days, but feel free to follow up offline.

@IgorMinar Actually, I've read your proposal and it actually looks practically identical but more limiting. Should I leave comments on the difference here? It's possible I just wasn't very clear last night creating this issue and something is lost in translation.

[blakeembrey]

@IgorMinar I'm of the opinion that a half-way approach might be interesting and work, where I implement the ability to use imports from @typings/<package> which are typed "polyfills" of regular NPM libraries. Is there a concern you have with that approach?

From your proposal, the main differences I see is:

• Using postinstall hooks to link type definitions
  • I propose using @typings/<package> so that dependencies are literally the type definitions too, no need for a tool or changes to TypeScript
• Use a global type definition repo
  • This is one of my biggest pain points - it's basically centralizing https://github.com/typings/registry and going to the DefinitelyTyped structure again
  • In fact, if you look at the Typings registry format - it's exactly the format you propose except it Typings maps to user repos instead of storing all source code centrally
• Why does it propose using peerDependencies?
  • I'm probably missing something there, but that sounds like a huge pain point - why wouldn't it use regular dependencies and regular dev dependencies? I still want my dependencies typed, I don't want a mapping solution that I push onto my non-TS users

This is a massive problem. My gut feeling is that the future for TypeScript is a Registry and non-ambient type definitions.

Most likely we'll just need to do some grunt work here to upgrade to both latest TypeScript version (with global augmentation) and make them non-ambient (90% of the time minimal effort).

Also a big loss. How would that affect users who have to stick with Angular 1.2.x for instance?

Sorry, by multiple versions I should have said multiple distributions. There'd be @typings/angular@1.2.x-0 to install. But we'd have to figure out what that looks like for different compiler versions. E.g. @typings/angular@1.2.x-ts14-0.

[IgorMinar]

@blakeembrey repackaging npm packages under @typings/ has many major issues, here are just the most important ones:

• you will be basically forking npm within npm
  • this will either result in compatibility issues especially around handling transitive dependencies (apps will have complicated dependency graph when a package depends on some typed and some untyped packages where the app also depends on some)
  • all typed code will have non-portable imports so if someone posts a snippet of code on StackOverflow in ES6, typescript users might accidentally install wrong dependencies or will have to always rewrite that code to use the right dependencies
  • every single release of a package with typed clone, will require a rerelease of the typed clone even for patch releases where the public api surface doesn't change
  • versioning will become a nightmare because if you need to rev a package only because of typings change what version will you use? how will users know what they are using and if they are using the right thing?
• licensing issues
  • in some cases it might be unclear or illegal to repackage the original package, which brings legal liability issues to the typings maintainers that might not even be aware that they are doing something illegal.

[blakeembrey]

No, you don't repackage everything. You re-export it. I believe this is in my first example.

main.js

module.exports = require('express')

main.d.ts

function express (): any;

declare namespace express {}

export = express

package.json

{
  "name": "@typings/express",
  "dependencies": {
    "express": "<semver version from `typings.json`>"
  }
}

Some of the other pieces are valid, but they are essentially the same issues we'll run into anyway.

In this case, dependencies are always typed. If the definition in NPM is already typed, it doesn't need to exist under @typings/. We can use the npm deprecate feature to warn here too. Packages can depend on @typings/ version when in a typed world, I believe it's a simple change (without negative side effects, as far as I can see) and the only other package dependencies would be other typed packages (either real NPM dependencies or more from the @typings/ ecosystem).

[IgorMinar]

@blakeembrey I see, I missed the reexport piece. I still think that you are proposing to fork the npm ecosystem in this way and this is going to be really troublesome. 3rd party typings is an orthogonal issue to the js delivery and by conflating the two we'll see ripple effects through the whole package and tools ecosystem.

npm gave us name registry for the js world, we should cherish it. I believe that your proposal to fork the registry is going to have severe side-effects and that's not acceptable.

Imagine flow would do the same and now we'd have @typings/ and @flow/ in npm and various projects would start depending on reexported packages from one or the other. At some point it will become common that es6 users that don't care about typescript or flow will end up depending on both via a very unfortunate transitive dependency paths. Such situation would be totally unacceptable.

I think the 3rd party typings delivery must be significantly improved but not at the cost of breaking the non-ts world especially since it can be avoided.

[blakeembrey]

Doesn't having peer dependencies or real dependencies on type definitions create this same dependency path issue? It's just pushed out of the critical path. Is your suggestion more around just using the registry or is it also using the NPM tooling? From the proposal I gathered you wanted to be able to use the tooling too and drop using typings. If it's not just that, I feel there might be better compromises on the TypeScript compiler than resolving node_modules/@typings.

For one, you could do:

1. Follow native resolution to dependency (E.g. node)
2. When typings are not found using tsc resolution, fallback to the source location typings/ (E.g. typings/express/index.d.ts)
3. Success or failure. This would work with any future resolution strategy and is directly what I'd love to see, since typings shouldn't be visible to end users - packages should be able to publish with their definitions and "just work".

[IgorMinar]

Doesn't having peer dependencies or real dependencies on type definitions create this same dependency path issue?

no. while your proposal forces users to import @typings/foo, with my proposal users would import just the normal foo and tsc would just fall back to loading the typings from node_modules/@typings/foo.

Now the question is how to get @typings/foo into node_modules - the answer is npm install. But how to make sure that we have the right version of typings? The answer to that is peerDependencies. Peer dependencies ensure that you don't mess up and install wrong version of @typings/foo.

[billti]

@IgorMinar Just noticed you are not on the Slack channel, so I'm including the link here to the Gist for ideas Ryan and I have been discussing. It shares a lot in common with your doc, and hopefully covers some of the above: https://gist.github.com/RyanCavanaugh/2ebc036361e53f8d6f69

At this point, our thinking is that we should be rolling some of the basic type acquisition mechanisms into TypeScript itself. There's a few reasons for this:

• With our efforts to have TypeScript power some of our JavaScript language services (see JavaScript powered by TypeScript microsoft/TypeScript#4789 ), we need type acquisition to happen seamlessly for JavaScript users also (i.e. they shouldn't have to know about dropping to command line and using additional tools - they shouldn't even have to know about TypeScript ideally).
• Some of the proposals require changes to the language itself and the file resolution mechanisms, as such this gets tied more closely to the TypeScript implementation and keeping changes in sync.
• We want the simplest possible story for users. Types are fundamental to TypeScript, (heck, it's right there in the name!), and we'd like to be a lot more prescriptive on tools and patterns to reduce some of the pain we see today.

Give it a read, comment, and then lets all try and converge next week. Everyone on this thread is a key stakeholder in landing a great solution here, and it seems we're all thinking along the same lines - so I'm optimistic that we're close!

[IgorMinar]

Yeah, that looks very similar to my proposal, except that what you call
"peer dependency" is not the same thing as what I call "peerDependency" and
you are missing version locking write up in your solution. Otherwise it
looks very similar if I understand it correctly.

I think Blake has a major concern about the mono-repo approach and we
should discuss that - I don't feel strongly about keeping the mono-repo
design that DefinitelyTyped started.

On Sat, Feb 20, 2016 at 2:30 AM Bill Ticehurst notifications@github.com
wrote:

@IgorMinar https://github.com/IgorMinar Just noticed you are not on the
Slack channel, so I'm including the link here to the Gist for ideas Ryan
and I have been discussing. It shares a lot in common with your doc, and
hopefully covers some of the above:
https://gist.github.com/RyanCavanaugh/2ebc036361e53f8d6f69

At this point, our thinking is that we should be rolling some of the basic
type acquisition mechanisms into TypeScript itself. There's a few reasons
for this:

• With our efforts to have TypeScript power some of our JavaScript
  language services (see JavaScript powered by TypeScript microsoft/TypeScript#4789
  JavaScript powered by TypeScript microsoft/TypeScript#4789 ), we need type
  acquisition to happen seamlessly for JavaScript users also (i.e. they
  shouldn't have to know about dropping to command line and using additional
  tools - they shouldn't even have to know about TypeScript ideally).
• Some of the proposals require changes to the language itself and the
  file resolution mechanisms, as such this gets tied more closely to the
  TypeScript implementation and keeping changes in sync.
• We want the simplest possible story for users. Types are fundamental
  to TypeScript, (heck, it's right there in the name!), and we'd like to be a
  lot more prescriptive on tools and patterns to reduce some of the pain we
  see today.

Give it a read, comment, and then lets all try and converge next week.
Everyone on this thread is a key stakeholder in landing a great solution
here, and it seems we're all thinking along the same lines - so I'm
optimistic that we're close!

—
Reply to this email directly or view it on GitHub
#223 (comment).

[billti]

Are you advocating the actual peerDependency property in package.json for specifying/installing packages? I've already hit pain with this when using Node v5, as that uses NPMv3 which has changed the behavior, and they don't install by default any longer.

From http://blog.npmjs.org/post/110924823920/npm-weekly-5

We will also be changing the behavior of peerDependencies in npm@3. We won’t be automatically downloading the peer dependency anymore. Instead, we’ll warn you if the peer dependency isn’t already installed. This requires you to resolve peerDependency conflicts yourself, manually, but in the long run this should make it less likely that you’ll end up in a tricky spot with your packages’ dependencies

If I'm misunderstanding your usage of peerDependency let me know (it is an overloaded term).

[IgorMinar]

@billti yes, those peerDependencies. not installing by default is the correct behavior. what's not correct is that there is a lot of hand-holding involved in dealing with peerDeps in the current npm. I'll be looking into fixing this via a PR to npm next week.

[billti]

I'd be interested in what you had in mind here. I just tried re-reading the doc, but still can't grasp what you are using peerDependencies for.

In ideas we've been tossing around, you wouldn't have to install each @typings/* package separately as per the example in your doc. You'd run something like tsc get-types and for each dependency or devDependency in package.json, it could fetch and npm install --save-dev the corresponding @typings/* package for the same major.minor version.

The structure and versioning of the types repository is something to be careful with. If we try and maintain a matrix of libraries x versions x TS compiler releases, it will become unwieldy quickly. We need to balance being useful and also maintainable. In reality the vast majority of updates to type definitions are for the latest version of the package with the latest version of the compiler. Definitely a key problem though for a workable & well supported ecosystem.

[IgorMinar]

peerDependencies tell you if you have a version mismatch between the
package and it's 3rd party typings package.

This mismatch could happen if you update one of your packages but forget to
update its typings.

Using peerDependencies a typings package expresses what version of the
package it's compatible with.
On Sat, Feb 20, 2016 at 4:06 AM Bill Ticehurst notifications@github.com
wrote:

I'd be interested in what you had in mind here. I just tried re-reading
the doc, but still can't grasp what you are using peerDependencies for.

In ideas we've been tossing around, you wouldn't have to install each
@typings/* package separately as per the example in your doc. You'd run
something like tsc get-types and for each dependency or devDependency in
package.json, it could fetch and npm install --save-dev the corresponding
@typings/* package for the same major.minor version.

The structure and versioning of the types repository is something to be
careful with. If we try and maintain a matrix of libraries x versions x
TS compiler releases, it will become unwieldy quickly. We need to
balance being useful and also maintainable. In reality the vast majority of
updates to type definitions are for the latest version of the package with
the latest version of the compiler. Definitely a key problem though for a
workable & well supported ecosystem.

—
Reply to this email directly or view it on GitHub
#223 (comment).

[IgorMinar]

Also keep in mind that the peerDependencies in my proposal are not meant to
enable installation of typings. That should be done via the typings
installer which could be built into tsc as you proposed.

I don't think that setting up dependencies between typings packages as
described in Ryan's proposal is a good idea because it's not necessary and
if specified incorrectly will only be a source of errors.

It is sufficient for installer to fetch typings for direct package
dependencies (those specified in package.json of the project being
compiled) - omitting all transitive dependencies. App developer should not
use transitive dependencies directly and also should there be a typing
error between direct dependency and a transitive dependency there is not
much an app developer can do about it. So why complicate things
unnecessarily?

The only exception to this is reexported transitive dependencies. e.g. how
gulp reexports Orchestrator as its public api surface. These reexports can
be handled using npm's "dependencies"
On Sat, Feb 20, 2016 at 7:23 AM Igor Minar iminar@google.com wrote:

peerDependencies tell you if you have a version mismatch between the
package and it's 3rd party typings package.

This mismatch could happen if you update one of your packages but forget
to update its typings.

Using peerDependencies a typings package expresses what version of the
package it's compatible with.
On Sat, Feb 20, 2016 at 4:06 AM Bill Ticehurst notifications@github.com
wrote:

I'd be interested in what you had in mind here. I just tried re-reading
the doc, but still can't grasp what you are using peerDependencies for.

In ideas we've been tossing around, you wouldn't have to install each
@typings/* package separately as per the example in your doc. You'd run
something like tsc get-types and for each dependency or devDependency in
package.json, it could fetch and npm install --save-dev the
corresponding @typings/* package for the same major.minor version.

The structure and versioning of the types repository is something to be
careful with. If we try and maintain a matrix of libraries x versions x
TS compiler releases, it will become unwieldy quickly. We need to
balance being useful and also maintainable. In reality the vast majority of
updates to type definitions are for the latest version of the package with
the latest version of the compiler. Definitely a key problem though for a
workable & well supported ecosystem.

—
Reply to this email directly or view it on GitHub
#223 (comment).

[blakeembrey]

I'm sure this'll come up in our call, but using peerDependencies feels like it'll be confusing for non-TS users, no? It'll start warning consumers of the package of expected peer dependencies, and they'll even be installed with NPM < 3 (which is currently bundled with node < 5). Also, there's no separation between normal and dev dependencies here, which I believe is also important for users for TypeScript.

Re-exported type dependencies are also quite common, but more common with option interfaces than actual implementation I've found. Just to clear it up, you suggest using all of the dependency fields in package.json and installing both the normal module and the @typings/ version right?

[unional]

I'm trying to understand the big picture here.

Objective

Zero or near zero configuration for user to get the benefit of typings in javascript or typescript environment (through javascript language service or typescript language service)

Problems to solve

• How to discover the packages in use? (Package Discovery)
• How to get the typings for those packages? (Typings Delivery)

Package Discovery

Environment variations: npm, bower, jspm, NuGet, "no package manager", etc.
Discussion in this thread focus on using npm's package.json for package discovery.

Typings Delivery

Discussion in this thread focus on using npm as the distribution channel for typings.

If these are true, I would suggest to separate Package Discovery and Typings Delivery. We need multiple Package Discovery strategies to support different environments, but we only need one Typings Delivery mechanism, whether it is npm or http (typings/registry).

My two cents.

[IgorMinar]

@unional yup. package discovery can be done via the typings installer that could be built into tsc and work off of the conventions - stuff that @billti and I discussed

the delivery can be via npm and alternatively via the typings installer by downloading the npm tarballs to other environments.

[IgorMinar]

@blakeembrey I think you misunderstand my proposed use of peerDependencies.

I'm proposing that for a package foo there exists a typings package called @typings/foo. It is this typings package @typings/foo that specifies peerDependency on foo. The purpose of this peerDependency is not to install the typings package, but to verify that the right version of the typings package is being installed.

Hopefully this scenario will illustrate the value:

$ npm install --save foo 
$ npm install --save-dev @typings/foo
$ npm install --save foo@someOldVersion
   ERROR peer deps mismatch
$ npm install --save foo@someOldVersion @typings/foo@someOldVersion
  ALL GOOD

We might need to make some tweaks in npm (via a PR) to ensure that the @typings/foo is installed as dev-dependency and not a real dependency, but I think that's doable.

Now if we were to use the typings installer as a postInstall hook then the workflow would look like this:

$ npm install --save foo 
$ npm install --save foo@someOldVersion
  ALL GOOD

I much more prefer this, but it requires the typings installer to be created and npm needs to be tweaked to call the postInstall hook after npm install <package_name> - currently it calls the hook only if install without package name is invoked (npm install).

[billti]

Thanks @IgorMinar . That clarifies things a lot. I do still worry about using peerDependencies though, as its behavior is changing from v2 to v3. While you mention "We might need to make some tweaks in npm (via a PR)...", note that we still see a LOT of usage of Node 0.12 (and a fair amount of 0.10), so back-compat has to be a strong consideration.

I would expect something like a tsc update-types (or just re-running tsc get-types) would perform a similar function of verifying and refreshing the typings packages. Could this cover the scenario sufficiently without using peerDependencies?

[IgorMinar]

For this particular usage the peerDeps work the same in npm v2 and v3.

If you want to do the compatible check in tsc you will still need a place
in package.json to store the compatible version range. It would be a shame
to create a custom field for something that npm already has a standard
field.
On Mon, Feb 22, 2016 at 5:44 PM Bill Ticehurst notifications@github.com
wrote:

Thanks @IgorMinar https://github.com/IgorMinar . That clarifies things
a lot. I do still worry about using peerDependencies though, as its
behavior is changing from v2 to v3. While you mention "We might need to
make some tweaks in npm (via a PR)...", note that we still see a LOT
of usage of Node 0.12 (and a fair amount of 0.10), so back-compat has to be
a strong consideration.

I would expect something like a tsc update-types (or just re-running tsc
get-types) would perform a similar function of verifying and refreshing
the typings packages. Could this cover the scenario sufficiently without
using peerDependencies?

—
Reply to this email directly or view it on GitHub
#223 (comment).

[blakeembrey]

@IgorMinar Thanks for the clarification. That makes a lot more sense now.

Looking forward to our discussion later this week now so we can formulate a plan.

[drinchev]

IMHO this is the best approach.

I would be really happy if this goes through and it's documented better.

Having another package manager ( as tsd, typings ) doesn't give the scalable infrastructure npm built.

I even suggested this in DefinitelyTyped/DefinitelyTyped#2150 (comment)

How to discover the packages in use? (Package Discovery)

npm supports a tag name, so a website with a npm query that filters repos with the tag name ( similar to http://yeoman.io/generators/ ) will be sufficient.

[blakeembrey]

@drinchev I agree. I've talked with the TypeScript team and they have plans for using NPM for aliases of top-level module names. Once they have the infrastructure set up for that to work in the compiler, I can know how I can also use it because Typings is more than just top-level aliases - it has type definitions for multiple different sources and ambient definitions (E.g. Atom, Electron, etc). Those don't fit into that model so well, but if I can also use it then great 👍

So, once TypeScript merges their library feature I'll be testing it and if it works over sub-dependencies with multiple namespaces (not just with node_modules/@typings) and I can use it, I'll be implementing it as a PoC and hopefully start using it long-term.

[blakeembrey]

@drinchev So the biggest thing here is that I don't think any of this can be built or bought into until the TypeScript library feature exists to enable some of it. The issue with switching to NPM as the registry to serve definitions is one thing, but actually consuming those is another. There needs to be the ability to create aliases that can be discovered properly used by the compiler to enable real external module support. Without that, Typings still has to do it's hacky chore of creating a bundle with namespacing, etc.

[drinchev]

Thanks for the clarification. I read more deeply this issue and it looks like TypeScript's team will help.

However as far as I followed the conversation, I saw that the only reason for not letting module.exports = require('express'); is :

Imagine flow would do the same and now we'd have @typings/ and @flow/ in npm and various projects would start depending on reexported packages from one or the other. At some point it will become common that es6 users that don't care about typescript or flow will end up depending on both via a very unfortunate transitive dependency paths. Such situation would be totally unacceptable.

No offense, but I honestly think, with the current state of npm and the micro-modules explosion ( left-pad & others ) the argument needs to be stronger than that.

Having typed-wrappers for the npm modules, hosted on npm actually requires almost no technical effort. People already started doing that ( https://www.npmjs.com/~weswigham ) and I also created my own PoC ( https://github.com/drinchev/ts-experiment ). It works with no TypeScript modifications.

I'm not sure what the final solution of TypeScript team will be, but having another package tool seems unneeded if the community agrees to use npm prefixed modules.

I'm really sorry if I've missed something that makes my arguments flawed.

[unional]

Can we close this now?

[blakeembrey]

Sure, sounds good. Typings will live as is since I don't have the development time to transition it and the effort should instead be put against the native TypeScript implementation.