re-base
re-base copied to clipboard
tylermcginnis
Typescript definitions clarification
I'm writing a definitions file for re-base and I just wanted to clarify something about the options objects that several of the functions take.
In the fetch documentation the options object should have a required then paramater that is a callback, however in the next example down there is a promise implementation that has no then function and executes like a standard promise.
Is this just a docs issue?
@TheHandsomeCoder yeah that is wrong its not required. It used to be in the past and missed updating it.
No worries, I'll keep an eye out for anything else and I'll post it here I guess.
Also would it be better to submit the types here or to definitely typed?
@TheHandsomeCoder yeah that would be great. working on cleaning up the docs for 3.x so that would be awesome if you see any other mistakes. That is a good question about location of the typings. This is an area I am not familiar with so any guidance would be greatly appreciated.
As a typescript user which do you prefer? If they are here then I think there needs to be tests that would fail if the code changes and the type definition is off because of the change. Or vice versa. If someone were to submit a new helper method to the library, it gets merged and published with a minor version bump and that new helper didn't exist in the type definition would that break your app?
I wouldn't want to break your app, but I also don't want to make it harder to contribute for someone who isn't familiar with typescript.
So the publishing section on Typescript lists two ways it can go, first is to self host and reference it in the types/typings property in package.json the other is to pusbish to the @types org on npm.
I'm currently writing then types under DefinitelyTyped and I'm including a tests file as part of this.
I've only been using typescript a few months so I'm not 100% on what's then prefered method. I use VSCode for all my .ts dev and it pulls in the types for me automatically, so for me either is fine. I guess however that if they're packaged with the library there is less chance that they'll be broken as the tests can be run at deploy time.
I'll look to do some research and report back