[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 (after all, use ts-jest)
• 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 would like to take the calendar.jsx file in work.

[yuki0410-dev]

@mirus-ua
Modifications to index.jsx may need to be synchronized with modifications to calendar.jsx. (especially the props type)
Would it be ok if I work on it all together?

[mirus-ua]

@mirus-ua Modifications to index.jsx may need to be synchronized with modifications to calendar.jsx. (especially the props type) Would it be ok if I work on it all together?

sure, I think you should wait a bit for the month and the year modules

[yuki0410-dev]

@mirus-ua

sure, I think you should wait a bit for the month and the year modules

I agree with waiting too.
We are moving forward on the calendar.jsx work, but there are some aspects that we cannot move forward on until those are completed.

[martijnrusschen]

apologies, I'm on vacation this week and don't have the ability to review or merge anything until Friday.

…

On Mon, Apr 29, 2024 at 3:15 PM yuki0410 ***@***.***> wrote: @mirus-ua <https://github.com/mirus-ua> sure, I think you should wait a bit for the month and the year modules I agree with waiting too. We are moving forward on the calendar.jsx work, but there are some aspects that we cannot move forward on until those are completed. — Reply to this email directly, view it on GitHub <#4700 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKY2KE7BIGCPH4IGIOERD3Y7ZBWDAVCNFSM6AAAAABGK5XR6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBSG4YTINRRGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mirus-ua]

@yuki0410-dev almost everything was merged, so you can start with the final part

[martijnrusschen]

what's left?

[yuki0410-dev]

@mirus-ua (@martijnrusschen )
I would like to take the week_picker_test.test.js file in work. and fix some types.

[mirus-ua]

what's left?

The core features are done.But I think better to migrate some amount of tests just to double check that all types are OK

[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