Repository navigation
discussion: support for TypeScript #1271
Description
This is a fresh take at #1261
Re-posting my initial thoughts:
So, a rewrite is out of question. Looks like viable proposals we have right now are:
- Add types alongside the library (for easy maintenance), as opposed to doing it from DT
- Find a way of keeping DT up-to-date (uphill task coz of lack of autonomy)
[my addition]Have a separate repo here in thevalidatorjsorg specifically for types (which can be mirrored with DT)
Personally I'm leaning towards 3. I'm also trying to:
- protect a small footprint for the library.
- be less disruptive with what we already have.
- keep supporting those who already were using DT (
@types/validator).
Let me know what you folks think.
/cc. @tux-tn @johannesschobel
Activity
profnandaa commentedon Mar 22, 2020
Cross-ref #789 #247 #662 #1194
deadcoder0904 commentedon Apr 14, 2020
Would love support for this :)
How do I use Tree-Shaking with TS if anyone's got ideas?
I have already installed
@types/validatorfrom DT & would love to incorporate tree-shaking as well with it.It currently gives errors if I directly use it from
es/*libraries as they don't have types associated with themrcollette commentedon May 6, 2020
@deadcoder0904 - I imported like
That's as small as you'll get for tree shaking with TS alone, otherwise you need Webpack or something similar to get tree shaking.
rcollette commentedon May 6, 2020
@profnandaa - I'm curious why the comment about not wanting to rewrite. JS is TS. There shouldn't be a need to rewrite anything.
You could just rename the files to TS and apply type information. You have the option to compile to multiple targets if you want ES5, etc.
If you don't want to write TS at all, you could use JSDoc, perform type checking with the compiler to ensure usage is consistent, and generate type declaration files from the .js
https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html
https://voxpelli.com/2019/10/use-type-script-3-7-to-generate/
AubreyHewes commentedon May 8, 2020
@profnandaa You should not mirror own types to TD.. TD started as a repo of libraries that had no types. (read npm packages without types). It is not "the repo for types". The idea is that packages provide own types (authored by the package) and that TD /
@types/etcslowly disappearsIn the next version that has own types.. simply supply the types within the package.. anyone using TS will, after installing the package, have your types.. and will not need to install from
@types/etc.. having to also install types from TD should be seen as a bad practice and can also introduce other problems (type packages with dependencies).One thing you definitely do not want to do is keep a separate repo/branch with type definitions that need to be updated with each master source change.. I agree with @rcollette just move to TS (possibly with
allowJSto get you going) and compile expected targetsrubiin commentedon May 14, 2021
This is great. We can do the typescript version. I think the time consuming part is on the creating types @profnandaa
fedeci commentedon May 14, 2021
On
express-validatorwe have some incomplete type definitions that may work well as a starting point.rubiin commentedon May 14, 2021
yeah that will help
vlascik commentedon Oct 3, 2021
You already have a near complete rewrite at https://github.com/fireflysemantics/validatorts/ . Merge it here, replace that weird angular build system with tsc to create ambient declarations, use babel to generate es5/es6 etc. packages, and that's it. You can see an example of that e.g. here https://github.com/microsoft/TypeScript-Babel-Starter, but I'm sure more examples exist.
Every other solution is just pointlessly complicating things.
AllusiveBox commentedon Feb 25, 2022
Curious if there was any decision actually made on how to go about using this? I am trying to argue for using this package instead of an internally managed one for work and they don't want to make the switch if there isn't any TypeScript support.
WikiRik commentedon Feb 25, 2022
I don't believe so, but using
@types/validatorin combination with this package works fine in my projectsAllusiveBox commentedon Feb 25, 2022
I missed that. Thanks, I'll let them know and see if that settles them for now.
tux-tn commentedon Feb 25, 2022
Agree with @WikiRik ,
@types/validatorshould cover all your needs.adamgen commentedon Jan 27, 2023
We can actually support types in a much better way.
DT offers type safety for the writing of the schema itself, however you cannot infer the end object's type from the schema like you can with other TS first libraries.
I've made a demo showcasing how we can easily infer types from our schema.
@profnandaa I'd like to hear your thoughts.
6 remaining items
WikiRik commentedon Feb 4, 2023
I think that it might be better to open a PR here that changes the infrastructure so that both TypeScript and JavaScript (including possible .d.ts files) are supported and we can migrate from JavaScript to TypeScript incrementally
rubiin commentedon Feb 4, 2023
@WikiRik maybe you can start a PR and I can add in the changes. How does that sound. I am happy with either way
fedeci commentedon Feb 16, 2023
For me the most viable solution is to convert the entire library to use TS. It is safer because of typings, prevents having to define types separately and it is quicker to understand the code for new contributors. I honestly cannot see drawbacks in adopting it.
adamgen commentedon Feb 19, 2023
I have to take a step back from what I've proposed since it doesn't fit with the current state of validator.js. However, I'll take a few steps forward down the road.
Going type-heavy on validator.js in its current form will bring little to no value.
That's because the validator.js returns mostly primitive types. And a complex type system with inference, as zod has, is only relevant for schema validation, not for primitives. This gap between primitive vs. schema validation brings me to my next point.
Why wouldn't validator.js validate schemas? It already does on express-validator, where @gustavohenke has done a great job.
Now I'm entirely out of my domain with what I'm about to suggest, but this is how it goes.
I suggest having the schema validation already done by @gustavohenke in express-validator to be merged/combined with validator.js. Only then adding the inferred types I proposed earlier.
It'll be freaking awesome if you ask me. It'll give not less than scores of developers a lot of validation*type power without installing additional dependencies or migrating to new code, which I've found myself doing on a large project that maintained.
Also, I can be completely non-breaking, and since 80% of the work is done across the board, it requires a low time investment.
The 2 points above make a good open source ROI.
Is it too crazy? Is opening a new ticket for it will be a waste of time? Is there no PR that can move the needle forward on this topic?
ffxsam commentedon Apr 21, 2023
I have one request if validator undergoes a major update:
Please simplify ESM tree-shaken imports:
validator/es/lib/isEmailis a bit inconvenient and clunky. The syntax I suggested will bring this package up to modern standards.ST-DDT commentedon Sep 1, 2023
@profnandaa / maintainers: What are your requirements for a community powered TS migration?
@types/validatorjs)I assume that there are quite a few community members (in addition to me) that would help with the migration itself.
We just need the requirements and an "go ahead".
WikiRik commentedon Sep 16, 2023
@ST-DDT indeed minimal breaking changes, but I want a major release either way when we ship our own types so it's clear to the users. I'm willing to update types if needed after we have merged a PR that copies the .d.ts files of @types/validator. And then preferably slowly migrate from .d.ts/.js files in the source code to .ts files
ST-DDT commentedon Sep 16, 2023
I understand that and it sounds reasonable.
Is there a good time to start the process (as an external contributor) or do you have your own roadmap for that change?
WikiRik commentedon Sep 16, 2023
As far as I know there is no roadmap, but it would be good to have approval from @profnandaa @tux-tn on a possible roadmap before we start executing it
rubiin commentedon May 9, 2024
@profnandaa maybe its time to ship our own types file like most libs do #2398
rubiin commentedon May 9, 2024
This might be a plan for v14. We maybe be opting to new modern tooling that provides a seemless transition from what we are using
profnandaa commentedon May 9, 2024
pano9000 commentedon Aug 25, 2024
after spending some time with TypeScript the last couple of months, and definitely feeling the benefits of using it (from a DX point of view -> from a user point of view, you don't care if JS or TS -> you care about "bug free" or buggy :-)).
I wonder, why the initial post states "So, a rewrite is out of question."
It shouldn't be too much work, honestly -and it would make development experience a lot better IMHO and less error prone. IMHO some of the bugs in isDate for example, would likely have been prevented if TypeScript was used.
This would of course not be something for v13, but a major change.
Only thing holding this back of course is the ton of open PRs
Just droppping my 2 cents here :-)
ST-DDT commentedon Mar 24, 2025
Since we just had a release. Would it be wise to consider this (a v14) for the next release?
WikiRik commentedon Mar 24, 2025
Give me a month or two to get more PRs reviewed/merged and then I think we can start on working on this