This probably needs a longer discussion. Our standard practice for developing the frontend modules is to work on one module at a time, running locally with the rest of the app being served from dev3. In this flow, the source maps are loaded locally for the app that you are working on, so while developing an app, you should have access to the source maps for the app. (You can read more about the flow in the OpenMRS 3.0 dev guide). Basically, the idea isn’t to not have source maps at all as it is to restrict source maps to the relevant ones.
This is purely a bandwidth issue; essentially, I was trying to cut down on the amount of data transferred from dev3 as this was costing some of our community volunteers quite a bit in bandwidth. I don’t see a way around this issue without changing the frontend dev workflow to use Docker images locally, in which case, bandwidth becomes a non-issue.
I’m just saying that we need to be able to debug the application as the whole with all building blocks in place. It’s going to be more and more complex especially given the number of components, versions and different possible configurations. They all interact with one another and may cause issues that occur only when run together. It’s not trying to change the standard practice for developing the frontend modules, which is the way it should be.
All right! Then let’s try to make it so that they are only fetched, if you need them.
Yeah, I’m not trying to say that our current setup is ideal. Having source maps is useful, just trying to contextualise the problem that was being solved by not having them. If there’s a way in which we can get this working, I’m happy to do so. I think the trick is to find a way to make downloading the source maps explicitly opt-in.
So this seems to require doing the following commands to get it to work:
docker-compose up -d
# wait for install to complete
docker-compose restart backend
# now the server works
It would be nice if we could avoid the need for the second line. Not quite sure why that happens.
I’m also a bit stumped on the patient chart loading issue. If I run the patient-chart-app locally, everything works as expected… There are also no obvious errors, which makes it a bit hard to know where to start… Even if we had source maps with out an error to start from it’s going to be a bit weird.
The problem seems to be in this component. In particular, the isLoadingPatient doesn’t seem to be getting set to true, hence the loading widget showing forever.
From the Network tab, I can see it actually loads the patient 3 times, which seems a bit off…
The underling cause of the breakage might be in another esm-module @ibacher (just thinking). Does our docker instance allow us to override the version of any esm module running? If so how can the version/instance be overriden?