[WIP] RxSwiftExt & RxCocoaExt Action Checklist

[freak4pc]

This continues discussion from #124, but decided it would be better to start a clean one since this is already "Calls to Action".

I'm assigning myself as I'd like to do many of the things here myself, but would love help on things related to Carthage and SPM since that's not my expertise :)

Here's the current checklist I have in mind.
Please feel free to comment and help me perfect this before I get started on making some work - hopefully before the weekend.

RxSwiftExt + RxCocoaExt (Single repo) checklist

• Suggest folder structure for all components (Source/RxCocoa is great, but do we want more internal folders to separate ControlEvents, Operators, etc?)

  Something like this might work (just a suggestion of course needs more discussion)

    - RxSwift
        - Operators
        - Common (or Core or Observables or something to describe non-operators)
    - RxCocoa
        - Operators
        - ControlEvents (or `UI`, or `Components` or something to describe non-operators related to UIKit/Cocoa extensions)
    - Common (rename Tools, just my personal preference Tools are more like scripts and not Helpers or Common shared code) - Common helpers that support both Pods
  

• Create a new RxCocoaExt subspec that would match the Source paths described above

• File name convention - Proposed and approved in Decide on File naming for RxCocoaExt(s) and RxSwiftExt(s) #131

• Swiftlint - Going to add the base and then make custom adjustments based on our current code base, and will refine from there [Swiftlint #128]

• Danger - Danger is super crucial in getting good automation and quality of PRs IMO. The current pieces I'm thinking of (ideas, not all are necessities)

  • Body must be longer than 25-50 characters (has a normal description) (Should warn if not)
  • CHANGELOG must have been modified (Should error if not)
  • Confirm the Tests folder changed and a relevant test-file was modified/created for a PR (Should error if not)
  • Confirm file name convention for tests, operators, etc.
  • Confirm a Playgrounds page was created if a new file was created (Should error if not)
  • Confirm Playgrounds were modified if Sources were modified (should warn if not)
  • Confirm correct filename if a new operator or control event is added (we know this based on the folder structure and a new function added, possibly), should error if not

• Migrate to CircleCI - TL;DR Travis is slow and have been crappy for OSS. Myself and @ashfurrow migrated some repos to CircleCI and it's proven to be much more stable and deliver better build times and less waits. (Move to CircleCI #129)

• Confirm support for Carthage and SPM

[freak4pc]

cc/ @fpillet @mosamer @bobgodwinx

[mosamer]

In such a case, will it make sense to move RxTestExt here as well? or would you prefer to wait a little bit on that?

[freak4pc]

Let's wait a bit and start with this first :)
There's a lot of work to be done and this is still WIP

[mosamer]

I get it, just some of the items in the list may not be applicable there (Playgrounds for instance) so just to keep that in mind if the plan for this is to happen eventually.

Also, feel free to let me know if you need help with any item in this list, will be glad to help ;)

[freak4pc]

Opinions on Folder Structure and general feedback would be helpful :)
When reaching the end of the list probably ensuring SPM and Carthage behave would help as well 😄

[mosamer]

• I am not sure about subfolders inside RxSwift & RxCocoa
• I'd keep Common folder for common/shared implementation code
• I'd add Utils -or Helpers- folder for helper functions shared (currently Tools)

[bobgodwinx]

After taking a look at both the current RxSwiftExt repo I did also checked how RxSwift repo which contains the RxCocoa relates. I still suggest we go for option one. A new repository because it will actually simplify things. And if we need operators from the RxSwiftExt we can always add it as a dependency just like RxSwift + RxCocoa. If you take a look at the RxSwift repository the only thing that RxCocoa shares is the workspace. The both of them are two different projects and I think the decision of having all of them is one single repository is because ReactiveX gave one repo per language and that is why we find the both in one repo. But if we go for a different one it is specific and clear from the beginning what it is for and why. Because Sometimes I get confused while navigating through the RxSwift repo by associating some operators.

[freak4pc]

I still (personally) don't find a case for separating the repos since they are so coupled. I understand your argument regarding ReactiveX single-repo, but I think it does make sense in that context; everything is found in one place, and everything can be maintained by a dedicated group of people without jumping between projects that share so much in common.

[ashfurrow]

Cool, all sounds good to me 👍 I like the subspecs idea but Carthage users will miss out, that's okay. I also like keeping things in one repo – just from experience I've found it easier. But 🤷‍♂️