Gastón Fournier
7aed1e0d13
chore: gradually reduce null-check errors ( #3094 )
...
## About the changes
In order to move us towards enabling `strictNullChecks` we'd want to
have a way of gradually enabling this without having to fix all errors
at once, this will force us to start reducing the number of null check
issues.
This new workflow:
1. [Checks out the current branch and main into 2 different
folders](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR15-R23 )
2. Uses the **same** script `gradual-strict-null-checks.sh` (from the
current branch) [against each folder in
parallel](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR34-R38 )
to count the number of errors if `strictNullChecks` was enabled
3. If the number of potential errors in the current branch is higher
than the number of potential errors in main [it
fails](https://github.com/Unleash/unleash/pull/3094/files#diff-068f2ace1d1d2e773fb5e4240c83ccab251556fd5524fe13847122878e40da3bR41-R46 )
As an example, a [new issue was introduced in this
PR](753f57223c
)
(and then
[reverted](e4deb62965
)),
so we can test the build failure:
https://github.com/Unleash/unleash/actions/runs/4163632636/jobs/7204268519#step:5:10
## Discussion points
This could be a non-mandatory check, just advising, or even adding a
comment in the PR. It might be good to start with a non-strict check,
but at the same time we can decide to make it non-strict if a problem
appears
In some situations, an additional null check error might require us to
fix a bunch of them, increasing the time to deliver. In these cases we
can suppress an individual line with `// @ts-ignore: Object is possibly
'null'.` although might defeat the purpose of this workflow
2023-02-14 15:52:21 +01:00