[Question] How can we better support TypeScript?

[fireflysemantics]

Trying to use @types/validator and getting errors. I asked the question on SO here. Curious if anyone else is having the same issue?

https://stackoverflow.com/questions/60457757/typescript-imports-for-valiatorjs-failing

[fireflysemantics]

This works:

import validator from "validator"

But that imports all of validator. In version 11 these types of imports used to work:

import { isDivisibleBy } from "validator";

I assumed that this was tree shakeable. I'm using validator in this project:

https://www.npmjs.com/package/@fireflysemantics/is

And each function is a typescript export. If validator is imported as a whole, then all the exported functions will include all of validator. It would be great if they would only include the specific function, but that seems to be enabled for ES6 only ... not typescript ....?

[profnandaa]

I think @types has not been updated with the latest validator.js. I don't know how to go about it, perhaps you might have some idea? This must have been the last PR - DefinitelyTyped/DefinitelyTyped#40491

There's another requests to add our own typing here, perhaps as the primary source of truth; and then mirror it on _DefinitelyTyped`, see conversation in #1194 #789

/cc. @johannesschobel

[johannesschobel]

If you offer own typings, you don't need to add them to DT anymore.

[fireflysemantics]

Hmmm ... I upgraded this library to the latest version of validator using the import I described:

https://www.npmjs.com/package/@fireflysemantics/is

But now I'm getting errors:

node_modules/@fireflysemantics/is/target/is.d.ts:571:62 - error TS2503: Cannot find namespace 'validator'.

So I'm thinking the easiest thing to do is just rewrite the library in typescript and offer a validator-ts package.

Thoughts?

[profnandaa]

@fireflysemantics -- I wouldn't call that the easiest option though...
@johannesschobel -- it looks to me that most libraries have stuck to using DT as a way of supporting TS types, a good example being lodash. I'd generally advocate for having the lib stay on JS, and have TS types supported separately.

[fireflysemantics]

I think I'm going to have a go rewriting the whole thing in Angular Package Format.

https://docs.google.com/document/d/1CZC2rcpxffTDfRDs6p1cfbmKNLA6x5O-NtkJglDaBVs/mobilebasic

This will compile support in for all the popular package formats and provide typescript typing. Did a small write up here:

https://medium.com/@ole.ersoy/creating-an-angular-9-npm-library-1a658ecfa3dc
https://medium.com/@ole.ersoy/unit-testing-your-angular-library-project-with-jest-42429a8716eb

When TS types are supported separately then Typescript is always playing catch up and as a result upstream builds break.

[fireflysemantics]

Here's what the toDate function would look like in Typescript with default exports removed (Because - https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad):

import assertString from './util/assertString';

export function toDate(date:string) {
  assertString(date);
  const millis:number = Date.parse(date);
  return !isNaN(millis) ? new Date(date) : null;
}

This would be exported from the public surface (public-api.ts) like this:

export * from './lib/toDate';

And import goes to:

import { toDate } from './toDate';

from:

import toDate  from './toDate';

IIUC this should produce tree shakeable utility methods.

[fireflysemantics]

#1263

[johannesschobel]

@profnandaa , i wouldn't say, that it is the "go to strategy" to use DT. The major issue with DT is, that it is a separate repostiory where you need to publish your changes. Often, the library repository is managed by the core-developer team, and the DT repository is maintained by the community. So the "DT interface" often differs / does not reflect the current state of the library itself.

I mean - the cleanest (!) solution would be to re-write the entire library in TS and automatically build the JS version from there (i.e., use a GitHub action to build the JS version after every push to master). However, this would be a huge workload 😢

[profnandaa]

Renaming this issue, and converging all TS conversations to this thread.

Calling on #789 #247 #662 #1194

[profnandaa]

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.