Project status:
- ✅ Actively maintained
- 🐢 Limited bandwidth
- 🔒 Not looking for code contributions from other developers
If you have a folder structure with Markdown notes, you can use this tool to generate Markdown trees that act as a table of contents for the folder structure.
Example input and expected result
By default, the tool does the following:
- Append a complete tree to the main
README.mdfile (in the directory where the tool is executed) - Write/overwrite
README.mdfiles in subdirectories, each containing the subdirectory's name as title and a tree of the subdirectory's contents (can be disabled through command line arguments)
You can run the tool again and again without changing the result. Once a tree has been written to your main README.md file, you can add anything below the tree (or move the tree) and the tool will respect the tree's boundaries.
Of course, it is recommended to run the tool again every time you make changes to the Markdown notes in your folder structure. It can be useful to include the tool in build scripts or pre-commit hooks.
npm install -D markdown-notes-tree
Not using Node for your project? You can install markdown-notes-tree globally, or you can even add it as a pre-commit plugin.
Example pre-commit configuration:
repos:
- repo: https://github.com/mistermicheels/markdown-notes-tree
rev: v1.12.0
hooks:
- id: markdown-notes-tree
You can run the tool by running npx markdown-notes-tree from the command line or invoking markdown-notes-tree from an npm script.
Make sure to run the tool in the top-level directory of your Markdown notes folder structure.
By default, the tool ignores:
- Folders starting with
.or_ node_modulesfolders- Files that are not Markdown files
You can customize this using the --ignore and --includeAllDirectoriesByDefault command line arguments (see below).
Normally, the tool expects to find the note's title as the first level 1 Markdown heading in the file.
However, if a note starts with YAML front matter that has a tree_title attribute, the value of tree_title will be used as the note's title in the tree.
The generated README.md files for subdirectories provide some space to add a description for the directory. If a description is provided, it will be preserved and it will also be included in generated trees containing the directory.
By default, the generated README.md files for subdirectories use the subdirectory's name as title. If you change this into a custom title, that custom title will be preserved and it will be used in the tree instead of the name of the subdirectory.
If you add content to the generated README.md files for subdirectories before the title or between the title and the description, that content will be preserved. This could be useful for image headers etc.
Don't throw an error on missing title but instead use the file name as fallback.
Example: markdown-notes-tree --allowMissingTitle
Specify glob pattern for additional files or folders to ignore. You can use this argument multiple times in order to specify multiple glob patterns.
Example: markdown-notes-tree --ignore **/CONTRIBUTING.md
Example: markdown-notes-tree --ignore CONTRIBUTING.md --ignore sub1/CONTRIBUTING.md
Example: markdown-notes-tree --ignore exclude-this-folder
Include all directories by default (don't apply the default ignored folders listed above). You can combine this with custom ignores as needed.
Example: markdown-notes-tree --includeAllDirectoriesByDefault --ignore node_modules
Add "Go one level up" and "Go to top level" links at the top of subdirectory README files. If the --linkToSubdirectoryReadme option is enabled, these will link directly to README files. Otherwise, they will link to directories.
Note: By design, markdown-notes-tree only ever touches the README files and not the actual notes. Upward navigation links will not be added to the notes.
Example: markdown-notes-tree --includeUpwardNavigation
When linking to a subdirectory, link directly to its README.md file. Note that this assumes that each subdirectory will actually have a README.md file. By default, the tool generates these automatically.
Example: markdown-notes-tree --linkToSubdirectoryReadme
Don't write README.md files to subdirectories. Any existing README.md files in subdirectories will be ignored.
Example: markdown-notes-tree --noSubdirectoryTrees
If a directory contains both notes and subdirectories, put the notes before the subdirectories in he tree. By default, it's the other way around.
Example: markdown-notes-tree --notesBeforeDirectories
Specify the number of spaces to use for indentation (the default is 4).
Example: markdown-notes-tree --numberSpaces 2
Order notes in the same (sub)directory by title instead of by filename.
Example: markdown-notes-tree --orderNotesByTitle
Filename to use for README files (both the main README file and subdirectory README files). The default is README.md.
Example: markdown-notes-tree --readmeFilename Home.md
Don't log to the console during execution.
Example: markdown-notes-tree --silent
If subdirectory descriptions are provided, put them on a new line in the tree.
Example: markdown-notes-tree --subdirectoryDescriptionOnNewLine
Use tabs (instead of the standard four spaces) for indentation.
Example: markdown-notes-tree --useTabs
- The tool does not support Markdown links inside the titles of notes and subdirectory README files
- This is intentional, because these titles will be turned into links by the tool and Markdown does not support nested links
- As a workaround, HTML links can be used (example)
- Subdirectory descriptions can only be a single paragraph, nothing more
This project is using Prettier to format the JavaScript code. Installing the VS Code plugin recommended through the extensions.json file should make this easy.
The build script verifies that the formatting actually matches Prettier style and that the unit and integration tests are passing.
During development, you can run the tool on a folder by navigating to the folder in the command line and then executing node path/to/cli.js, adding arguments as needed. Example: node ../../../cli.js --silent
- When examining existing Markdown, use actual parsed AST where possible
- For content generated by the tool, use AST for generation where practical
- Complication: we need to retain some level of control over line endings, indentation, ...
- For user-maintained content, prefer reusing existing content instead of regenerating (the latter might change formatting syntax, for example
*vs_for emphasis)