Ian

Can you say more about the motivation here? I'm not terribly keen on having the component decorator become part of the public API, as it limits our ability to make...

If we're just exporting components from the styleguide, there's no reason to make this a public export. We can just use the component decorator directly in the styleguide (things inside...

Sorry... I think I dropped the ball on this. Anyways, if we _do_ need to export the openmrsComponentDecorator, then we need to add doc strings to it explaining how it...

> TBH, while the openmrsComponentDecorator() function gets the job done, it doesn't feel intuitive to use. While that's true, I like the idea of exposing the `OpenmrsReactComponent` (as it currently...

When submitting a PR, please do _not_ delete the checklist. Among other things, this asks to make sure that you ran `mvn clean package` before committing this. One of the...

If this only addresses something in the Address Hierarchy module, then we should just fix it there. Modules can mark their activator as "DaemonTokenAware" to get a valid token for...

The idea of the ticket is just to automate the process described [here](https://github.com/openmrs/openmrs-core/tree/master/liquibase). I can't imagine that we can merge this as-is without breaking things, since you've now turned the...

I agree with @mseaton's points. `DRAFT` is not a reasonable "fulfiller status". I'm also uncertain about using Task Status here. Orders are not FHIR tasks, though I suppose they might...

> changes look more than what the ticket requires Both more and less. I don't know that the comments are terribly helpful, but also there are clearly tests in the...

> I moved the cleanupObsoleteFeatureFlags function to core-config.ts I don't think that's the right point. `setupCoreConfig()` is called way too early in the cycle. I'd add a new `then()` call...