Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support relative paths for --root-dir #1606

Open
mre opened this issue Jan 6, 2025 · 0 comments
Open

Support relative paths for --root-dir #1606

mre opened this issue Jan 6, 2025 · 0 comments
Labels
enhancement New feature or request question Further information is requested request-for-comments

Comments

@mre
Copy link
Member

mre commented Jan 6, 2025

In #1576, we added support for the --root-dir parameter.
It is useful for checking absolute links, especially when the rendered documents are located in a subdirectory.

Common usage scenarios for --root-dir

  • Static site builds in a public or dist directory
  • Documentation sites with absolute links
  • Any project where links start with /

Here's a usage example

# Assuming the output html files get rendered into the `public` directory
lychee --root-dir "$(pwd)/public" "**/*.html"

Full documentation here.

Proposal

Add support for relative paths, e.g. . or ./public.

That would be very convenient and relatively easy to implement.
We could apply std::fs::canonicalize when we handle the root-dir:

use std::fs::canonicalize;
use std::path::PathBuf;

fn main() {
        let path = PathBuf::from(".");
        println!("{:?}", canonicalize(path));
}

Our argumentation for not doing that in the first place was that we wanted to be conservative and avoid running into edge-cases. However, after playing with the feature a bit, I'm beginning to think there is no downside to supporting that.

The above example would be simplified to

lychee --root-dir public "**/*.html"

FYI @trask, since you worked on the initial implementation.

Edit: Removed my other proposal of making --root-dir . the default. I'm no longer confident that this is a good idea.

@mre mre added question Further information is requested request-for-comments enhancement New feature or request labels Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested request-for-comments
Projects
None yet
Development

No branches or pull requests

1 participant