Skip to content
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

Support TypeScript #28

Closed
isergey opened this issue Jul 17, 2018 · 25 comments · Fixed by #177
Closed

Support TypeScript #28

isergey opened this issue Jul 17, 2018 · 25 comments · Fixed by #177

Comments

@isergey
Copy link

isergey commented Jul 17, 2018

Thank you!

@sbarfurth
Copy link
Collaborator

What type of support would you want exactly? This will run perfectly fine inside TypeScript, at least in theory.

@Azael05x
Copy link

He probably meant to provide typings (@types/v8n)

@isergey
Copy link
Author

isergey commented Jul 18, 2018

Azael05x is write. Needs @types/v8n for compile time type checking.
https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

@sbarfurth
Copy link
Collaborator

I've submitted declarations for publishing.

I will update with the status here!

@imbrn
Copy link
Owner

imbrn commented Jul 20, 2018

Thank you so much @sebastianbarfurth. Very great job!

@imbrn imbrn added this to the v1.1.0 milestone Jul 20, 2018
@lazarljubenovic
Copy link

If the types are official, there's no reason to use @types. Just inclide the .d.ts files in the repo itself. Then there will be no compatibility issues and we'll know it's always up to date. You only install one package - if you're using TS it just works and if you're using JS it's ignored.

Better yet, rewrite the whole thing in TypeScript ;)

@sbarfurth
Copy link
Collaborator

sbarfurth commented Jul 21, 2018

@lazarljubenovic According to the docs the @types approach is favored for non TypeScript applications, so I'm trying to go with standards here. I do see your point, I believe rewriting to TypeScript for the core is useful anyway. When that happens the types can move into the project.

For switching to TypeScript @imbrn would need to agree. It's a fairly simple switch, if we wanna do it I can probably do it today or tomorrow. It's especially nice because it introduces no changes to the resulting code, it's merely a help in development and makes everything work a bit smoother.

@sbarfurth
Copy link
Collaborator

I actually feel like converting to TypeScript sooner rather than later would be a good thing. Just as an aside.

@imbrn
Copy link
Owner

imbrn commented Jul 21, 2018

Go ahead and do that! This is the last thing we need to do before releasing version 1.1. 🎉🎉

@sbarfurth
Copy link
Collaborator

I'm nearly done, but I can't find a way to make type definitions for a Proxy based approach, since the names of functions aren't known.

@imbrn
Copy link
Owner

imbrn commented Jul 22, 2018

Maybe we should keep this feature out of the next version, and then we can think about it better.

@sbarfurth
Copy link
Collaborator

@imbrn Yeah, I wanna do docs first and I will go ahead with this for 1.2.0.

@imbrn
Copy link
Owner

imbrn commented Jul 22, 2018

@sebastianbarfurth This library has a lot of dynamic behavior, and I think this is great. So, we really need to talk about how we can make this work for TypeScript. Maybe it needs some code refactoring to make it a little less dynamic, but this is something we quite need to discuss before though.

@imbrn imbrn removed this from the v1.1.0 milestone Jul 22, 2018
@sbarfurth
Copy link
Collaborator

I agree. I have done a lot of work on this with TypeScript and it adds a lot of consistency and insight into code quality, but the dynamic parts are hard to represent. Will revisit for a later version.

@imbrn
Copy link
Owner

imbrn commented Jul 22, 2018

Ok

@sbarfurth
Copy link
Collaborator

Removing this from 1.2.0 since this requires some additional refactoring before-hand.

@imbrn imbrn added this to the v1.4.0 milestone Sep 8, 2018
@Raiondesu
Copy link

Awesome library!
In order to properly type it, it needs to create a separate context for custom rules (upon calling the extend function), instead of a global variable, as it is now.

Everything else is perfectly typable.

@BottlecapDave
Copy link

Is there any update on this? I'd love to use it, but lack of typings is a bit of a deal breaker for work related projects

@trevorr
Copy link

trevorr commented Jan 3, 2020

@BottlecapDave I felt the same way regarding this being the best library I could find for fluent validation, but I didn't see a way to easily address this Typescript issue and (perhaps more importantly) the lack of human-readable error messages. Therefore, I created a new one: https://github.com/trevorr/tsfv. Maybe it will meet your needs.

@iampervaze
Copy link

Awesome lib, but not been able to use it with Angular 8. Looking forward to the typescript version. Thank you!

@lazarljubenovic
Copy link

You can use it with any framework, you just won't get types.

@iampervaze
Copy link

iampervaze commented Jan 10, 2020

Using v8n with Angular
https://stackblitz.com/edit/angular-ymlf4z

@GustavTaxen
Copy link

Has there been any progress on this lately?

If Typescript support isn't coming soon for v8n, I'm afraid that we'll have no choice but to switch to a different validation toolkit.

@sbarfurth sbarfurth mentioned this issue Nov 10, 2020
3 tasks
@sbarfurth
Copy link
Collaborator

@GustavTaxen and the rest: Just created #178.

@joeldesante
Copy link

Hi, just so you all are aware. I've forked the repository and published a version of it (with very basic typings) to npm under the name v8n.ts
https://www.npmjs.com/package/v8n.ts

My intentions are for this to be a temporary package that should be deprecated once this issue is resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment