There are a lot of typescript projects now, hoping to provide a typescript definition
someone should do it. i can't.
I do not know typescript i have no reason to learn it as of now.
If you know typescript please do it i will add the file where needed.
Someone should also then mantain it.
Is providing a typescript definition mandatory to make it work on typescript?
Is there anything that generates type definition from jsdoc?
I'm using https://www.npmjs.com/package/@types/fabric which seems to work OK
Import is:
import * as fabric from 'fabric';
I set it as an external module in Rollup (so load the minified fabric.js build as normal in the browser)
is based on fabricjs 1.5
May lead to errors with new versions.
Thanks, yes I'm so far just using core features that haven't changed so it's working for me. It would be nice to have "official" versions but I'm guessing if someone is maintaining them they will be updated soon enough and not everyone is going to be using Typescript to make it an urgent priority.
well the point is that javascript is still a losely typed langauge.
Is not an issue for me at all, i could produce a file that says that everything is Any
I think that who wants to use typescript should create one and mantain it as long as he want.
I do not feel like is a feature at all.
Maybe because i do not use typescript.
Typescript is a superset of Javascript with types added, while you can definitely use "any" for things, doing that doesn't really give you the true benefits (like type-safety and intellisense).
It's really easiest if things are coded in typescript but is still valuable for a lib with a large API to make it easier to consume. As I said, I can understand it not making sense for you to add or support it though.
i do not have time really.
Also i think that in some points can be also problematic.
For example i like to use transformPoint passing a fabric.Point or a simple Object.
I wonder if that is still possible with a type definition.
Yes, you can define a signature as accepting multiple types, e.g.
function doSomething(whatever : fabric.Point | fabric.Object)
put help wanted label, whoever wants to do it will do it.
@CaptainCodeman @leehavin since you are typescript users, you are good candidates.
Still no update at DefinitelyTyped/DefinitelyTyped#19911.
just to be clear, i have no time or skills to do it. We need a contributor
There is potential problem with custom builds, but it's probably good idea to include all possible typings no matter the actual build looks like. (Just have encountered problem with named getters/settetrs which have been removed by default.)
I did have a look at doing this but none of the JSDoc -> Typescript Definition tools I found worked.
Doing it manually isn't really an option as it will probably get out of sync if it isn't an automated part of the build system (where we are now with the current typings).
I would not trust our JSDOC entirely.
Oh wow but this can also just be a JSDOC template maybe?
need to check this idea.
Yeah, it's possible the errors were issues in the JSDoc content so it may be worth pursuing further. I didn't have a ton of time to spend on it unfortunately.
I figured "convert all the source to typescript" probably wouldn't fly as a suggestion although there are probably some strong arguments that could be made - it'd be quite a chunk of work to do.
Most of our JSDOC documentation have the @param and @return statement.
The one not updated, or wrong need to be fixed anyway.
Regarding the idea i was talking about look here:
https://www.npmjs.com/package/tsd-jsdoc
i would be more than happy to fix all the JSDOC and as a side effect get a .td file auto created by the build script.
@rebendajirijr
Once i see a TD definition how it does look like, could it make sense to include it over every function similarly to jsdocs, like this
/* TYPE_SCRIPT_DEF .... td definition ... */
So that at build time, with a custom build or not, we can remove everything from the js file, and build the .td file using reg exps?
It didn't occur to me to try to use the jsdoc. It may work, but might not be a great experience.
I appreciate the desire to avoid the definition getting out of sync with the API, but the API in fabric won't change too much now that 2.0 is out & stable, right?
Having some tests run as part of the build can help catch drift. The tests can verify that some standard code compiles (and, even better, that some invalid code doesn't compile!). So the test isn't actually running the code written, instead the test takes that code and feeds it through the TypeScript compiler. Really the "compile" in this case is more a "type check".
I haven't jumped in to fabric 2.x yet as I've been busy with other things. I guess we're not worrying about trying to create 1.x definitions here so I'll get up to speed on 2.x in the near future (migrating our app to it I suppose) and then see what I can do to contribute.
Maybe we can use the one from DefinitelyTyped as foundation and change it to match Fabric 2.0?
Changes to the API would be a manual task, but these should be rather rare.
And we could optimize the definition file over time.
And how should the imports look like?
import { Canvas, Circle } from "fabric";
or import { fabric } from "fabric";.
I use the first one (as it was with @types/fabric 1.5.29), the second is @types/fabric 1.5.30 (which doesn't work with fabric 2.0 anymore)
import { fabric } from "fabric"; i use this when i use babel imports
I think I'll have a first draft ready on the weekend. This will contain some basic types and interfaces (Canvas, Object, Triangle, ...).
I'll commit (and improve) this here: https://github.com/JPAhnen/fabric.js/tree/typescript-definition
cool! i ll make questions on the or so i get in touch with the topic
I pushed the first draft. Next important things I will add are Canvas and Image/ImageOptions.
I marked all places where I had to use any with todo (mostly parameters/return types where I couldn't infer the type easily).
Further discussion can be done in my Repo.
can't you start to open a PR? would be very easier for me
@JPAhnen What do I hope I can help you?
There are many todos in the definition, mainly where I had to use any. Fell free to to replace them by the correct type if you know it.
There is a lot of very recent work happening at the DefinitelyTyped project. Is it still based on 1.0 or have they updated it for 2.0 now?
https://github.com/DefinitelyTyped/DefinitelyTyped/commits/master/types/fabric
They are still old. For example Object.getScaledWidth() is still missing.
we have our unmerged file for it.
I sincerly have no time to mantain it or finish it, but if someone has
will, we have a draft, keep updating is something can be done later
On Thu, 21 Jun 2018, 09:41 crazyfx1, notifications@github.com wrote:
They are still old. For example Object.getScaledWidth() is still missing.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fabricjs/fabric.js/issues/4507#issuecomment-399007075,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABI4QH3XP7X-BS0WdO9BnZ3AlDrPW9oPks5t-04vgaJpZM4Qrle4
.
Which typescript definition should be used?
we do not have any. No one ever did them.
Looking for a jsdoc to dts converter.
On Mon, 4 Mar 2019, 10:20 wstaelens, notifications@github.com wrote:
Which typescript definition should be used?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fabricjs/fabric.js/issues/4507#issuecomment-469177710,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABI4QL-VA1bYoqZq75cbmoK2rf5mK2XQks5vTOVVgaJpZM4Qrle4
.
I've found this, but seems old: https://www.nuget.org/packages/fabricjs.TypeScript.DefinitelyTyped
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
someone should do it. i can't.
I do not know typescript i have no reason to learn it as of now.
If you know typescript please do it i will add the file where needed.
Someone should also then mantain it.
Is providing a typescript definition mandatory to make it work on typescript?