Deploying to a web server subfolder fails
davosian opened this issue · comments
Generating the export and deploying it to a server works fine as long as all sources are in the web server's root directory. However, when moving the deployment to a sub directory, a JSON.parse SyntaxError comes up:
The following structure works fine:
❯ tree www
www
├── bundle.css
├── bundle.css.map
├── bundle.js
├── bundle.js.map
├── favicon.ico
├── index.html
├── insomnia.json
└── logo.png
Running a web server with python3 -m http.server 8000
inside the www
directory works fine.
The following structure does not work when the web server root is www
:
❯ tree www
www
├── my-api-docs
│ ├── bundle.css
│ ├── bundle.css.map
│ ├── bundle.js
│ ├── bundle.js.map
│ ├── favicon.ico
│ ├── index.html
│ ├── insomnia.json
│ └── logo.png
Running a web server with python3 -m http.server 8000
inside the www
directory is resulting in a JSON.parse SyntaxError
. Because of this issue, I tested versions 1.0.4
and 1.0.6
of the plugin. The result is the same.
The same issue arises when deploying to a folder on Azure. When I modify the export to have all resources pointing to an absolute path (/my-api-docs/...
), everything is working again. This leads me to believe that relative paths are not being picked up correctly.
You will need to specify what the root path is. To do this, you have to open index.html
and replace the following line:
<div id="app"></div>
with the following:
<div id="app" data-root="/my-api-docs"></div>
In this case, the app will pick up the insomnia.json
file from the /my-api-docs
directory. You should NOT put a trailing slash in the data-root
property.
Thank you for using this plugin and don't forget to star the repo.
Thanks for your quick reply @devhammed.
Your fix worked fine when testing with the python web server. I made sure to star your repo, of course ;)
That being said, I am envisioning to run the export and deploy step automatically at given intervals. Ideally, no manual tweaking to the index.html
would be required to keep the workflow as simple as possible. Therefore, if the Plugin API allows for project level configuration, providing the root folder (and remembering it) in addition to the output path when running the export would make things even easier. Consider it a "nice to have" :)
Sidenote: the Azure static site only worked when I also made the other resources absolute links:
<link rel="shortcut icon" href="/my-api-docs/favicon.ico">
<link rel="stylesheet" href="/my-api-docs/bundle.css">
<script defer src="/my-api-docs/bundle.js"></script>
However, this is probably an issue related to Azure and not to this plugin. I am currently investigating.
issue related to Azure
I found the Azure related issue: to load the resources correctly, the URL needs to have a trailing slash:
This works: https://api.mydomain.com/my-api-docs/
This does not load relative resources correctly: https://api.mydomain.com/my-api-docs
issue related to Azure
I found the Azure related issue: to load the resources correctly, the URL needs to have a trailing slash:
This works:
https://api.mydomain.com/my-api-docs/
This does not load relative resources correctly:https://api.mydomain.com/my-api-docs
Oh Wow...I guess we will need to go the absolute path way for everything.
Thanks for your quick reply @devhammed.
Your fix worked fine when testing with the python web server. I made sure to star your repo, of course ;)
That being said, I am envisioning to run the export and deploy step automatically at given intervals. Ideally, no manual tweaking to the
index.html
would be required to keep the workflow as simple as possible. Therefore, if the Plugin API allows for project level configuration, providing the root folder (and remembering it) in addition to the output path when running the export would make things even easier. Consider it a "nice to have" :)Sidenote: the Azure static site only worked when I also made the other resources absolute links:
<link rel="shortcut icon" href="/my-api-docs/favicon.ico"> <link rel="stylesheet" href="/my-api-docs/bundle.css"> <script defer src="/my-api-docs/bundle.js"></script>
However, this is probably an issue related to Azure and not to this plugin. I am currently investigating.
I will look into adding root path prompt too 👍
Oh Wow...I guess we will need to go the absolute path way for everything.
I would not worry about this one too much. Absolute paths is probably not a good idea for most use cases. I rather consider it a limitation on Azure's implementation and for Azure, there are other deployment options available as well. The one I picked was simply the most basic one and since we are talking about a static site, the current setup is good enough at least for my use case.
Oh Wow...I guess we will need to go the absolute path way for everything.
I would not worry about this one too much. Absolute paths is probably not a good idea for most use cases. I rather consider it a limitation on Azure's implementation and for Azure, there are other deployment options available as well. The one I picked was simply the most basic one and since we are talking about a static site, the current setup is good enough at least for my use case.
The absolute path should work everywhere.
Even better 😊
Hello @davosian , the feature has landed with the commit c299706, you should upgrade the plugin.
I tried v1.0.7 but I do not see any additional export settings even after reloading the plugin. Am I missing anything?
My bad: I expected two input fields but now I realized that the input files come up sequentially. Testing right now...
Found 1 minor issue: while most resources are using absolute paths now, logo.png
is not.
Found 1 minor issue: while most resources are using absolute paths now,
logo.png
is not.
Fixed, upgrade to 1.0.8
.
1.0.8
works like a charm now, thank you 👍
Just be aware that the source mapping files bundle.css.map
and bundle.js.map
are still using the relative paths to logo.png
.
1.0.8
works like a charm now, thank youJust be aware that the source mapping files
bundle.css.map
andbundle.js.map
are still using the relative paths tologo.png
.
You're welcome.
For the source maps, I will look into them later in the day.