mathjs in Typescript

[husayt]

Hi Jos,
Just wanted to ask your opinion regarding switching matjhs to Typescript? Obviously there will be a cost to this, but when it's done it will be a win for JS users as well as for TS users. Also considering the size of the library, that will help to grow it further with minimal errors, as TS helps weeding out lots of nasty bugs.

If this is something you feel positive about, I will be happy to help.

[EricCrosson]

I've been looking through the issues to determine the current state of TypeScript support. I see pointers to the @types/mathjs definitions on DefinitelyTyped, but the latest version of mathjs with type definitions is major version 6, 2 major versions behind and nearly a year out of date.

I agree with @husayt, an implementation in TypeScript would provide numerous benefits:

• less chance of introducing bugs or regressions
• would clean up the third-party type definitions (pretty wonky to work around currently, numerous type unsafe type annotations are required for the overloaded functions)
• net increase in development speed
• easier for new contributors to get up to speed
• types would never be this out-of-sync with the underlying implementation again
• boost in quality of tooling to assist with refactors

Relevant issue re out-of-date DefinitelyTyped definitions: https://github.com/josdejong/mathjs/issues/1539

[josdejong]

Thanks for your suggestion @husayt. I'm positive about looking into converting the code base to TypeScript.

I expect that this will not be easy. There is quite some special stuff going on with dynamically creating functions. mathjs has these typed-functions which define (runtime) types for example, and generates index files based on factory functions etc. I can imagine getting all types right can be hard, and may become verbose, forcing you to write types twice and ending up with unwieldy generics to make stuff work. Maybe we want/need to make changes in the architecture to make mathjs play nice with TypeScript.

I think it would be good to first investigate what is required to get TypeScript into the code base, and then decide on if and to what extend we would like to integrate TypeScript. TypeScript can add value, but it also comes at a cost.

A pragmatic short term solution of course is to get the type definitions of @types/mathjs on par.

Anyone interested in picking this up?

[husayt]

@josdejong I am happy to start with this. Yes, it will take time to switch fully to Typescript. But the good thing with TS is that this can be done gradually and without breaking everything. As JS is TS we can start with very loose tsconfig and then try to introduce types, and as we are we are doing that we can switch to more strict settings. This will happen without breaking things. If there are any breaking changes required we can leave them to the end. Then we can decide if they should come in v9.x or not. This way most of the changes can be done as part of v8 i.e. nonbreaking changes. If you are happy with this approach I can do the first step.

[harrysarson]

If I may chime in, there is value in not needing a build script. It looks like we do still use build scripts to convert the files in src to files in lib but if I understand correctly this is a temporary measure whilst we work out how to get ESM working properly in node.

A nice feature of some javascript libraries that we should (I believe) aim to support is that a library can beimported "as is" and transpilation is a extra step if you need the library to run in an old browser (babel inserts shims for IE11 for example) or want to optimise (download size etc).

[josdejong]

Thanks @husayt! Yes it's very nice that we can implementing TypeScript gradually. But let's first do an experiment to investigate all the bears we will encounter down the road and have a clear view on how the code base will look like in the end. Then make a clear plan, before we start for real.

A first small, pragmatic step I think would be to improve the existing type definitions. That will yield a lot of value with very little effort.

@harrysarson I think we cannot get rid of the build tools any time soon. Part of it is to build ESM, CommonJs, and bundle output, but an other part is to generate index files (see the src/generated/* files). I'm looking forward to just having ESM though :).