Validation of footer href values does not allow URI references (e.g. /foo/bar)

[petejohanson]

🐛 Bug Report

Upgrading from 2.0.0-alpha.55 to 2.0.0-alpha.61 of all my docusaurus packages has resulted in a validation failure in a working docusaurus.config.js file. In particular, In our project, I am deploying to Netlify, and using a netlify.toml file to add a redirect /community/discord/join URL that will redirect to the current Discord invite link.

In my footer, I've been using an item like:

            {
              label: "Discord",
              href: "/community/discord/invite",
            },

So that clicking that link in the footer will redirect the browser to that URL on the current host/origin server, which then redirects to the actual Discord link.

After updating all my NPM packages, I get an error when starting Docusaurus:

❯ npm start

> docs@0.0.0 start /home/peter/git/zmk/docs
> docusaurus start

Starting the development server...

A validation error occured.
The validation system was added recently to Docusaurus as an attempt to avoid user configuration errors.
We may have made some mistakes.
If you think your configuration is valid and should keep working, please open a bug report.

ValidationError: "footer.links[1].items[0].href" must be a valid uri

I can't use to instead of href, because that will only redirect with the JS router, not cause a browser navigation, so that just 404s in JS land.

Workaround

I can hardcode the full production deployment URL for this one footer link. It's not a huge problem. But doing so definitely seems "wrong", and I would expect to be able to use a URI-reference for this field, not just a URI.

Have you read the Contributing Guidelines on issues?

Yup!

To Reproduce

(Write your steps here:)

1. Bootstrap a new V2 docusaurus site with latest packages.
2. Add a footer link item that uses a relative URI (no scheme or authority section), e.g. /foo/bar
3. Run npm start

Expected behavior

A footer link will be added that performs a browser navigation to the given relative URI when clicked.

Actual Behavior

I can't run/build docusaurus.

Your Environment

• Docusaurus version used: 2.0.0-alpha.61

Reproducible Demo

1. Check out repo at zmkfirmware/zmk
2. Change into the docs directory.
3. Run npm ci
4. Run npm start and confirm it loads and footer link with labeled "Discord" and confirm it works.
5. Run npm update to pull in latest Docusaurus NPM packages.
6. Run npm start
7. Confirm it fails to start.

[slorber]

Helpful infos summary:

• https://github.com/zmkfirmware/zmk
• https://zmkfirmware.dev/
• https://zmkfirmware.dev/community/discord/invite

The netlify redirect:

---

As it's not really affecting you deeply, I'm going to close and see if this problem comes up again.

As a workaround, you can normally get the deployment URL as an env variable, so that you use the redirect fo the current deployment:

const siteDomain = process.env.DEPLOY_URL
  ? process.env.DEPLOY_URL
  : "https://zmkfirmware.dev";

const footerLink = {
  label: "Discord",
  href: siteDomain + "/community/discord/invite"
};

see https://docs.netlify.com/configure-builds/environment-variables/#deploy-urls-and-metadata

[petejohanson]

@slorber Thanks for the quick follow up. The only downside to using DEPLOY_URL is it doesn't update after a particular deploy is promoted to the active deploy for the site, so your production site ends up w/ the long annoying deploy URL instead of the "nice" URL.

I can use process.env.URL for now, but that doesn't technically work, should I deploy a preview with a different redirect in the netlify.toml.

Agreed this is a niche issue, but still something that seems worth thinking about supporting somehow in Docusaurus.

Thanks again for the great project.

[slorber]

Thanks

Not sure but maybe DEPLOY_PRIME_URL is a good fit?

We could have an escape hatch like pathname:///community/discord/invite, we already have that in another place just in case, but I prefer to see a usecase for which it would be really mandatory to support that.

[tommilligan]

@petejohanson I think your issue may be the same as mine - configuring links to relative external pages via themeConfig.

Would #3449 fix this issue for you?

[petejohanson]

@tommilligan Sure seems like that would address the issue I had to work around, yes.