feat(typescript): convert js to ts

[tduyng]

Close #28

• Convert js to ts
• Improve some types
• Update examples files
• Create make command to run examples files

[pebie]

@tienduy-nguyen,
Now that we have to build the project, how did you plan to publish the build on npm. It seems that you have test it on your own npm registry. Could you explains how you did that ?

[tduyng]

@tienduy-nguyen, Now that we have to build the project, how did you plan to publish the build on npm. It seems that you have test it on your own npm registry. Could you explains how you did that ?

Yes, I tested it in my own npm.

[fthouraud]

Thank you for your contribution @tienduy-nguyen.

If I may, this work should have been split into several PR to ease the review and track each issue.

Also, why do you replace ava with Jest? 🤔

[pebie]

If I may, this work should have been split into several PR to ease the review and track each issue.

What do you mean ? Split between test, core and build maybe ?

[tduyng]

If I may, this work should have been split into several PR to ease the review and track each issue.
What do you mean ? Split between test, core and build maybe ?

I thinks Fabien want to talk about the separation for steps: travisCI -> Github action, update dependencies, .....

• I tried did it before with 3 different PR, but after all, il will take so much more efforts and time to do the review. So I deleted other PR and put them all here

Also, why do you replace ava with Jest? 🤔

Ava is very light, It's not too bad for an libary npm. But it's syntax is not too familiar. It demands more tools to work completely as sinon and nyc. And debug with ava is less simple.
Meanwhile, Jest is a really good tool. The features are complete. It's easy to use, syntaxe is really well known and familiar. And Jest has many improvements for the performance in recents version.

On another hand, we have a trouble with ava with Github action when we make the comparison the string with color.

So I think Jest is a good choice to replace ava.

[fthouraud]

It should have been done sequentially to keep track of each major modification instead of only two commits covering a total rewrite of the lib, some addition, a new CI system, etc.

The advantage of AVA is especially that it is a lightweight test runner without bringing extra tooling. Also, the fact you're not familiar with the syntax a tool provides doesn't mean it has to be replaced. Regarding Jest's improvements, I'm pretty sure it is unnoticeable for such a small project. This change is purely motivated by your personal tastes instead of actual benefits for the library.

I can't speak for the problem you encountered but as long as AVA was working before I bet you looked in the wrong direction ;)

No hard feelings here, I'm glad you contributed but it should have been focused more on the library and its history.

[fthouraud]

It also relates to this #26.

[tduyng]

It should have been done sequentially to keep track of each major modification instead of only two commits covering a total rewrite of the lib, some addition, a new CI system, etc.

The advantage of AVA is especially that it is a lightweight test runner without bringing extra tooling. Also, the fact you're not familiar with the syntax a tool provides doesn't mean it has to be replaced. Regarding Jest's improvements, I'm pretty sure it is unnoticeable for such a small project. This change is purely motivated by your personal tastes instead of actual benefits for the library.

I can't speak for the problem you encountered but as long as AVA was working before I bet you looked in the wrong direction ;)

No hard feelings here, I'm glad you contributed but it should have been focused more on the library and its history.

OK, thank Fabien for clarifying them. I appreciate that. I'll take the modification.

[pebie]

It should have been done sequentially to keep track of each major modification instead of only two commits covering a total rewrite of the lib, some addition, a new CI system, etc.

Ok to split by commit but do multiple PRs seems to be complicated since migrate TS needs to rework eslint, node modules, ci/cd... And I'm not sure this is possible to split it in multiple PR.

I understand this PR is hard to review so we can split it by commit :

• tests
• core
• tooling

Maybe

[fthouraud]

Why should this be difficult?

This should be perfectly fine in this order:

• dependency upgrades,
• Migrate CI to GitHub Actions #26 & Support and test LTS Node #27,
• Migrato to TypeScript #28.

The dependency upgrade could be included in one of the two MR, but if the code needs modifications, this should not be mixed up with other changes.

[tduyng]

Why should this be difficult?

This should be perfectly fine in this order:

• dependency upgrades,
• Migrate CI to GitHub Actions #26 & Support and test LTS Node #27,
• Migrato to TypeScript #28.

The dependency upgrade could be included in one of the two MR, but if the code needs modifications, this should not be mixed up with other changes.

Thank Fabien for your suggestion.
So now I separated in 3 different PR:

• Update dependencies: Update dependencies #38
• Replace travisCi by github action and support Nodejs LTS: chore(CI): replace travisCI by github action #39
• Js to Ts (only core files): feat(typescript): convert js to ts #31

[fthouraud]

Thank you @tienduy-nguyen for your effort 🙏 This is much appreciated.

This should be included in a major release due to the number of changes and the impact on imports.