Make linter work with explicit-function-return-type and no-any

[amaury1093]

After #254, we disabled:

https://github.com/amaurymartiny/shoot-i-smoke/blob/1b0c1ce36a39b5a2781dbe42905ca55c7129a629/.eslintrc.js#L13-L17

because there was too much work in one PR.

This issue is to finish this PR, namely:

• remove those two rules in .eslintrc.js
• add function return types on all functions (most of them are React components, so React.ReactElement will do)
• Remove all instances of any

[Rallph]

Is it alright if I take this issue? I've already started work on it and I don't expect that it will take too long.

[amaury1093]

@Rallph Yes, please go ahead, you have the green light!

[amaury1093]

Hey @Rallph, are you still working on this? Do you need any help?

[Rallph]

Yes, I am still working on it, sorry about the delay. I have run into an issue;

In Screens.tsx there is the following code:

https://github.com/amaurymartiny/shoot-i-smoke/blob/7e8f7060f97620b33cfa3b34d1563c8a032ce0e2/App/Screens/Screens.tsx#L88-L104

The function that calls fadeIn() on line 101 should have a return type of TransitionConfig. However, when I try to set TransitionConfig as the return type, it's unable to be found. It turns out that this is actually an issue in the react-navigation-stack package. That issue says that this bug is fixed in react-navigation-stack version 1.9.3, whereas this project is still using version 1.8.1. So now I have a couple of questions:

1. Should a new issue be created in this project for this outdated version?
2. Should I take the liberty of updating the dependency/dependencies and including the updated package.json and yarn.lock files in my PR?

Otherwise, I don't have any other problems with this task. I've been quite busy lately and I apologize that it's taking so long.

[amaury1093]

and I apologize that it's taking so long

No pressure! Everything is open-source, based on volunteering.

Should a new issue be created in this project for this outdated version?
Should I take the liberty of updating the dependency/dependencies and including the updated package.json and yarn.lock files in my PR?

I know some version of expo works with some particular versions of react-navigation (and therefore react-navigation-stack), so I would not bump that package without some testing.

What I propose:

• For now, you can create a PR with eslint-disable-line and/or @ts-ignore on that line 101, I can merge this PR pretty fast
• And then create a second PR which bumps react-navigation-stack, so that I can test that separately. If everything works, I'll merge this second PR too

What do you think?

[Rallph]

Sounds good! I'll get on it.