Migrate Standard Bundle Modules (TypeScript 2) to DefinitelyTyped/@types

[tomwanzek]

This issue tracks the high-level status of migrating the Typescript 2 definitions with test to DefinitelyTyped (types-2.0 branch) and their propagation to the @types organization.

Module	DefinitelyTyped/types-2.0	@types
d3-array	Current	Current
d3-axis	Current	Current
d3-brush	Current	Current
d3-chord	Current	Current
d3-collection	Current	Current
d3-color	Current	Current
d3-dispatch	Current	Current
d3-drag	Current	Current
d3-dsv	Current	Current
d3-ease	Current	Current
d3-force	Current	Current
d3-format	Current	Current
d3-geo	Current	Current
d3-hierarchy	Current	Current
d3-interpolate	Current	Current
d3-path	Current	Current
d3-polygon	Current	Current
d3-quadtree	Current	Current
d3-queue	Current	Current
d3-random	Current	Current
d3-request	Current	Current
d3-scale	Current	Current
d3-selection	Current	Current
d3-shape	Current	Current
d3-time	Current	Current
d3-time-format	Current	Current
d3-timer	Current	Current
d3-transition	Current	Current
d3-voronoi	Current	Current
d3-zoom	Current	Current

[tomwanzek]

The main issue related to the migration, is the treatment of definitions in DT which consume the legacy versions. By implication this also includes the relationship to the DT master branch.

These issues, primarily affecting the definitions held in PR 10453 on DT, as reflected in the DT issues 9936 and 10711.

The reference issues also extent to the version number disconnect, where the @types packages do not have the right major and minor version number. These should reflect the version numbers of the module for which the definitions are written.

By implication, progress to migrate d3, d3-dsv and d3-request definitions has stalled, despite attempts to raise awareness for the matter on DT.

[kbtz]

I can hardly wait to use this... thanks for your efforts man ^_^

[tomwanzek]

More than welcome. For clarity, most of the individual definitions are already available using npm install @types/d3-***** --save. Including the contributions by @Ledragon @gustavderdrache and @arrayjam .

Hopefully, the remaining cloud does not rain on the parade for too much longer... 😄

[kbtz]

Glad to hear that!
I just didn't managed yet to use everything as a single namespace you know...
AFAIK, even If I install the definitions for all d3 libraries that I use I still can't do something like this:

import * as d3 from 'd3'

This will be possible when the migration is finished right?

[tomwanzek]

@snolflake Assuming you use D3 with module imports as seems to be the case, you are right that the bundle defintions which support import * as d3 from 'd3' are still held back by the migration issues flagged on DefiniteltyTyped.

In the interim, you can simply create a barrel of your own using re-exports as a workaround, i.e.:

// bundle-d3.ts
export * from 'd3-array'
...
export * from 'd3-zoom'

Then you simply use import * as d3 from './bundle-d3' with whatever path is appropriate for your project setup. Gets you the convenience you are looking for.

This also allows you do use only partial re-exports, if you do not need everything. Or you can add in optional scope modules like e.g. export * from 'd3-selection-multi'.

When you create a barrel, you should however watch the sequencing of module imports, as e.g. d3-transition augments d3-selection. And d3-selection-multi extends both d3-selection and d3-transition.

At the core, this is the same strategy I used, when creating a D3Service for Angular 2 + some additional wrapping obviously.

The only true functionality gap is, if you wanted to use the d3 global with individual, unbundled D3 vanilla scripts. That is the scenario, which currently runs into the TypeScript UMD export as namespace 'd3' restrictions.

[kbtz]

The only true functionality gap is, if you wanted to use the d3 global with individual, unbundled D3 vanilla scripts. That is the scenario, which currently runs into the TypeScript UMD export as namespace 'd3' restrictions.

Indeed! I was using unbundled D3 to get all functionality at once (the way mbostock divided the libraries can be quite counter intuitive some times), then I've tried to put the definitions in a global namespace in so many ways... I remember it always ended up in some TS error.

Well, now that things are more clear to me, I've switched back into using individual d3 packages and created a barrel as you recommended, worked like a charm. Thank you again!

[tomwanzek]

I guess from Mike's perspective it makes total sense.

When using D3 as vanilla script, not matter whether you use the bundled script or the individual scripts, you always access through an exposed d3 global. So D3 consuming code is re-usable.

When using D3 with module imports, it's all up to the programmer, given that one can build a barrel and use import aliases as one sees fit.

The limitation is currently much more on the TypeScript side. TS2 currently has a 'first global wins' strategy implemented. Which explains, why it throws an error when writing separate UMD module definitions which attempt to merge into the same global, i.e. d3.

Well, we'll see...

[wz2b]

I get the idea here but I am missing something to make it work. With an angular-cli app I made src/app/bundle-d3.ts that contains

export * from '@types/d3-time';
export * from '@types/d3-scale';

Then, just as a test, in src/app/app-component.ts:

import * as d3 from './bundle-d3';
...
  constructor() {
       d3.scaleLinear();
  }

and I get this:

ERROR in ./src/app/bundle-d3.ts
Module not found: Error: Can't resolve '@types/d3-scale' in '/home/xxx/work/xxx-kiosk/src/app'
@ ./src/app/bundle-d3.ts 2:0-32
@ ./src/app/app.component.ts
@ ./src/app/index.ts
@ ./src/main.ts
@ multi main

ERROR in ./src/app/bundle-d3.ts
Module not found: Error: Can't resolve '@types/d3-time' in '/home/xxx/work/xxx-kiosk/src/app'
@ ./src/app/bundle-d3.ts 1:0-31
@ ./src/app/app.component.ts
@ ./src/app/index.ts
@ ./src/main.ts
@ multi main

so I think I'm on board with the idea - I create a bundle file that just re-exports all the modules I care about, then I import the entire thing using 'import * as d3' ... but it seems like perhaps I have to do something else to declare that the actual typings come out of node_modules/@types.

Do you happen to have a complete example?

--C

[tomwanzek]

@wz2b the short answer is, when building a barrel, one has to re-export the actual modules, not the definitions. The definitions are implicitly resolved by TS2, if they were installed from @types.

To give you a better idea, I have created an Angular 2 service for D3 which illustrates the principle. It is also published on npm for import into angular-cli projects. I am wrapping up a brief demo, which I will push shortly. (I was hoping for a newer release of the angular-cli webpack version to be finalized)

Let's keep this issue here to what it is all about though. Tracking the migration of this repo's content to DT / @types. Thx for understanding 😄. Cheers.