Uncertainty About Deployment Mechanism/Toolchain for Definitions

[tomwanzek]

Currently there are two primary channels for publishing typescript definitions for third party libraries, where the definitions are not included with the library: DefinitelyTyped and typings registry. A separate tool, typings (or formerly tsd), is used for acquisition of definition files and integration into the code base.

The typescript 2.0 milestone adds a further dimension for typescript definitions acquisition with the @types/npm mechanism. @types is intended to draw on DefinitelyTyped (including conversion tooling). typescript@next also already allows the authoring of definitions in UMD format.

With respect to support for D3 v4 related typings, this raises the question of the best deployment mechanism/migration path, i. p. since D3 v4

• is now modularized,
• can be deployed 'vanilla' using a d3 global (both as standard bundle or with a subset of the modules which extend the same global), and
• can be used through module imports.

Given the implications of @types for module resolution of definitions (additional meta data files npm etc.) and in order not to cloud the focus of on D3 v4 this typing related exploration, definitions and tests are currently integrated using relative imports.

This is a preliminary matter, to focus on definition content rather than tool chain implications.

[tomwanzek]

See DefinitelyTyped issue for new D3 v4 definitions.

[tomwanzek]

Started migration to DefinitelyTyped.

See Roadmap and the related issue on Request for d3.js API update from v3 to v4.1.0.

Closing this broad strategy issue. I will open migration specific issues as they arise.

[tomwanzek]

I am re-opening this issue to reflect the risk that a complete migration to DT/@types may not be possible.

This risk is qualitatively distinct from the issues tracking the module-level migration status (#56 and #105 ).

While the definitions for the standard bundle modules are complete in this repo, there has been no progress in clearing up the apparent structural DT/@types transition issues affecting DT PR 10453.

As a result, it is presently not self-evident, that everything can be successfully migrated into DT / @types. Most notably, this affects the definitions for the D3 standard bundle, d3-dsv and d3-request.

For those in a position to contribute to resolving the relevant issues on DT, here are the primary references:

• D3 Definitions Request Tracking Issue 9936
• Generalized, spun-Off Issue 10711 for DT Contributions to @types

Hopefully, this can be cleared up shortly.

FYI @gustavderdrache @Ledragon @arrayjam

[tomwanzek]

Closing this issue here. It is a know DT/types-publisher issue to allow parallel version structures in DT/types-2.0. The TS team intends to provide a solution to it.

The issue will be tracked on DT on a go-forward basis until resolution.