For now files are generated as {route}/index.html
A Amazon CloudFront compatible mode to have files work with the use of the angular router
{route}.html or {route} so URLs can resolve and do not hit the default rule to be routed to index.html
This is a serious SEO issue
Changing files in places in the dist folder
@alan-agius4 I would like to implement this one, will it be accepted ?
@williamdes, I am sorry, but I am not fully understanding the problem here.
Do you have some docs that describe this behaviour?
https://medium.com/@peatiscoding/here-is-how-easy-it-is-to-deploy-an-angular-spa-single-page-app-as-a-static-website-using-s3-and-6aa446db38ef
Finally, now we need to configure 403 or 404 errors to redirect the traffic to index.html to do this.
Go to Distribution Settings
Go to Error Pages Tab
Create 2 Customer Error Responses for 403, and 404 error. Both of them should use Customize Error Response with page of index.html and change status to 200.
So all requests are redirected to index.html because virtual app routes do not exist.
But I want that my SSR routes are real files and can be served without hitting the 404 rule.
So having {route}/index.html will hit the 404 rule and use index.html but if I have a {route} file it will use it and return the contents.
Is it more clear explained that way ?

@alan-agius4 Just outputting {route}.html instead of {route}/index.html is an easy change. What are your thoughts on adding this custom functionality to the prerender builder?
I feel it might be reasonable to expect users to create their own build scripts for organizing their prerendered files, but I wouldn't be particularly opposed to making this change.
@wagnermaciel / @williamdes, I think this is more of a configuration issue S3, because when using prerender the index file under the root does exist and In case you have a request to https://<bucket-name>.s3-website-<region>.amazonaws.com/my-route -> it should try to locate an index.html under the my-route folder.
So the above mentioned root shouldn't be triggered at all.
@wagnermaciel / @williamdes, I think this is more of a configuration issue S3, because when using prerender the index file under the root does exist and In case you have a request to
https://<bucket-name>.s3-website-<region>.amazonaws.com/my-route-> it should try to locate anindex.htmlunder themy-routefolder.So the above mentioned root shouldn't be triggered at all.
I will not work because routes are used like this:
/dashboard > 404 > /index.html > 200 > virtual router (everything okay)/dashboard > 200 (everything okay)Trust me, a lot of people have searched and there is not solution but the proposed one.
Or we all missed something obvious :thinking:
I did think about a solution:
routes: [
"/",
{
"route": "/dashboard",
"output": "/folder/customconfig/whatever" // relative to dist folder of course
},
"/whocares"
]
What do you think @wagnermaciel @alan-agius4
@williamdes Couldn't you add a script to the end of your build process to reformat all of the files outputted by prerendering to your desired file structure?
I could see this getting very messy with customizing outputs. Also, a solution for customizing prerendered route outputs would also need to work with the "routesFile" option for the prerender builder.
@williamdes Couldn't you add a script to the end of your build process to reformat all of the files outputted by prerendering to your desired file structure?
Sure but I will have 2 places to maintain and I think it is a bad future-proof solution.
Should I open a pull-request or will it not be accepted and deployed in a short time ? :thinking:
@williamdes, I think before accepting a PR we need to invest some more time investing S3 and CloudFront, especially since adding another option will increase the api surface.
I think that serving the index.html is possible using lamda鈥檚, but I haven鈥檛 play with them that much to be certain.
This is also the first time that someone brought up this issue so I am a bit surprised.
@williamdes, I think before accepting a PR we need to invest some more time investing S3 and CloudFront, especially since adding another option will increase the api surface.
I think that serving the index.html is possible using lamda鈥檚, but I haven鈥檛 play with them that much to be certain.
This is also the first time that someone brought up this issue so I am a bit surprised.
Please note the issue is not serving index.html but serving a route that is not ended by a slash, and not ending by .html
CloudFront is great but not for this sort of configs..
Anyway we had pre-rendering working before Angular 9 with another setup.
lambda鈥檚 are only more complexity and more money ;)
Please note the issue is not serving index.html but serving a route that is not ended by a slash, and not ending by .html
You can amend always amend the lamda, that was just for reference that it can be done via lambda!
Please note the issue is not serving index.html but serving a route that is not ended by a slash, and not ending by .html
You can amend always amend the lamda, that was just for reference that it can be done via lambda!
Yeah
I am not negating your potential solutions ;)
Just searching for the most light weight and transparent one
@wagnermaciel I did the script way and it did work as expected.
#!/bin/bash
ME=$(dirname $0)
ENV="$1"
set -e
# Load up .env
set -o allexport
[[ -f $ME/$1 ]] && source $ME/$1
set +o allexport
# use s3 sync to send build files to S3 bucket
echo "Build path: ${BUILD_PATH}"
echo "S3 bucket: ${AWS_S3_BUCKET}"
routes=(
"fr"
"en"
"privateroute"
)
for route in "${routes[@]}"
do
mv "${BUILD_PATH}/${route}" "${BUILD_PATH}/${route}-folder"
mv "${BUILD_PATH}/${route}-folder/index.html" "${BUILD_PATH}/${route}"
rmdir "${BUILD_PATH}/${route}-folder"
done
aws s3 sync "${BUILD_PATH}" "s3://${AWS_S3_BUCKET}" --acl public-read --delete
aws s3 cp "${BUILD_PATH}/index.html" "s3://${AWS_S3_BUCKET}" --acl public-read
for route in "${routes[@]}"
do
aws s3 cp "${BUILD_PATH}/${route}" "s3://${AWS_S3_BUCKET}" --acl public-read --content-type text/html
done
@williamdes That's good to hear! I would also encourage you to take a look at the "routesFile" option. This way you wouldn't have to repeat your routes definition in two different places.
diff --git a/angular.json b/angular.json
index 22926886a..4c508d878 100644
--- a/angular.json
+++ b/angular.json
@@ -193,13 +193,7 @@
"prerender": {
"builder": "@nguniversal/builders:prerender",
"options": {
- "routes": [
- "/",
- "/fr",
- "/en",
- "/privateroute"
- ],
+ "routesFile": "prerender-routes",
"guessRoutes": false
},
"configurations": {
diff --git a/deploy-s3.sh b/deploy-s3.sh
index a4b6f4f40..f44d36e2a 100755
--- a/deploy-s3.sh
+++ b/deploy-s3.sh
@@ -16,14 +16,9 @@ set +o allexport
echo "Build path: ${BUILD_PATH}"
echo "S3 bucket: ${AWS_S3_BUCKET}"
-routes=(
- "fr"
- "en"
- "privateroute"
-)
-
-for route in "${routes[@]}"
+routes=`cat prerender-routes`
+# Replace / by nothing
+routes=${routes/\//}
+
+for route in $routes;
do
mv "${BUILD_PATH}/${route}" "${BUILD_PATH}/${route}-folder"
mv "${BUILD_PATH}/${route}-folder/index.html" "${BUILD_PATH}/${route}"
@@ -34,7 +29,7 @@ aws s3 sync "${BUILD_PATH}" "s3://${AWS_S3_BUCKET}" --acl public-read --delete
aws s3 cp "${BUILD_PATH}/index.html" "s3://${AWS_S3_BUCKET}" --acl public-read
-for route in "${routes[@]}"
+for route in $routes;
do
aws s3 cp "${BUILD_PATH}/${route}" "s3://${AWS_S3_BUCKET}" --acl public-read --content-type text/html
done
diff --git a/prerender-routes b/prerender-routes
new file mode 100644
index 000000000..f566920ad
--- /dev/null
+++ b/prerender-routes
@@ -0,0 +1,5 @@
+/
+/fr
+/en
+/privateroute
Done.
Since I did stop procrastinating and did the script @alan-agius4 it is up to you to let me know if you want an implementation or close this issue.
Thank you for all the support and comments !
PS: routesFiles had one inconvenient for / route, I did need to exclude it from the custom folder process
Seeing that this can be possible done via lamda/scripts let鈥檚 close the issue for know.
Let鈥檚 reconsider this If more users require this feature.
Thanks for your understanding.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._