Extensionise core components
@mattwire I've opened this to track your interest in moving civimember to a core extension. In general I agree that it's a long term goal to structure our code this way - it would move us to better interactions (hooks rather than hacked in code).
I don't think anyone should have the expectation of any functionality change in this process - but moving to more standardised interactions should have spin off benefits in allowing us to simplify code.
We currently have a process - ie create the extension as a hidden extension & start moving functionality over until it can stand alone - at which point we unhide it. We have 2 in progress
- event cart
- financial acls
The latter is not blocked on anything but is going to take time. The former will also take time but is also has a specific blockage in that we don't have a process to install extensions on new install that also does the DB layer stuff. If might be possible to make the extension fully optional & by pass that (ie not install it on new installs) but the install issue would be a blocker to doing similar for other components - eg. civigrant.
My personal preferred approach would be to keep chipping away at the 2 in progress ones so that they can be enabled on demand on install rather than always and then around Feb or March get a block of @totten time blocked out to address the install issue properly.
If we were to do a full core component I'd rather start with civigrant as the most doable and learn from that.