Add TypeScript typings

[eioo]

Resolves #13
TypeScript typings would be nice for this package. I personally try avoiding "any" as much as I can. It's also nice to get autocompletion for the new options this package offers.

[Kequc]

The two parameters appStringcase and dbStringcase can also include functions.

[Kequc]

In general I'm not happy with adding typescript definitions with this implementation because it means at least one additional dependency that only serves typescript users. The utiliy of this change seems fairly inconsequential because this library is essentially just doing configuration.

What I mean is, that while I understand that it's nice to have thorough autocompletion. It isn't needed when it's only used the first time you implement knex-stringcase into your configuration. And even then only if you are using typescript.

Is there a way to have a much looser implementation that doesn't force dependencies?

[eioo]

You're right. The implementation was pretty bulky because of the dependency, the types package was also depending on knex package itself. @types/knex seems to be unmaintained anyways.

I made knexStringcase() generic and added usage example for it in README.md, let me know what you think.

[Kequc]

That's a lot better thank you. I believe parameters appStringcase and dbStringcase are still incorrect as it can be a string, or a function or an array of strings, or an array of functions, or a mix of both.

[eioo]

That should do it. "Stringcase" and "StringcaseFn" probably could have better names but didn't came up with any. But hey, now it works! 👍

[Kequc]

I've decided not to support typescript on this project it's unnecessary.

[shellscape]

Having a contributor go through all of those steps just to decide at the very end that you're not going to accept their work is a really bad look. At the very least you should have given them a detailed apology in return for their time.

@eioo thank you for your work on this. I'm going to put it up on a public gist to preserve it in the event your fork goes away one day. solid work.

[Kequc]

It has remained here for over a year why would the fork go away. How cordial do I need to be in order not to get hounded by Typescript users. I think I explained in quite a lot of detail why it is unnecessary.

You're trying to guilt me and if I'm completely honest you're baiting me, why is that a good look and not how I cared for this merge request?

If this feature is updated to use the newest patch version I'll merge it.

[shellscape]

Maybe something is lost in translation on this one - it doesn't appear that you receive critical feedback well. If you perceive criticism regarding contributors and your behavior towards them as guilting, baiting, etc then open source may not be for you. You don't have to agree with feedback, but to suggest something so dramatic as "baiting" is juvenile.

Regardless, I'm disengaging from this project.

[Kequc]

Thank you for your critical feedback, which was to pamper people with pleasantries. It's ok if you call repository owners juvenile though.

[acro5piano]

I'm really glad to see the migration to TypeScript on v1.5.0. Nice work! Thank you @Kequc

[Kequc]

I came to realize Typescript should basically just be everywhere. Node has recently realized this too now Typescript seems to be supported out of the box. Unfortunately there's issues here with the import that I was not able to fix, but I'm sure we'll figure it out in time.

Might be just a named export instead of a default export is the way to go with libraries like this. Thanks!