Integrate Sorbet type checking

[bensheldon]

It would be nice to integrate Sorbet. I have tried before in #235, but found more sharp edges than I was comfortable with.

Short-term success is having some additional manual tooling and workflows that adds value to the development process and is not burdensome to contributors.

Long-term success would be to run Sorbet type checking as part of the CI lint process (e.g. there is a clean/green state and deviation from that state would fail CI).

[toshitapandey]

@bensheldon - May I give it a try?

[bensheldon]

@toshitapandey definitely! 🎉 I'm available to answer any questions or help navigate. Ask questions here or ping me on https://www.rubyonrails.link/

[bensheldon]

@toshitapandey just wanted to check in and see if can help. I definitely want to encourage you to prioritize an incomplete PR to discuss over perfection. Thank you!

[saksham-jain]

Hey, @bensheldon saw this issue is open for a long time. If someone has not taken it up already can I take it up?
Also need some more description on the same as I am new to this project.

[bensheldon]

@saksham-jain thank you for the interest! unfortunately I don't think this is a good first issue unless you've set up sorbet before. I should remove that tag.

What sort of thing are you looking to help on?

[saksham-jain]

@bensheldon Yes sorbet would be new to me. I would like to start contributing to this project with beginner-friendly issues/features. Once gets good understanding of the project can even pick bigger issues.

[bensheldon]

@saksham-jain Do you want to take #673 ?

[saksham-jain]

Sure @bensheldon. Please assign me that issue.

[dixpac]

I think cons will overweight the pros here for good_job at the current time and size of the engine.

Maybe introducing sorbet without all the type definitions could be beneficial to some degree(ex: catching NameErrors) but going full Sorbet I feel will slow down the development process, and make the pool of potential contributors smaller.

[bensheldon]

@dixpac having gotten #760 to green, I think we're pretty closely aligned.

I'd like GoodJob to be tapioca-able in the parent application (and this repo be srb tc passing) but I'm not planning to add explicit type definitions to GoodJob (eg not typed: strict). And I don't even think I can get GoodJob to typed: true without runtime type hinting, which I'm ignorantly reluctant to do.

As for contribution-friendliness, I realize that potential devs may self-select never to open a PR if they think they can't carry it to completion, but that's not how I maintain this repo. I love for folks to contribute what they can and then I can assist it over the finish line.