-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace D3 Legacy #12256
Replace D3 Legacy #12256
Conversation
* Replaces the legacy D3 v3 definitions in `d3` with a definition file representing the D3 version 4 standard bundle * Add `package.json` file with legacy dependency to @types/d3 version >=3.5.36 <4.0.0
* Updated tsconfig.json to control typings resolution for D3 v3 * Updated package.json to use caret notation of D3 typings * Updated certain affected definitions header comments with version numbers, where version number was missing buit seemed reasonably ascertainable as latest. * Added comments to each affected definition file with TODO once upgrade to D3 v4 is considered
Don't see the relation to #9937, did you mean something else? |
@andy-ms Yes, thanks for catching my typo, I fixed it above. |
Travis seems to be a bit moody. Doesn't seems to want to start the job. Is there anything required from my side to trigger it again? |
🎉 |
@andy-ms when you have a chance to merge this PR can you also kindly look at #12272 . It's a tiny fix PR for d3-format (it already passed Travis as well). Thanks!!! most appreciated. |
@@ -1,10 +1,17 @@ | |||
// Type definitions for C3js | |||
// Type definitions for C3js v0.4.11 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for a patch version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll remove it. As an FYI, I tended to keep the patch version in for the d3-xxxxx definitions for ttwo reasons:
(1) It's easier to go back to the underlying library and check for changes in commits after the last validated patch w.r.t. definition accuracy, and
(2) which goes hand in hand with (1), while a patch release in JS may not break the JS API, there are times when it does break a strongly typed TS API definition.
"compilerOptions": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use the same indent it had before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI. The .editorconfig
I have in my fork specs out indent=2 for json files? So the changes were simply automatically applied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -0,0 +1,5 @@ | |||
{ | |||
"dependencies": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer 4 space indents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do.
@@ -0,0 +1,5 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file won't actually do anything right now -- legacy
will be ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's ok as far as I can tell,it certainly does not break any dependencies in DT. If someone runs into an issue when newly acquiring the legacy definitions, we will hear about it and cross that bridge then...
@@ -1,9 +1,15 @@ | |||
// Type definitions for nvd3 1.8.1 | |||
// Type definitions for nvd3 v1.8.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The v
isn't needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a convention I used, no problem I can take it out.
Pushed the updated changes as per review above. Travis is not starting...yet. |
@andy-ms Seems all in good working order now. Let me know, if you need anything else from my side. Cheers. |
I think you should remove the TODO comments. I don't want people installing types and seeing a TODO comment at the top -- they'll assume it's a work in progress, when it's are actually fine as-is. For example, c3 currently uses d3 version 3.5, so the typings shouldn't be updated yet anyway. The practice of updating the version number and updating dependencies should be common practices anyway, so we should catch it during code review. |
@andy-ms as per your request the comments have been removed. I am assuming that Travis will be finished in appr. 1.5 hrs. So hopefully, within the next 2hrs we finally have a merge and consecutive publication to the npm @types organization. The publication of the Standard Bundle definition for version 4 has been a long time coming... Thx in advance for proceeding with this! |
One last thing -- could you eliminate any changes that only add some newlines to a file? I think those were previously the TODO comments. |
@andy-ms While I respect your vigilance, this particular PR process has become rather tedious and protracted for increasingly limited value. We have worked for months to get these definitions published, with an extreme amount of patience for all the stumbling blocks and delays on the way. I understand the MSFT team, including yourself, are working very hard to provide great tooling. So are others who provide the content. Tooling alone does not make for a smooth process. Please confirm that there are no further changes required to get this PR published before I consider deleting added lines. Thank you. |
Yes, this is the last review from me (assuming there are no mistakes made in the next change). |
Final changes submitted. |
Final changes passed. |
Thx! |
@tomwanzek, I'm confused! When I go here, is that Type Definitions for D3 v4? or the older v3? |
@Ciwan1859 you have to look here https://github.com/DefinitelyTyped/DefinitelyTyped/tree/types-2.0/d3 Only the types-2.0 branch has been updated (as that is what gets pushed to npm) |
@Ciwan1859 in short as @eamodio just said. With a little background: All definitions for D3 version 4 are contained in the
I.e. The definitions in the old You can look at #9936 for the history of these changes for D3 and the recently updated DefinitelyTyped Readme on the main page for the general background. |
Thanks guys, I'm still a n00b to Git and GitHub and only just noticed that Branch drop down in the top-left. Up to this point, I've been manually adding the definitions files. I'll try your command and see if it works! Thanks again. |
@tomwanzek does the |
@Ciwan1859 the If you are installing the d3 definitions with If you want to use the standard bundle definitions from /// <reference types='d3' />
d3.select('svg'); // Or whatever else your heart desires
... In this latter case, you will have to include the d3 v4 bundle script into your HTML, rather than install/import it. One note of caution, the vanilla script use is only supported out-of-the-box by the definitions for the standard bundle in Hope this helps. |
This PR closes #11367. It is related to #9936. @andy-ms thanks for making this possible!!!
cc @gustavderdrache @Ledragon
The
d3
folder is updated to include a definition file for the Standard D3 version 4 bundle.The definition file allows for using
import
-based scenarios and the use of ad3
global in vanilla scripts using the standard D3 version 4 bundle as a script. It simply re-exports the members of the constituent modules.The legacy definitions have been renamed and left in the
d3
folder or reference purposes.In order to allow definitions of other libraries in DT depending on D3 version 3.5.x to still compile within DefinitelyTyped as well as to have the right dependencies when published to npm
@types
, the following changes where made:package.json
stub with the dependency on@types/d3: "^3.5.36"
(This implies use of the latest published definition file for legacy D3). Dependencies on definitions for other libraries, e.g.jquery
have so far not been added to thepackage.json
. This means that, as before, the type-publisher process will add them in aslatest
.tsconfig.json
files have been updated as necessary to ensure the definitions resolution respects the legacy definition version of D3 in thepackage.json
DT/types-2.0
to support version number parsing before publishing to npm@types
TODO
comment advising of the need to check/update the D3 dependency, if the library gets updated to use D3 version 4.No other changes were made to the affected library definitions.
The following definitions have been updated as per above:
EDIT: Corrected issue reference to 9936 in opening paragraph.