discussion: support for TypeScript

[profnandaa]

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:

1. Add types alongside the library (for easy maintenance), as opposed to doing it from DT
2. Find a way of keeping DT up-to-date (uphill task coz of lack of autonomy)
3. [my addition] Have a separate repo here in the validatorjs org 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

[profnandaa]

Cross-ref #789 #247 #662 #1194

[deadcoder0904]

Would love support for this :)

How do I use Tree-Shaking with TS if anyone's got ideas?

I have already installed @types/validator from 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 them

[rcollette]

@deadcoder0904 - I imported like

import isEmail from 'validator/lib/isEmail';

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]

@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]

@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/etc slowly disappears

In 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 allowJS to get you going) and compile expected targets

[rubiin]

This is great. We can do the typescript version. I think the time consuming part is on the creating types @profnandaa

[fedeci]

On express-validator we have some incomplete type definitions that may work well as a starting point.

[rubiin]

On express-validator we have some incomplete type definitions that may work well as a starting point.

yeah that will help

[vlascik]

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]

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]

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.

I don't believe so, but using @types/validator in combination with this package works fine in my projects

[AllusiveBox]

I don't believe so, but using @types/validator in combination with this package works fine in my projects

I missed that. Thanks, I'll let them know and see if that settles them for now.