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
Is your feature request related to a problem? Please describe.
I am currently working on a fornax project to build gh-pages as docs for other repositories. The default gh-pages link is created somewhat like the following
https://{user_name}.github.io/{repo_name}/
After which the fornax structure is appended. This leads to the problem, that relative links, which work fine in dev (exmaple: /content/content.md) will not resolve to the correct page in gh-pages (/{repo_name}/content/content.md).
Describe the solution you'd like
Maybe give fornax watch not only an option to user an alternative port, but also to adjust the dev url.
The text was updated successfully, but these errors were encountered:
I don't think it can/should be the responsibility of the cli tool to keep track of this?
I think it might make more sense to let loaders/generators handle URL structures like this. You could, for instance, load the prepended URL structure via a global loader and retrieve it as required in your generators based on some arbitrary dev/prod flag.
Is your feature request related to a problem? Please describe.
I am currently working on a fornax project to build gh-pages as docs for other repositories. The default gh-pages link is created somewhat like the following
https://{user_name}.github.io/{repo_name}/
After which the fornax structure is appended. This leads to the problem, that relative links, which work fine in dev (exmaple:
/content/content.md
) will not resolve to the correct page in gh-pages (/{repo_name}/content/content.md
).Describe the solution you'd like
Maybe give
fornax watch
not only an option to user an alternative port, but also to adjust the dev url.The text was updated successfully, but these errors were encountered: