metalsmith
What is the logic behind relative paths here?
Running metalsmith-permalinks on this directory:
Macbook:project me$ ls -R src/
src:
first-post.html test
src/test:
test.txt
results in the following permalinks structure (with @pian0's duplicate relative files fix)
Macbook:project me$ ls -R build/
build:
first-post test
build/first-post:
index.html test
build/first-post/test:
test.txt
build/test:
test.txt
I'm just wondering what the logic of the copying over the "sibling" files is. IMHO, the resulting file structure should be:
Macbook:project me$ ls -R build/
build:
first-post test
first-post:
index.html
test:
test.txt
I also wondered at the functionality's purpose. I guess if you link to test.txt from index.html, the link will break once the permalinks are resolved. I personally added an option to turn the relative files functionality off entirely because I was bending over backwards to avoid it.
If that is the problem that copying sibling files over solves, then I think a better solution might be in order... maybe metalsmith-permalinks could provide some metadata about the directories? For example:
Macbook:project me$ ls -R src/
css page1.html
css:
style.css
Could generate this build
Macbook:project me$ ls -R build/
css page1
css:
style.css
page1:
index.html
And then also create the metadata pl.css which could be the dirname of the css folder. You'd have to run metalsmith-templates after permalinks though. Not sure if that can be worked around.
ah yeah, i added that functionality because linking to things like images is super nice to be able to images/whatever.png in the markdown and not have to worry about where the file might end up (which would make it a leaky abstraction)
i'd be super down for a PR to have the copying of files be an option called relative or something that defaults to true
i'd also be down to accept a PR that adds a symlink option defaulted to false that would make them symlinks too.
both sound like great ideas
I'm not sure about the global directory metadata feature. Consider this source dir..
$ ls -R source/
index.html post.html jobs css
jobs:
resume.html
css:
style.css
If index.html, post.html, and jobs/resume.html all linked to css/style.css, then what use would be the metadata about the css folder?
It's okay if the links from post.html and jobs/resume.html are different (i.e. {{pl.css}} and ../{{pl.css}} respectively), but the links from index.html and posts.html should be the same. They should both be {{pl.css}} as in the source file structure, but the one piece of metadata can't link both of them correctly since post.html would be moved one level deeper and index.html wouldn't.
Maybe you'd thought I meant file-local metadata all along, but I've been thinking about global metadata. File-local metadata would be the solution since permalinks can handle edge cases such as index.html and post.html needing different link directories.
ah sorry, i'm not sure a metadata change is the way to do it. i'd rather it just be behind two options i think. updated my last comment there to make it clearer
Are you sure? I think adding new file metadata about the original source directory structure would be a really clever and transparent solution. Would basically be a map of relative paths for each file.
Oh, cool. I've already done the relative / family option on my branch. I'll set up a PR tonight.
Files could link to the value of link["css/style.css"], where link is an object that is generated for each file. And then templates can read that and put the actual relative link there.
the only problem i see with that is that it makes using permalinks with markdown a lot more complicated. right now we can just do  and it works like people would expect for a static site
I see. That is a big problem. I wish there was a way to do this nicely! I'll keep thinking about it.
I was thinking about the symlinks option, and realized that it should probably create new files that are marked as symlinks somehow and will be output as symlinks by Metalsmith. Do you agree?
I.e. add to the files object some file with symlink: { source: '../path/to/foo/bar' } metadata, or something. Do you have any thoughts on this?
mm yeah that makes sense. dang haha, one more thing to add to the metadata api. what are the other options for symlinks that you were thinking about being in that object? otherwise would be nice to just do symlink: 'path'?
I didn't seriously consider any other options... A new symlinks object is obviously not a good solution since we'd have to pass that around (just to throw a new idea out in the air). Not sure if there's any better way to do it than adding a symlink metadata API.
I was thinking that files['path/to/symlink/dest'] = { symlink: 'path/to/symlink/src' }; would be kinda nice. Symlinks are files so it makes sense semantically.
Cool. I was working on this night but ran into issue #41 in the metalsmith repo :P I'll work on it again tonight.
TIL /link/from/root/ is a thing, and all my worries about writing links are resolved
