What is the current recommended way of getting node.d.ts typings?

[bpasero]

With the release of 1.6 and tsconfig supporting module resolution, what is the current best practices to get node.d.ts typings into my project. Should I use "tsd" to get the definitions in? This sounds like a step backwards to me as I really like the new module resolution logic that would pick up d.ts files within node_modules.

My 2 cents: Some authority (either node.js or typescript) should maintain a node module that is versioned in the same way as node.js releases are and include a .d.ts file that I can depend on to code against the right version of node.js API.Whenever my node environment changes to a newer version, I would also update the npm module with its definitions.

Are there alternatives? In my current setup I do not really want to add node.d.ts into a "typings" folder because this node.d.ts file is not versioned and will very quickly be outdated when node.js API is added.

[weswigham]

If/when we nail down how we're fixing package dependency global scope conflicts, I think npm packages like this are pretty neat.

[tinganho]

@weswigham so you recommend adding a typed- prefix and re-export the original package? I was thinking about just asking an author to add the typings directly. I don't think they mind.

[weswigham]

That's perfectly reasonable as well.

On Fri, Sep 25, 2015, 1:11 AM Tingan Ho [email protected] wrote:

@weswigham https://github.com/weswigham so you recommend adding a typed-
prefix and re-export the original package? I was thinking about just asking
an author to add the typings directly. I don't think they mind.

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

[DanielRosenwasser]

@tinganho if you can get the authors to include a typings folder then that would be more ideal. Most authors are pretty nice about it, though, it can be a sensitive issue for some.

[mhegazy]

I do not think adding new npm packages is the right way to go. this adds a burden on users to add these package dependencies that have no runtime impact. it will also add new mental overhead for users to understand what packages are "empty" and which are not.

There will always be packages that do not ship their .d.ts, for these we need a versioning story. see #4665 for more discussion.