[milestone] Convert the library to typescript

[mirus-ua]

Contribution is welcome

Why?

Everything started here from the willing to merge a separate package with the corresponding type definitions into this repo.
The idea is great, but we, as a community, can go further and migrate the entire code base into typescript.

Any benefits?

• only one package to install for end users
• easier to maintain
• your help to the lovely library
• ???
• profit

Our steps to achieve the goal

• extend rollup and rest tools to support .ts and .tsx modules [typescript-migration] initial ts config and the first calendar_container.jsx module #4704
• migrate datepicker modules first
• add a GitHub action to check types @mirus-ua [typescript-migration] add type-check to gh actions #4749
• update docs
• migrate test cases
• use ts-jest @mirus-ua
• migrate docs (optional)

Modules to migrate and how to contribute

Basic rules and advice:

• start with the smallest isolated modules, like calendar_container.jsx
• prevent the use any or other loose types if you don't have strong arguments
• prevent using "slow types", give this option to the end users
• use interfaces instead of types because the large amount of the code base is class-based
• add JSDocs where you can to improve overall DX. Everyone likes a good DX

Steps to contribute

1. Write in the comments the name of the module that you want help to migrate
2. Me or a maintainer will assign your name to the list to prevent doing the same job twice
3. Migrate according to the list of advice above
4. Highly recommended to migrate test cases together with the module
5. Create a PR with a name format [typescript-migration] calendar.jsx etc.

• calendar_icon.jsx [typescript-migration] calendar_icon.jsx #4706
• calendar_container.tsx [typescript-migration] initial ts config and the first calendar_container.jsx module #4704
• date_utils.js [typescript-migration] date_utils.js #4707
• inputTime.jsx [typescript-migration] input_time.jsx  #4708
• calendar.jsx @yuki0410-dev [typescript-migration] calendar.jsx and index.jsx #4766
• popper_component.jsx @yuki0410-dev [typescript-migration] popper_component.jsx #4740
• week_number.jsx @yuki0410-dev [typescript-migration] week_number.jsx #4714
• month.jsx @mirus-ua [typescript-migration] month.jsx #4743
• portal.jsx @Olenka-Yurchuk [typescript-migration] portal.js #4722
• with_floating.jsx [typescript-migration] with_floating.jsx #4709
• month_dropdown.jsx @yuki0410-dev [typescript-migration] month_dropdown.jsx and month_dropdown_options.jsx #4723
• year.jsx @Olenka-Yurchuk [typescript-migration] year.jsx #4756
• month_dropdown_options.jsx @yuki0410-dev [typescript-migration] month_dropdown.jsx and month_dropdown_options.jsx #4723
• tab_loop.jsx [typescript-migration] tab_loop.jsx #4710
• year_dropdown.jsx @yuki0410-dev [typescript-migration] year_dropdown.jsx and year_dropdown_options.jsx #4715
• day.jsx @mirus-ua [typescript-migration] day.js #4713
• month_year_dropdown.jsx [typescript-migration] month_year_dropdown.jsx and month_year_dropdown_options.jsx #4724
• time.jsx @yuki0410-dev [typescript-migration] time.jsx #4726
• year_dropdown_options.jsx @yuki0410-dev [typescript-migration] year_dropdown.jsx and year_dropdown_options.jsx #4715
• index.jsx @yuki0410-dev [typescript-migration] calendar.jsx and index.jsx #4766
• month_year_dropdown_options.jsx [typescript-migration] month_year_dropdown.jsx and month_year_dropdown_options.jsx #4724
• week.jsx [typescript-migration] week.jsx #4725 [typescript-migration] week.jsx #4725

Breaking changes so far:

• newDate helper always returns a date, if the initial params were invalid, then it returns just a new Date Line; PR
• calendarIconClassname => calendarIconClassName PR

[mirus-ua]

@martijnrusschen can you pin the issue?

[martijnrusschen]

Nice progress so far!

[yuki0410-dev]

@mirus-ua ( @martijnrusschen )
Thank you for the great attempt.
I would like to help as well, but should I declare the file to be started on this issue?

[yuki0410-dev]

refs #4000

[martijnrusschen]

@yuki0410-dev Feel free to claim a file and let it know here so there's no duplicate work done.

[mirus-ua]

@yuki0410-dev hello
Yes, grab anything, the only one piece of advice is to pick modules without dependencies or with dependencies only on typescript modules, because it won't be pleasant to combine them later

[Olenka-Yurchuk]

I would like to take the portal jsx file in work

[yuki0410-dev]

I would like to take the week_number.jsx file in work

[mirus-ua]

Added your name to week_number.jsx

[mirus-ua]

6.6% 💪

[yuki0410-dev]

@mirus-ua
I would like to take the year_dropdown.jsx and year_dropdown_options.jsx file in work.

[yuki0410-dev]

@mirus-ua
I would like to take the month_dropdown.jsx and month_dropdown_options.jsx file in work.

[mirus-ua]

@martijnrusschen hello. Please ask reviews to look at four opened PRs if you can. It'll be much faster if we merge them because the rest of the modules depend on them

[martijnrusschen]

Yep, I'll expect them to complete this soon. Normal turnaround time is ~2-4 hours.

[yuki0410-dev]

@mirus-ua
I noticed during my experimentation with #4810 that type errors in the test file do not seem to result in errors in CI.
Is it my understanding that this is due to the fact that I am now using babel-jest to run tests with type information ignored, and that when I change to ts-jest later on, I will get CI errors?

[mirus-ua]

@mirus-ua I noticed during my experimentation with #4810 that type errors in the test file do not seem to result in errors in CI. Is it my understanding that this is due to the fact that I am now using babel-jest to run tests with type information ignored, and that when I change to ts-jest later on, I will get CI errors?

everything is correct

[ryantanrk]

hi, is anyone working on these files? i would like to take 1 of them:

calendar_test.test.js
datepicker_test.test.js
month_test.test.js

[martijnrusschen]

@ryantanrk go for it :)

[ryantanrk]

i'll take month_test.test.js then if no one is working on it 👍

[yuki0410-dev]

@martijnrusschen @ryantanrk @mirus-ua
Converted calendar_test.test.js and datepicker_test.test.js.

[mirus-ua]

What test modules are left?

[yuki0410-dev]

@mirus-ua
#4855 is merged, TS conversion of all test modules is complete.

[martijnrusschen]

Once #4855 is merged, I'll issue a major version upgrade. Are there any type/test changes we want to make once we're fully migrated to TS?

[martijnrusschen]

The issue description says: after all, use ts-jest

[mirus-ua]

Migrate to ts-jest and then go with the major

[martijnrusschen]

Sounds good. On 2 Jun 2024, at 16:36, Mirus ***@***.***> wrote: Migrate to ts-jest and then go with the major —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[mirus-ua]

OK. I'll do then

[mirus-ua]

It looks like I underestimated the amount of work. Almost all tests have types issues, so I don't think that I can do it relatively fast alone

[martijnrusschen]

Is this something that could be split up somehow?

[mirus-ua]

Is this something that could be split up somehow?

I can push the branch with basic config, and then we can use it as PRs target for this activity

[martijnrusschen]

sounds good

[mirus-ua]

I'll do it today

UPD:

#4870

[yuki0410-dev]

@mirus-ua
Just a thought, but if we assign the tests to ts-jest one file at a time in the transform section, can we migrate from babel-jest to ts-jest without causing errors in CI?

[mirus-ua]

@mirus-ua Just a thought, but if we assign the tests to ts-jest one file at a time in the transform section, can we migrate from babel-jest to ts-jest without causing errors in CI?

Do you mean here explicitly add files that we migrated? It could work even if it'll be tedious