docusaurus
docusaurus copied to clipboard
asset links with trailing slash true can be broken
Have you read the Contributing Guidelines on issues?
- [X] I have read the Contributing Guidelines on issues.
Prerequisites
- [X] I'm using the latest version of Docusaurus.
- [X] I have tried the
npm run clearoryarn clearcommand. - [X] I have tried
rm -rf node_modules yarn.lock package-lock.jsonand re-installing packages. - [X] I have tried creating a repro with https://new.docusaurus.io.
- [X] I have read the console error message carefully (if applicable).
Description
I have a hosting provider where trailing slash true is required, and that works great. However, for direct links to files, it is broken.
I have a file in the docs folder (which is also versioned), and a link in .md doc like so
[Download this docx using Markdown](./assets/docusaurus-asset-example.docx)
However that link is transformed to .../assets/file/haash.docx/ and that link ends up as a 404, as it's treated as path by host, rather than resolving the file.
I think asset links should never get a trailing slash, but I don't have enough knowledge of other platforms to say that definitively.
Steps to reproduce
You can use the docusaurus docs to reproduce
- set trailing slash true
- npm run build
- npm run serve as an example server that is broken (I self host with Apache, and have the same problem)
On the /docs/markdown-features/assets#files page, attempt to open the .docx file links.
Expected behavior
It opens the linked file. File assets should probably never have trailing slashes, some hosts seem to be fine with it, but not all. I imagine all however a fine without for file assets.
Actual behavior
Document not found.
Your environment
- Public source code:
- Public site URL:
- Docusaurus version used: beta.14
- Environment name and version (e.g. Chrome 89, Node.js 16.4): hosted with apache
- Operating system and version (e.g. Ubuntu 20.04.2 LTS):
Reproducible demo
No response
Self-service
- [ ] I'd be willing to fix this bug myself.
This is actually not very easy to solve since we don't know what's a good heuristic for "assets" vs "pages"... I don't know if the static folder + pathname:// trick works for trailing slashes either, but worth trying out?
Note that our documentation has the same usage as well and a trailing slash is appended in deploy preview (we have trailingSlash: true for deploy preview and false for production). However, seems Netlify is smart enough to serve the correct file.
Yes, the problem can be seen here BTW: https://deploy-preview-6320--docusaurus-2.netlify.app/docs/markdown-features/assets/#files
We can maybe add a new "hidden" prop in <Link> similar to the existing undocumented autoAddBaseUrl, something like autoApplyTrailingSlash, and then use it in the transformLinks MDX code? 🤷♂️ (or maybe a asset: true prop?)
We already have some heuristic there:
const hasAssetLikeExtension =
path.extname(assetPath) && !assetPath.match(/#|.md|.mdx|.html/);
But this probably doesn't make sense to apply this generically in the Link component
Using pathname:// prefix could work but it's not the same as the asset won't be converted to a require call and it would require to put it in /static
For people experiencing this issue, a workaround is to use absolute URL:s for the links.
@stnor to avoid an absolute url, you should be able to put the file in /static/folder/file.xyz and ref it with [download file](pathname:///folder/file.xyz)
I am sorry if that was unclear.
The files folder is in /static/files the link is <a href="/files/foo.pdf" target="_blank">clickme</<a>
I get the 404 with the url /files/foo.pdf/ unless I use an absolute URL. On 2.0.1.
Are you suggesting it would work in markdown?
edit: oh is pathname:// some Docusaurus workaround? Does it work with <a href=""> too?
I'll give it a go.
Ok, got it. Nice that the pathname:// routing worked with html links too!
Found: https://docusaurus.io/docs/advanced/routing#escaping-from-spa-redirects
Thanks.