Question about whether the relative path is base on current working dir or current md file?

[RunSimple42]

I usually use markdown with image like that:

- path/to/folder
  - hello.md
  - hello.jpg

And in hello.md, image is referred like ![](./hello.jpg).

It's working in VSCode that what I think might be right, but not here. This package always try to resolve the src with cwd.

I was like to make a PR to fix this, but thought that may be a big break change. I'd like to listen your opinion about it, thanks.

[solution-loisir]

Hi @RunSimple42, if I'm not mistaken, the current behavior is that the relative path is based on project root. That's how Eleventy-img plugin is resolving relative path too. If I understand correctly, when you're using a reference to an image the path is resolved against CWD, but what you would like is to not have to do /path/to/folder. I'm sorry if I get all this wrong here, I might have to try it for myself before I fully understand. Anyhow, I quite happy to discuss about to see what's best for this project. Thank for your input!

[solution-loisir]

Would you have an example I could play with? Thanks!

[solution-loisir]

Hi @RunSimple42, I'm rereading my comment and I believe that I answered a little quickly here and got a little confused. By default this plugin is resolving relative path based on the eleventy-img outputDir config property which is by default "./img/". So the way the path is defined will depend on where you're defining this plugin and basically how you handle markdown processing. So the path is not necessarily resolved to the project root. Now, defaults can be changed through configuration. Maybe that is not your point. Feel free to redirect me in that case.

[tianjianchn]

Would you have an example I could play with? Thanks!

You could try this repo: https://github.com/tianjianchn/markdown-it-eleventy-img-relative-path-issue , after running npm run build, it will be broken like that:

[11ty] Problem writing Eleventy templates: (more in DEBUG output)
[11ty] 1. Having trouble rendering njk template ./posts/hello/index.md (via TemplateContentRenderError)
[11ty] 2. ENOENT: no such file or directory, stat './hello.jpeg' (via Error)
[11ty] 
[11ty] Original error stack trace: Error: ENOENT: no such file or directory, stat './hello.jpeg'
[11ty]     at Object.statSync (node:fs:1588:3)

Maybe we could add an option to allow user to change this behavior? Place the images next to md file might be more intuitive and easy to manage.

[solution-loisir]

I'll look at it a little later. Thanks for your comment. This might be related to urlPath. https://www.11ty.dev/docs/plugins/image/#url-path

[solution-loisir]

OK, I had time to play with @tianjianchn reproduction repo and it appears that my first comment was right in the end: relative paths are based on project root which is where the plugin is defined. So for instance, in @tianjianchn example, to reference hello.jpeg in index.md in a file system like below:

- posts
  - hello
    - index.md
    - hello.jpeg

You have to do:

<!-- posts/hello/index.md -->

![](./posts/hello/hello.jpeg)
<!-- OR -->
![](posts/hello/hello.jpeg)
<!-- The relative path is resolved against project root -->

I, personally, never found that behavior to be problematic. I guess it always felt natural to me. I'm not sure it's explicit in the README though and it probably should (note to self). I know these things can be a matter of preference and I'm not against providing an opt-in resolvedAgainstRoot boolean. I'm not sure if it's possible, but I'll look into it. I'm open to suggestion on how to implement such feature. Thank you both for your inputs! 🙌

[solution-loisir]

For the record, I just found a blog post that tackle this very problem. The solution is very 11ty specific, but the principles are there! Maybe a good starting point.

[solution-loisir]

Funny enough, so far the test with the programmatic version of Eleventy doesn't yield any error. I'll keep testing! 😁

[solution-loisir]

Funny enough, so far the test with the programmatic version of Eleventy doesn't yield any error. I'll keep testing! 😁

My bad, this is working as expected. 😂

[tianjianchn]

I'm not against providing an opt-in resolvedAgainstRoot boolean.

Nice! Second this.

For the record, I just found a blog post that tackle this very problem.

Yes, it is. As this blog's author said, he also made the output images being relative to post, not root. That's better for image SEO, which I didn't consider about ever. But it might break the behaviors of urlPath and outputDir in @11ty/eleventy-img if we merge this feature into markdown-it-eleventy-img, since we have to overwrite them, or their default value at least. I'm not sure whether it's ok.

[solution-loisir]

But it might break the behaviors of urlPath and outputDir in @11ty/eleventy-img if we merge this feature into markdown-it-eleventy-img, since we have to overwrite them, or their default value at least. I'm not sure whether it's ok.

My idea would be to keep the current behavior as default and have a custom config property that could be switched off to get the other behavior. If it's not possible at all without breaking everything, I'll keep things as is which is completely functional, works for most use case and is aligned with the underlying tools used by markdown-it-eleventy-img. I'll make some tests in the next few days and I'll get back to you.