Skip to content

[Tech] Let's be even more strict when writing TS code #1761

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 13 commits into from

Conversation

CommandMC
Copy link
Collaborator

@CommandMC CommandMC commented Aug 31, 2022

I've changed some of our TS settings so we're forced to account for more situations that were easy to miss before. I think this will ultimately lead to a more stable experience for our users, at the cost of having to do a bit more work when writing new code

Changes in tsconfig.json:

  • Ordered options based on where they appear in TS' docs
  • Added the following options:
    • allowUnreachableCode: false
    • allowUnusedLabels: false
    • noUncheckedIndexedAccess: true
  • Turned off the following options:
    • suppressImplicitAnyIndexErrors
  • Options that were removed but whose values were set to their default values:
    (Just to clarify, these changes only cleaned up our config file, no functional changes were made)
    • noImplicitThis: Already true since strict is enabled
    • noImplicitAny: Same as above
    • strictNullChecks: Same as above

Use the following Checklist if you have changed something on the Backend or Frontend:

  • Tested the feature and it's working on a current and clean install.
  • Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
  • Created / Updated Tests (If necessary)
  • Created / Updated documentation (If necessary)

These changes mostly boil down to:
- Telling TS we're sure an array member will always exist since we're
  accessing it with an index gotten by `findIndex` before
- Using already defined `window`/`mainWindow` variables instead of
  obtaining them again
- Checking `unknown | undefined` values for being `undefined` first,
  before assigning them to something

The syntax is still a little messy in places, I don't really like having
to repeat `someArray[index]!` all the time. But that's something that
can be improved some other time :^)
@CommandMC CommandMC added the pr:testing This PR is in testing, don't merge. label Aug 31, 2022
@CommandMC CommandMC self-assigned this Aug 31, 2022
Copy link
Collaborator

@Nocccer Nocccer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall.
Still have some questions/suggestions.

@CommandMC
Copy link
Collaborator Author

Arg, got caught by polymorphism here... 0 is of course also false. Now what's the most elegant way to check just for undefined...

These things are quite complicated, not sure why we didn't use the
library since the start
@Nocccer
Copy link
Collaborator

Nocccer commented Sep 2, 2022

Arg, got caught by polymorphism here... 0 is of course also false. Now what's the most elegant way to check just for undefined...

Someone in the internet said checking for null also catches undefined.

@CommandMC
Copy link
Collaborator Author

I ended up just using the semver library, I think some dependency we have already requires it anyways and it's far easier to just use it rather than implementing everything ourselves

@CommandMC CommandMC added pr:ready-for-review Feature-complete, ready for the grind! :P and removed pr:testing This PR is in testing, don't merge. labels Sep 11, 2022
Copy link
Member

@flavioislima flavioislima left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a lot of changes, will test it during the week.
Left a few comments for now.

@flavioislima flavioislima requested review from a team, arielj, imLinguin, redromnon and BrettCleary and removed request for a team October 8, 2022 14:37
@flavioislima flavioislima added the pr:testing This PR is in testing, don't merge. label Oct 8, 2022
Copy link
Collaborator

@redromnon redromnon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

This makes them a little easier to read
I've decided against putting them in a separate file, since they're
used exclusively here. If that changes, having a `constants.ts` file
might make sense

Note that since the Epic Store URL is dynamic, depending on the
language, I've added `$lang` to the string and replace any
occurrences of it with the actual language once the URL
is pulled from the object
Copy link
Collaborator

@arielj arielj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me!

@CommandMC
Copy link
Collaborator Author

Currently waiting on #1887 and #1901 to merge before updating this

@flavioislima
Copy link
Member

@CommandMC will still work on this one?

@CommandMC
Copy link
Collaborator Author

I doubt I'm going to work on it anytime soon, might as well open up a new PR then

@CommandMC CommandMC closed this Dec 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr:ready-for-review Feature-complete, ready for the grind! :P pr:testing This PR is in testing, don't merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants