This is the very thing I came to Mermaid looking for. Hopefully it'll get added eventually.

I, too, would like this feature.

I just stumbled upon the same thing. Would be great to have that feature. Or any other diagram to represent hierarchy (within folders, or like JSONs).

I'd like to vouch for this as well, I feel it's a very useful and small feature to add.

Hi! I'm currently taking a look at this issue!

I'm still early in the process, but so far,

folders
  my files
  pictures of stars
   star1.jpeg
   star2.jpeg
   star3.jpeg
  your files
   folder
    folder in a folders
     not a folder
  our files
   red flag

results in

I haven't really considered the appearance of things too much yet, as I'm still working out the syntax and other basics, but if anyone has any suggestions/wishes please do voice them in this chat!

@brvv that's great! Even if it's just simple text based, it'd be good enough imo. https://codelogbook.com/2022/12/06/representing-file-structures-in-markdown

@brvv your first publish looks good so far. I would be available to test if there is a working excrement.

@brvv are you still working on this?

@jgreywolf yeah, I'll try to work on it this weekend, been very busy recently

Hey! This might be the wrong place, but I was looking for a good way to display a file structure in Mermaid and came across this.

I couldn't find anything in the direction I wanted, but after trying loads of things, I did this:

graph LR
    C["C:."] --> budget_html["budget.html"]
    C --> index_html["index.html"]
    C --> README["README.md"]
    C --> script_js["script.js"]
    C --> shell_cost["shell-cost.csv"]
    C --> style_css["style.css"]
    C --> assets["assets"]
    
    assets -.-> AeonikRegular["Aeonik-Regular.ttf"]
    assets -.-> ChecklistIconSelected["Checklist Icon Selected.png"]
    assets -.-> ChecklistIcon["Checklist Icon.png"]
    assets -.-> HeaderBackground["Header Background.png"]
    assets -.-> LargeHeaderBackground["Large Header Background.png"]
    assets -.-> Logo["Logo.png"]

    classDef default fill:#fff,stroke:#000,stroke-width:1px;
    classDef assets fill:#f9f9f9,stroke:#000,stroke-width:1px;

Which outputs this:

It does get quite cluttered when there are many files, but it worked for my few files.

I might be in the completely wrong direction here, but I just thought I'd share just in case it does help anyone looking for a similar way to display their file structure.

Sorry if this is the wrong place, hopefully someone finds this useful though.

Hi there @brvv! How about this?

directories
  file1: f
  directory1: d
    file2: file
    file3: file
    directory2: d
  directory3: dir

Which output would be (I used text for simple visualization):

.
├── file1
├── directory1/
│   ├── file2
│   ├── file3
│   └── directory2/
└── directory3/

And maybe the user don't want . as root dir, he might add : r or : root for it. For example:

directories
  root_dir: r
  file1: f

And outputs as:

root_dir
└── file1

It might be a better solution to able to distinguish between directories/folders and files. And the ability to add other styles, e.g., : e or : executable, that will indicate that the file is executable.

So, what does anyone think? any suggestion?

I might be able to work on it with you @brvv if you are fine with it.

Hi there @brvv! How about this?

directories
  file1: f
  directory1: d
    file2: file
    file3: file
    directory2: d
  directory3: dir

Which output would be (I used text for simple visualization):

.
├── file1
├── directory1/
│   ├── file2
│   ├── file3
│   └── directory2/
└── directory3/

And maybe the user don't want . as root dir, he might add : r or : root for it. For example:

directories
  root_dir: r
  file1: f

And outputs as:

root_dir
└── file1

It might be a better solution to able to distinguish between directories/folders and files. And the ability to add other styles, e.g., : e or : executable, that will indicate that the file is executable.

---

So, what does anyone think? any suggestion?

I might be able to work on it with you @brvv if you are fine with it.

Why? What would this enable, specifically?
I thought the goal was a simple file tree layout based on ASCII characters. If that's the case, there really isn't a visual difference between a file and a folder. Are you suggesting this to enable styling or properties of the objects?

If that's the case, there really isn't a visual difference between a file and a folder.

I'm not really sure about that. I think it would be helpful to be able to distinguish between empty folders and files. I'm aware that most files end with an extension, but some don't. And some files have . inside it which might indicate that's a file rather than a folder.

Are you suggesting this to enable styling or properties of the objects?

We might do so. As I said above, we have to make some differences to let users distinguish between them. We might style it differently, as you suggested, or add that trailing /.

But I guess the properties of the object would be essential since the folder could have sub-files or folders. How would we be able to refer to the parent of those files or folders?

In my oppinion, there is an easy way to distinguish files from folders: files usually have a extesion separated by dot, folders have a subtree. A trailing slash is not needed and crashes the readability of this feature. If there is a need to put a trailling slash to a folder, put them in the folder text. Please..... Keep it simple. Let's support @brvv with specific feedbacks on his first poc so he can drive it to beta rather than thousends of well reflected sugestions, what would be nice too. Regards Sven

@brvv Do you have a PR or something that I can potentially help with this?

I would also like this very much! Please keep up working on this!

Was looking for this functionality today, thanks all for the work so far. I support the idea of being able to tag each item as a file/directory since it cannot be assumed that every file has an extension. If the community is happy using a trailing slash character for indicating an item is an empty directory that could solve the problem.

I'm not a big fan of the trailing slash personally, but it's a good approach to distinguishing between files and folders. If someone has a better way to distinguish, we could discuss it.

Just to make sure that you're on the same track with me, I'm suggesting that the trailing slash be optional; if it exists, it's for sure a directory. If not, we rely on indentation:

this_is_a_file
this_is_a_dir
  this_is_a_file
this_is_a_dir/

here is an example of an ascii one we could take some inspiration from to write the grammar: https://tree.nathanfriend.io

Do we want to depend on where the text is? Meaning, 4 spaces = sub, etc..

Or something more like:

Root
-sub1
-sub2
---sub2_sub1
-file1

Do we want to depend on where the text is? Meaning, 4 spaces = sub, etc..

We already have precedence with using spaces indentation in mindmaps in mermaid (and languages like python in general). Also, most editors have support for auto indentation with spaces, but won't support -.

Seeking this feature's future implementation.

No matter how it is implemented... this is the diagram I really need.

Just to make sure that you're on the same track with me, I'm suggesting that the trailing slash be optional; if it exists, it's for sure a directory. If not, we rely on indentation:

this_is_a_file
this_is_a_dir
  this_is_a_file
this_is_a_dir/

here is an example of an ascii one we could take some inspiration from to write the grammar: https://tree.nathanfriend.io

My Idea with this feature request followed a simple approach: I want to simply visualize a file tree. Is there a need to distinguish between folders and files? There are no icons to place, just text. When I have an entry with subentries, it's clear to me, it must be a folder. If not, it's whether an empty folder or a file. Does the entry have an extension (i.e. *.doc) it's clear too, that Enty is most probably a file.
I'm open for discussion.

Maybe We have to open our minds a bit to get away from just Files and Folders: There are other useful uses for this representation: for example, a representation of Git commits, or blockchains. Here no folders and files are involved, and yet the succession of objects is to be represented.

I'd go with the simple text with spaces for indentation approach. If the user wants the trailing slashes, they can write them themselves. I'm all in for configuration, so automatically adding a trailing slash to nodes with children if a configuration is set, but that's extra.

Another useful configuration would be to be able to collapse the nodes and configure the maximum depth that the diagram will render initially expanded.

Another useful configuration would be to be able to use icons for the files. That way the directories and files could have different icons, even by file type.

@brvv Do you have a PR or something that I can potentially help with this?

Any updates on this @brvv? I believe me and some other people would love to help.

whats the current workaround for this?

Would be good to see this, @brvv @george-gca - I can help as well

The best solution I found so far to drawing folder structure is not with mermaid, but using typograms instead.

It's partially off-topic, I found this extension very useful for inserting a folder structure into a markdown text: https://github.com/aprilandjan/vscode-ascii-tree-generator

For windows users, the tree command will also get you a nice ascii representation of a directory. It'd be nice in mermaid of course, but this might be passable alternative for the time being at least. (just a shame that it's not easy to edit)

❯ tree /F
Folder PATH listing for volume ChaosCore
Volume serial number is 788C-1621
C:.
│   cpp.hint
│   Dll1.sln
│   Dll1.vcxproj
│   Dll1.vcxproj.filters
│   Dll1.vcxproj.user
│   dllmain.cpp
│   file.h
│   pch.cpp
│   pch.h
│
├───Dll1
│   └───x64
│       └───Release
│           │   Dll1.dll.recipe
│           │   Dll1.iobj
│           │   Dll1.ipdb
│           │   Dll1.log
│           │   dllmain.obj
│           │   vc143.pdb
│           │
│           └───Dll1.tlog
│                   CL.command.1.tlog
│                   Cl.items.tlog
│                   CL.read.1.tlog
│                   CL.write.1.tlog
│                   Dll1.lastbuildstate
│                   link.command.1.tlog
│                   link.read.1.tlog
│                   link.secondary.1.tlog
│                   link.write.1.tlog
│
└───x64
    └───Release
            Dll1.dll
            Dll1.exp
            Dll1.lib
            Dll1.pdb

Hey! Is this feature still desirable currently? If it is, then I would like to work on this issue if nobody else is working on it.

I would also be open to contributing on this one if it's still of interest to the maintainers.

@Vikrantpalle has done a remarkable job of implementing this feature in #5665.

The only thing left to nail down is the name, ideas welcome!

#5665 (comment)

Since this is a tree being represented in the form of a hierarchical list, I think ListTree is a fitting name. Otherwise, I think fileTree is a good name too.

Will this be available soon? I could really use it!