Replies: 6 comments 10 replies
-
We also made an integration https://github.com/userquin/astro-md-image-integration |
Beta Was this translation helpful? Give feedback.
-
We are on Astro2.0 and still this is not supported :| |
Beta Was this translation helpful? Give feedback.
-
Hey folks! I didn't find this thread when migrating my website 😢 (which was weird because I googled for 2 weeks from every possible angle how to get relative paths working for me) Why relative media paths are desirable (for me)1) Portable content (framework agnostic)As a content owner, I want to keep my MD(X) agnostic to framework opinions/constraints, so that I can port it easily ... I want to be able to preview content + media with most basic of MD readers (I work with design system documentation often, and this was a deal breaker to adopt Astro when we evaluated) 2) low complexity (variance generates waste)As a developer, I want to treat all images in the same way no matter where they're expressed in content or (meta)data, so that I can keep complexity level to a minimum Treating all of these the same
... and even ...
... enables using the same approach (and basically the same code), whether you are rendering the image in the page, on a list, on metadata or even back to JSON. Note: images from external data need a base path context in order to be resolved, all other cases are simply resolved from the content (MD file) path What I rolled out on my websiteI pieced together an integration that does
How it works
It is certainly be possible to also have "absolute" paths or "public/" based paths. If I ever need those I'll probably use an alias More details
TODOs:
|
Beta Was this translation helpful? Give feedback.
-
Hi everyone! We're currently working towards a new core story for optimized images, including support for relative images in Markdown. Please leave your feedback here: #468 |
Beta Was this translation helpful? Give feedback.
-
I updated the Survey section of this Discussion to take #468 into account. With a bit of luck, we might not need this one anymore, but we're not there yet. |
Beta Was this translation helpful? Give feedback.
-
This is now supported by default in Astro 3.0 |
Beta Was this translation helpful? Give feedback.
-
Proposal
Add support for Astro markdown to reference images relative to the markdown file
usage examples :
Motivation
This proposal is to make markdown portable for programmers and easy to use for non programmers.
I like Astro and believe this will increase its adoption by avoiding rework when using existing markdown, this will also improve DX by having markdown rendered in code editor same as by Astro.
Survey
core image optimization rfc A plan for a core image story #468 : this rfc has partial but not total coverage due to missing SVG support, and in case optimization cannot be disabled in favor of usage of simple assets management alone. Also might prevent customizing images with a custom component.
astro doc
https://docs.astro.build/en/guides/markdown-content/
astro mdx integration
https://docs.astro.build/en/guides/integrations-guide/mdx/
astro examples
https://github.com/withastro/astro/tree/main/examples
active RFCs proposals :
https://github.com/withastro/rfcs/tree/main/proposals
open RFC's PR's :
https://github.com/withastro/rfcs/pulls
Astro image components
https://docs.astro.build/en/guides/integrations-guide/image/
Standard
Why I mention that this a defacto standard and not a standard because searching in common cheat sheets, I could not find a clear reference to relative images usage
https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#images
This link show a relative image on the summary table then when following the link only absolute paths are used
https://www.markdownguide.org/cheat-sheet/
Defacto Standard
usage in VSCode
in VSCode the markdown preview of relative file usage already renders the expected result

usage in github
in github, such a committed markdown file with the asset in the same directory will also render,

a closer look by inspecting the html source of the github page shows management of the assets in a raw directory
Solution with integration
https://github.com/userquin/astro-md-image-integration
by @userquin and @kasvith
Solution implemented with remark plugin
(note : this solution did not take existence of Astro image integration in consideration which is currently ongoing)
I implemented a solution that solves the problem by managing the asset replacing the relative path with the new one of the copied asset in the public folder, this way, it is relying on Astro to move the assets further from the public directory to the final distribution folder. Final solution should avoid that.
how this works
This is similar to assets management in the src dir by Astro but extends it to the root directory of the project where markdown can also be placed in e.g.
data
directory. All managed assets will get a unique path und thepublic/raw
directory. The path relative to the root will be reflected from theraw
which is like the new asset root.So all the plugin does is copy the asset to the new
public/raw
path and update the node.url so that the html sees the new asset path. given that all paths under the root are unique, no need to rename assets file names with generated uids.code
Link : https://github.com/MicroWebStacks/astro-big-doc/blob/main/src/libs/remark-rel-asset.js
This is the full remark-rel-asset.js plugin
And this is where the magic happens
Link : https://github.com/MicroWebStacks/astro-big-doc/blob/main/src/libs/utils.js
Caveats
usage in Astro component
Although this was first intended to solve a standardized markdown relative paths notation, this can also be used in an Astro component as follows
here a link to a full real case usage example : https://github.com/MicroWebStacks/astro-big-doc/blob/c51ec72e9ee8e5e9683fbdecc19b16a4e27a67e4/src/components/gallery.astro#L19
but that is more subject to discussion, because first it relies on another remark plugin to provide the filedir, and there are plenty of alternatives like imports or Astro image integration. It still feels to me more flexible given the usage of build time dynamic variables and not having to hardcode all used files to an import.
Expected Final solution
expected is out of the box Astro Markdown support for relative paths and relative assets management without intermediate public folder usage. This can relate to Astro image components integration, but goal is to have it applied directly to Markdown.
see also integation potenial ready to take in Astro https://github.com/userquin/astro-md-image-integration
Beta Was this translation helpful? Give feedback.
All reactions