How to mention types using the new npm @types?

[Ptival]

So, as far as I can tell, with any other module I have tried so far, the definitions files have a line like:

declare module Rx {
declare module 'tsmonad'

Which lets me refer to parts of the module without importing it, for instance, in a definition file.

None of the d3 modules seems to have this. Therefore, at the moment, I can talk about d3 types in implementation files like this:

import * as d3Selection from "d3-selection"
type MySelection = d3Selection.Selection(...)

But I have found it so far impossible to define such a type in a definition file:

type MySelection = Selection(...) // has no idea what that is
// adding an import is not possible in a definition file

I even tried reference path, which I'd like to avoid, and couldn't make it work either. In fact, Selection is already another thing in lib.d.ts, so I'm not even sure how this would work without some namespacing.

[valorcurse]

I've been wondering this myself, I'd like to encompass everything under a 'd3' namespace (i.e. d3.selection, d3.time) without having to import every single package by doing import * as 'd3' from 'd3'. This would help keep the code clear and avoid name collisions with other packages as @Ptival mentioned.

Is the only way to do this by creating an own module package which imports d3 packages and exports them under a different name?

[tomwanzek]

While I have closed this repo after completed migration to DefinitelyTyped/ypes-2.0 (and by implication to npm @types), I will provide a brief response below. Should it not suffice, please review the issue DT 9936 for further context. The issue also cross-references any and all open items, which where carried over from this repo. So, in case of further question, please use the DefinitelyTyped issues on a go forward basis.

@Ptival The definition file module structure is that of an external module, which is in accordance with TypeScript 2 practices. So, using import { Selection } from 'd3-selection' will import the interface for the selection object, assuming you have installed the definitions from npm @types. You also must use TypeScript 2+ for any of this to work.

I have pushed PRs to DefinitelyTyped a week ago, which adds JSDoc comments starting with some of the more complex definitions (in particular, they contain explanations of the used generics in the interfaces and methods).

If you go the github repo for type-script handbook, you will find more information on the different ways declaration files can and should be structured and written now.

They were originally intended to be individually written as UMD module definitions, meaning that individually they would contain an export as namespace d3; which would have exposed the content under a d3 global for use of D3 modules in vanilla script scenarios. This is not possible due to TypeScript 2 not allowing to merge into the same global from multiple separate definition file. I had filed an issue with the TS team to explore opening this compiler behavior up, but they ended up deciding against it. So the individual definitions in and of themselves cannot be used in plain vanilla settings right now. Wish I could change,but I can't, I am afraid...

For module import scenarios, the D3 module definitions work exactly like the corresponding D3 modules do.

So, if you want a bundle of modules to use with an import alias of d3, you need to create the bundle of the relevant modules and you need a definition file which reflects the corresponding bundle content to use it with TypeScript.

@valorcurse With respect to definitions for what I have called the D3 Standard Bundle as published by Mike Bostock on d3/d3, there is an open issue on DefinitelyTyped11367. Again, I have pushed for the necessary changes to DefinitelyTyped for some time now. The definitions for the bundle, which you find in this repo are as yet unpublished on DT/npm @types, because the relevant DT branch does not yet support parallel version structures. Publishing version 4 there, would break several other definitions, which still depend on D3 v3.x You will find a work around in the issue I referenced.