As a developer, I would like an easy way to build and test the production app locally

[gsehrlich]

Is your feature request related to a problem? Please describe.
There have been several recent issues (e.g. #482) about differences between the development and production builds of the app. As a developer, I would like to be able to test fixes for the issues. Currently the README contains instructions for building the development version locally, and there's an open issue to document how to deploy the production app remotely (#471), but there's no documented way to build the production app locally.

Describe the solution you'd like
A documented sequence of commands, perhaps in the README, that build and serve the production app locally.

For developers
As an outline, one could first build the production app, then follow all the steps to serve the development app locally, and finally take down the web container and replace it with serve build.

More ideally, we would have a docker-compose.livewire-localtest.yml file that can be included in the docker-compose call that gets all the settings right to run the production version of the app locally. This would replace docker-compose.livewire.yml in the commands in steps 7 and 8 at the bottom of /.github/deployment.md.

[Temidayo32]

@gsehrlich "A documented sequence of commands, perhaps in the README, that build and serve the production app locally."

I am not sure, but I think the new changes to the deployment.md attends to the issue, since the deployment process was done locally via the terminal. And I think there was a step that addressed building the production app locally (which came after bringing down the production environment). Or you will rather a separate how-to step-by-step for this process entirely?

[Temidayo32]

@gsehrlich Or am I missing something?

[Temidayo32]

Okay, the title of the issue also mentioned testing. That isn't included in the deployment.md file. There was nothing that spoke to testing the production locally.

[gsehrlich]

Thanks for asking—this probably needs some clarification. The frontend framework for this app, React, can build in two different ways: "development mode," which is clunky but good for debugging, and "production mode," which has been compiled for distribution over the Internet but much more difficult to debug. There's more about it here: https://stackoverflow.com/questions/48151128/difference-between-production-and-development-build-in-reactjs

The instructions you wrote in PR #485 are about deploying the app to be served over the Internet from the Digital Ocean server, which uses React's production mode. This issue is about building and testing the app in production mode, but locally, from the developer's own computer, before deploying it from the server. It's possible that the same docker-compose commands you referenced would work equally well for a developer testing the app locally on their own computer! I'm not sure—I haven't looked into it.

Eventually we'll need to document this process, but first we need to figure out the best way to do it.

[Temidayo32]

@gsehrlich This is interesting. So let me get something straight: why would you want to be able to test the app in the production mode? what is the significance? Is there any benefit to that? Or perhaps, there is something that triggered the need for that.

[gsehrlich]

Great question! Sometimes the production mode behaves differently from the development mode, unfortunately. See #482 for an example.

[Temidayo32]

@gsehrlich If I get the problem correctly, it appears there is a clash between the CSS styling that applies in the production and development environment. Is that correct?

[gsehrlich]

Sort of. I would expect the CSS to behave identically in the production and development environments, but for some reason the production version works differently. So the CSS that looks right in development looks different in production.

[Temidayo32]

That's interesting. But why is that? Perhaps, there is a need to work on realigning the CSS styling in both environment. Or that won't be necessary?

[gsehrlich]

"Why is that happening?" is the central question of this open issue. I imagine the solution will require some research!

[Temidayo32]

@gsehrlich If webpack is the tool used for the production build, then it might be the first place to look at to discover the problem (the research you speak of).

at #482, webpack settings was suggested as the place to look at to find out reasons for the CSS mismatch and the redundancy: Are there "webpack settings causing e.g. the redundant <style> tags seen in #453?