-
Notifications
You must be signed in to change notification settings - Fork 14
Uncertainty About Deployment Mechanism/Toolchain for Definitions #1
Comments
…toolchain. See deployment related issue #1. As a result, imports are now set to relative paths in the interim to postpone decision regarding deployment and module resolution. Updates to d3-selection and d3-transition to replace use of type aliases with direct argument typing of function arguments passed into methods or returned. This is done with regard to ease visibility of typing info in editor without need to navigate to alias definition (development is in VS Code). Some updates to naming of generics (e.g. DescElement to generalize beyon immediate child elements in selections, also use OldDatum in selectAll, where pre-existing data may be selected with the elements.)
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. |
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:
Hopefully, this can be cleared up shortly. |
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. |
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
d3
global (both as standard bundle or with a subset of the modules which extend the same global), andGiven 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.
The text was updated successfully, but these errors were encountered: