Closed danielpetisme closed 5 years ago
Hello @Authfix, @kbeaugrand Could you help me on the front packaging.
Currently if I do dotnet run
it builds and run the backend but the front is not server. I guess I need to copy the front app in the wwwroot ?
For a pure dev mode running npm start
in parallel to have the front running+ hot reload is fine but not for distribution.
Could you help? point some good practices?
Hi @danielpetisme,
dotnet run
is not the right command to get a production distribution.
We must use dotnet publish
for that. Actually, in my first PR (#12), I fixed the dotnet build and angular build. During the dotnet publish process, angular application is build with production settings and configure to be serve as static files by asp.net application.
Actually, I think we just need to configure the spa route to serve the index.html by default with MapSpaFallbackRoute
.
With JHipster java
mvn spring-boot:run
build is app (compilation, linking, etc.) and serve the back and front with the Dev profile by default but can be override.
mvn package
does the packaging to have a thin war or a fat jar (ie. executable) and you can provide a profile you want to apply
I'm trying to configure the project to use dotnet run
and dotnet publish
to have the same behavior with the Debug
and Release
profile.
Does it make any sense ?
Finally, I would like some feedback on the wwwroot
role?
Should we consider it as a src or binary folder ?
Should we copy the compile frontend files into wwwroot
?
I would like, as much as possible, avoir any configuration the the server side (ie. C# code). The backend shouldn't be aware of the existence of a frontend app, it should only behaves as an API provider.
To answer the above question.
wwwroot
content is copied as-is during the run/publish target.
The front app source code is hosted in ClientApp
and the webpack build are trigger by the build target with the Debug->webpack:build
and Release->webpack:prod
binding. The built front app is then copied to wwwroot
to be served.
This PR has been open long enough, I'll merge the above behavior into master to move on.
This PR aims to fix #4