-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(feat) Supporting O3-2510: Expose patient-common-lib on window #1430
Conversation
Size Change: +30 B (0%) Total Size: 9.1 MB ℹ️ View Unchanged
|
Question on the premise here: openmrs-ngx-formentry is, in fact, using Webpack (I realize the Angular team regards this as an "implementation detail", but it's one we rely on). With that in mind, do you think this is still the right approach or should we use something like |
Oh, interesting. I guess I am still inclined to do it this way. I don't think it poses major disadvantages, other than that there's no way to do explicit version dependency, and this can be substituted for checking expected function signatures and logging good error messages. I'm not sure it would be worth it to get the whole |
Requirements
Summary
Makes esm-patient-common-lib available on the window object. This will allow ngx-formentry to access it despite not being a webpack module.
Related Issue
https://issues.openmrs.org/browse/O3-2510
Other
Copilot called me out for doing a hack