Add TypeScript type definitions about keyv HOT 8 CLOSED

To prevent definitions going out of sync we should either include some sort of test to validate the definitions or alternatively they be generated from our source (annotated comments?).

I saw the previous discussion, but by far the easiest way to do this is rewriting the source in TypeScript and enabling "declarations" in the compiler options. tsd can be used to validate, but doesn't really solve the problem of them going out of sync as the -test-d.ts also has to be updated.

If you've had any change of heart, I've got no problem doing the rewrite and configuring tsc.

from keyv.

Thanks for the offer @caseyWebb ❤️

I kinda figured that was the only maintainable solution.

Tbh I've had a little play with TypeScript and wasn't really sold on it. I didn't hate it, I just didn't really "get it". I'm still open to it.

I'm interested in the idea, but I have some worries:

1. You port this codebase to TypeScript, I don't like it, don't accept your PR, you feel like you've wasted your time.

2. You port this codebase to TypeScript, I like it and merge, you disappear, future maintenance becomes much harder (I'm already struggling to find the time) because I'm not as familiar with TypeScript.

There is also the issue that if we re-write this in TypeScript we should probably re-write all storage adapters in TypeScript too.

What are your thoughts?

from keyv.

On the concern of not merging, no harm no foul. This codebase will take 15 minutes, tops.

On the concern of maintainability, it's actually a pretty easy out in worst case scenario. Set the tsconfig.json target to "esnext", transpile, replace the source with the output JS. It will be identical with only the types missing.

I'm more than willing to work on the adapters as well, as while not crucial I do agree that they should all be done. Have you considered/would you be open to a monorepo?

One more thing to note, not being sold on it is a common thread among people. 3 things I like to point out:

1. your consumers will benefit far more than you will; they won't need to continually hop back and forth with the documentation, and it makes discovery a lot easier.

2. if you weren't using compilerOptions.strict, you're missing the vast majority of the benefits afforded. Non-strict TS may as well be JS.

3. it makes eslint way more powerful when used with @typescript-eslint, as it can catch annoying things like unhandled promises via the type information.

from keyv.

You are definitely selling it to me.

Have you considered/would you be open to a monorepo?

I've not been a fan of them historically but this current setup with dependencies spread across repos is definitely not ideal. If you can demonstrate a better solution using a monorepo then I'd be interested.

The maintenance issue is the only thing really worrying me, as I mentioned before I'm already struggling with time as is. Extra build steps and stuff I'm not familiar with, while probably simple to learn, is just extra stuff eating away at time I already don't have a lot of.

How interested are you in this project? Is this a one time contribution you want to make or are you interested in sticking around and becoming a maintainer?

No pressure to commit to anything you don't want to, I just wanna know if I'm gonna be accepting extra maintenance burden by accepting these changes.

from keyv.

If you can demonstrate a better solution using a monorepo then I'd be interested.

Challenge accepted 😉

I totally get the maintainability concerns. Tbh I've almost used keyv in a few projects but the lack of solid TS support led to me rolling my own solutions, so I'm more than willing to maintain it long term. As far as having to learn new stuff, my goal is always to have everything you need exposed via npm run scripts, optionally with docker support if it makes sense; so you, as well as any new contributors, should be able to clone, npm run build, npm test, and expect all green.

I'll do the refactors in a fresh monorepo (with git history maintained) as it makes it a lot easier during active development (esp with regards to docker... it doesn't like npm link), and then it can be decided whether or not to keep them together or cherrypick the changes into the respective packages.

When I've got at least two packages I'll push them so you can get an overview of the proposed architecture and see how you like working in it.

from keyv.

Thanks @caseyWebb, this sounds really great.

my goal is always to have everything you need exposed via npm run script

Ah, a man after my own heart!

Look forward to seeing what you produce!

from keyv.

It would be better to just define the types: http://blog.wolksoftware.com/contributing-to-definitelytyped

Casey - More than happy to help you with this.

from keyv.

Going to close this out as the fix should be to move to typescript or add in the definition.

from keyv.