Open NickSto opened 3 years ago
FYI, a search (grep -ER '[^!]\[.+\]\(\./[^)]+\.[^)]+\)'
) through the build directory shows that currently there aren't actually many links directly to files.
The only clear one is the link to PoweredByGalaxy.xcf
on /outreach/powered-by-galaxy/
.
I feel like there were other examples but I've checked my regex a few times and it should be catching them.
Nick, we can kill that xcf file. I bet it has never been used
@tnabtaf Good to know. We can also easily just move it to a static directory (content/media/
), FYI. That'll still work.
That .xcf file will be deleted in PR #954.
It seems that when a hyperlink points to a local file (not in a static directory), Gridsome usually moves the file to the
/assets/
directory and rewrites the href to point to the file. This can lead to issues.One known scenario is when the file is actually a symlink placed there by our build system (
preprocessor.mjs
). In that case, Gridsome copies the symlink itself, not the target file. Because our symlinks are relative, if you put them in a different filesystem location, they break. Even if they didn't break, I'd want to verify that the AWS uploader would be able to access the target file (since it's in a totally different directory).The bottom line is this makes linking to a local file (one in the same directory) unreliable. We'd ideally like to support that.
There are several factors that affect whether Gridsome takes action and performs the rewriting, and if so, how it does it:
yarn develop
vsyarn build
).vue-remark
or justsource-filesystem
.This page has details on the effects of each factor.