You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was working with Adrian on support request 2301110040009179 to try and understand if there was a straight forward way to deploy our static web app to a subdirectory. (Not sure if y'all have access to that same tracking system, but just in case I included that Support Request ID.)
Basically all we would like to do, in a simple and straight forward configuration setting, is to be able to set the destination directory. For example; ourdomain.com/our-static-web-app
I wanted to put in a feature request to be able to do so without having to conjure up a workaround, which we have. I'll explain.
We have a domain, teachforamerica.org, and we have a website, or let's say, index.html at the root of that domain already. We plan on deploying several static web applications in several paths, each on their own static web app resource so we can maintain those separately and route to them via CDN. For example; /eligibility, or /apply, etc.
What we have done is:
set the workflow file output_location to /dist
set our vite build outDir to dist/eligibility
at the end of our build, or closeBundle vite hook, we copy the index.html from the /dist/eligibility directory to the /dist directory (so we pass checks for the index.html at the root)
in the staticwebapp.config.json we set routes to redirect to /eligibility/ if the root index.html is visited.
What would be great is if we didn't have to do this and we were able to simply set the destination directory and have the service check the set destination directory for the index.html vs as the root.
It looks as though others have been needing the same capability. (#351, and #671) Could this be in store for the future?
Thank you so much for y'all's time!
The text was updated successfully, but these errors were encountered:
@jaysonpotter thanks for the feedback, I know we've documented the workaround but we could look into providing ways to make this more seamless. I'd love to understand more about how you're using SWA in this way, could we get in touch?
@thomasgauvin What is your work around? I'm in a similar space. I have multiple MFEs in the same repo and we want to have a separate pipeline for each mfe to deploy to the same ASWA, but in different directories.
Hey there,
I was working with Adrian on support request 2301110040009179 to try and understand if there was a straight forward way to deploy our static web app to a subdirectory. (Not sure if y'all have access to that same tracking system, but just in case I included that Support Request ID.)
Basically all we would like to do, in a simple and straight forward configuration setting, is to be able to set the destination directory. For example; ourdomain.com/our-static-web-app
I wanted to put in a feature request to be able to do so without having to conjure up a workaround, which we have. I'll explain.
We have a domain, teachforamerica.org, and we have a website, or let's say, index.html at the root of that domain already. We plan on deploying several static web applications in several paths, each on their own static web app resource so we can maintain those separately and route to them via CDN. For example; /eligibility, or /apply, etc.
What we have done is:
output_location
to /distoutDir
to dist/eligibilitycloseBundle
vite hook, we copy the index.html from the /dist/eligibility directory to the /dist directory (so we pass checks for the index.html at the root)routes
to redirect to /eligibility/ if the root index.html is visited.What would be great is if we didn't have to do this and we were able to simply set the destination directory and have the service check the set destination directory for the index.html vs as the root.
It looks as though others have been needing the same capability. (#351, and #671) Could this be in store for the future?
Thank you so much for y'all's time!
The text was updated successfully, but these errors were encountered: