What about "The Future of Declaration Files"

[zam6ak]

No issue, just wanted to get peoples toughts on this

The Future of Declaration Files
https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/

[blakeembrey]

What sort of thoughts are you after? I'm positive on it (as it says, I've been helping out) but there's still a few kinks that need ironing out and some work to put into it.

[cspotcode]

What should I be doing today when I write new .d.ts files? Put them in DefinitelyTyped, or typings' registry, or both?

I like the distributed nature of typings' registry, and how it differentiates between external and ambient modules, and is agnostic to the exact name of a module. How will those things be possible when everything's in DefinitelyTyped?

How will DefinitelyTyped deal with different versions of a declaration?

Are there any github issues or blog posts I can read to answer these questions for myself?

[blakeembrey]

@cspotcode You're better asking these questions in the linked TypeScript repo discussion. Today, you can put them where you like. I'd recommend still using Typings until we get redirects working and then we'll put an effort in to port the existing registry base into DefinitelyTyped. The big thing why is also external modules for me, I haven't yet seen the huge refactor of DefinitelyTyped which should refactor the repo into external modules (but it's coming).

[blakeembrey]

How will those things be possible when everything's in DefinitelyTyped?

External vs ambient should be less of an issue, since UMD support is coming in TypeScript 2.0 also. The only other concern is namespace conflicts, which I believe NPM module will take precedence since it's now going to be mirrored to NPM.

How will DefinitelyTyped deal with different versions of a declaration?

As far as I can tell, inside the repo it'll be versioned folder based. Across redirects has not been defined.

Are there any github issues or blog posts I can read to answer these questions for myself?

There's a few, the best ones to start with are the official one: microsoft/TypeScript#9184.

[cspotcode]

@blakeembrey Thanks, I missed that link in the blog post; I'm checking it out now. UMD sounds great, plus the planned ability to reference external repos from DefinitelyTyped. It sounds like a lot of the advantages of typings are being brought into DefinitelyTyped and the TypeScript compiler itself.

The huge refactor of DefinitelyTyped to external modules: will that be something the TS team automates, e.g. converting everything to a UMD declaration?

[blakeembrey]

will that be something the TS team automates

As far as I know, yes.

[zam6ak]

@blakeembrey Lol. I am not "after" any specific thoughts. It was my way of trying to nicely ask if typings will cease to be, and we should start migrating towards this new "Future"...

[blakeembrey]

@zam6ak Easier to just ask, I won't take it too personally 😄 Yes, we should migrate. No, Typings won't cease to exist until traffic drops well off the block (I won't be killing something people use). No, we can't migrate until the infrastructure set-up is completed.

[zam6ak]

@blakeembrey Ok great. Thanks for the clarification. May be useful for others to put some of those points on the from page of the project.

[felixfbecker]

typings is far superior to @types for typings management because you can version the typings independently from the package. Besides that, npm can really f*ck up your typings if your typings depend on a different version of another typing than you do. You will get duplicate identifier errors everywhere. I hope typings is not going anywhere :)

[marcysutton]

I am having so much trouble with this. I submitted a repo to DefinitelyTyped, which is now ported to @types. It seems like a better idea to distribute the file on npm along with source code to minimize install steps. But the two files conflict with each other. It would be really helpful to have more thorough instructions on how to create definition files with tests that assert the APIs in those definitions. I really want the development experience with TypeScript to be awesome, but it has been nothing but pain all the way down. I should add that our library exposes one global for test integrations.

[felixfbecker]

@marcysutton I think what TS will need to do in the future is resolve typings like Node resolve dependencies. Don't treat them globally, but only external, and look in node_modules subfolder of the typing first, then go one dir up, repeat. But that is not possible currently, the only system that manages typings dependencies properly is typings.

[cspotcode]

@felixfbecker TypeScript 2.0 does that with @types and "moduleResolution": "node", right?

[felixfbecker]

If that is the case, what is the cause of your issue then?

[unional]

AFAIK, TypeScript 2.0 solution does not handle version dependencies properly. Simply because in the declaration file you cannot specify which version of the dependencies you are depending on.

[felixfbecker]

@unional it would be alright if they resolved the deps like Node:

|-- index.ts // will get declarations for A@1.0 and B@2.0
`-- node_modules
  `-- @types
    |-- A@1.0 // will get declarations for B@1.0
    | `-- node_modules
    |   `-- @types
    |     `-- B@1.0
    `-- B@2.0

But all you get at the moment is duplicate module identifier B

[unional]

yes, that is an issue they need to solve to properly handle versioning.

btw, your illustration clearly describes the problem. GJ 🌷

[unional]

Another btw, would this also get into trouble?

|-- index.ts // will get declarations for A@1.0 and B@1.0
`-- node_modules
  `-- @types
    |-- A@1.0 // will get declarations for B@1.0
    | `-- node_modules
    |   `-- @types
    |     `-- B@1.0
    `-- B@1.0  // Still 1.0

I didn't try it out because I know the version issue is not resolved.

[blakeembrey]

I haven't been using TS 2.0 module resolution myself yet, just because Typings does work perfectly fine for myself, but I thought TypeScript had fixed the issues around dependency resolution. At least, this was 100% my concern so if it hasn't been resolved that'll be a huge bummer. My understanding was external modules act like they do in Typings (following node_module resolution) while global definitions the top-most level one takes precedence. I'm not really a fan of the global because it means someone can install two separate node definitions or none and it'd work accidentally until you install a local copy manually - but it seemed like a decent tradeoff for people new to TypeScript.

If someone can confirm this isn't the case, it should be a logged issue ASAP.

As for the initial comment a couple of hours ago, @marcysutton can you give more information on what you're doing or trying to do so someone can help?

[felixfbecker]

@blakeembrey I agree, I am using typings atm too until the redirects are implemented, so my statement might not be true anymore.