digdag icon indicating copy to clipboard operation
digdag copied to clipboard

Migrating to Typescript

Open szyn opened this issue 4 years ago • 7 comments

See also https://github.com/treasure-data/digdag/pull/1641#issuecomment-932850649 for details.

szyn avatar Oct 21 '21 13:10 szyn

Can I work on it?

seiyab avatar Dec 07 '21 14:12 seiyab

Sure, no problem at all. I appreciate your help as usual 👍

szyn avatar Dec 15 '21 09:12 szyn

@szyn Which plan is better do you think?

  1. Gradually migrate
    • steps
      1. Make all the codes valid typescript syntax without resolving type errors and lint errors
      2. Gradually collect type errors and lint errors by many small PRs.
      3. When all the type errors and lint errors are resolved, add type check step and lint step into CI.
    • pros
      • can avoid conflicts
      • each PRs will be small and easier to review
      • other contributors can help migration
      • some progress will be commited even if I stop commit for some reason
  2. Migrate in single PR
    • steps
      1. Make syntax, type, format and coding style valid at one PR and check them on CI
    • pros
      • can avoid committing half done codes
      • you will review PR only 1 time
      • can avoid half done migration even if I stop migration for some reason

seiyab avatar Dec 18 '21 13:12 seiyab

Thank you, I feel that 2 is simple and better for me. What do you think?

szyn avatar Dec 31 '21 06:12 szyn

I think each of them is good. I'll try latter one.

seiyab avatar Jan 07 '22 06:01 seiyab

@szyn I found that fixing all the typing error in reliable way is hard. It is similar problem to newer flow that reports too many type errors. Many type annotations are unclear.

So I will add some any, that is unclear type and some ts-ignore, that make type checker skip codes. Do you agree it?

This approach is based on original approach 2, but it also has some flavor of original approach 1.

  • No type error will be reported by type checker after the single PR.
  • So we can run type checker on CI.
  • However, a part of type annotations (any) don't make sense, and even be ignored sometimes.
    • So, After migration, I recommend that request change for PRs that adds more any or ts-ignore to make type annotations more reilable.
    • I'm going to additional PRs that will resolve some part of anys and ts-ignores after migration.

seiyab avatar Jan 10 '22 11:01 seiyab

So I will add some any, that is unclear type and some ts-ignore, that make type checker skip codes. Do you agree it?

Yes, I agree with it. And also it looks good to me for the approach you suggested. Thank you for letting me know 👍

szyn avatar Jan 19 '22 08:01 szyn