[markdownlint] `trunk init` markdownlint config incompatible with VSCode markdownlint extension (`extends` resolved as path)

[AndrewDongminYoo]

Summary

trunk init generates .trunk/configs/.markdownlint.yaml with:

extends: markdownlint/style/prettier

This works in trunk check because Trunk's markdownlint wrapper sets NODE_PATH to Trunk-managed node_modules, but it fails when the same config is used by VSCode extension DavidAnson.vscode-markdownlint via "markdownlint.configFile".

This makes the generated config non-portable and confusing, especially compared to the older Trunk-generated config that disabled formatting rules directly (no extends).

Repro steps

1. In a repo containing any Markdown files, run:

   • trunk init
   • When prompted to install markdownlint (with others), answer Y.

2. Confirm generated file .trunk/configs/.markdownlint.yaml contains:

   extends: markdownlint/style/prettier

3. In VSCode, add to .vscode/settings.json:

   {
     "markdownlint.configFile": ".trunk/configs/.markdownlint.yaml"
   }

4. Open any .md file.

Actual result (VSCode output)

VSCode shows repeated errors like:

Error: Unable to use configuration file '~/Development/01_personal/apr-app-assignment/.trunk/configs/.markdownlint.yaml'; Error: ENOENT: no such file or directory, open '~/Development/01_personal/apr-app-assignment/.trunk/configs/markdownlint/style/prettier'
stack:
 at xc (~/.vscode/extensions/davidanson.vscode-markdownlint-0.61.1/bundle.js:39:39268)
 at ~/.vscode/extensions/davidanson.vscode-markdownlint-0.61.1/bundle.js:39:47281
 at async Ic (~/.vscode/extensions/davidanson.vscode-markdownlint-0.61.1/bundle.js:39:46482)
cause:
 EntryNotFound (FileSystemError): Error: ENOENT: no such file or directory, open '~/Development/01_personal/apr-app-assignment/.trunk/configs/markdownlint/style/prettier'
 stack:
  at Lr.e (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:116:18080)
  at Object.readFile (file:///Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:116:16601)

Expected result

The Trunk-generated markdownlint config should be usable by standard markdownlint tooling, including VSCode extension, without requiring repo-specific path rewrites.

Why it happens

vscode-markdownlint / markdownlint-cli2 resolves extends as a path relative to the config file location. So extends: markdownlint/style/prettier is interpreted as:
.trunk/configs/markdownlint/style/prettier
which does not exist.

Meanwhile, Trunk’s wrapper sets:

• NODE_PATH=~/.cache/trunk/tools/markdownlint/.../node_modules
  so Trunk CLI runs succeed, masking the portability issue.

Wrapper snippet for reference (.trunk/tools/markdownlint):

export NODE_PATH=".../node_modules"
exec markdownlint "$@"

Regression / historical behavior

Older trunk init versions used a self-contained config like:

default: true
blank_lines: false
bullet: false
html: false
indentation: false
line_length: false
spaces: false
url: false
whitespace: false

This worked everywhere without relying on extends resolution.

Suggested fixes

One of:

1. Revert to generating a self-contained config (disable formatting rules directly).
2. Vendor/emit the preset file under .trunk/configs/... and use a relative extends: ./markdownlint/style/prettier.
3. Document prominently that the generated config is Trunk-runtime-specific and provide a VSCode-compatible variant.

Environment

• OS: macOS (Apple Silicon)
• VSCode: Version: 1.109.4
• Extension: DavidAnson.vscode-markdownlint 0.61.1
• Trunk: 1.25.0
• Tool versions (from Trunk cache): markdownlint 0.47.0, node 22.16.0

[AndrewDongminYoo]

Actually, I never use the file as it's first created; I always overwrite it with this content. (It's a bit overly descriptive, but I'm strictly following the guidelines from markdownlint/style/prettier.) Like this:

File: .trunk/configs/markdownlint.yaml

Language: yaml

Range: lines 1-109 (full file)

# Disables rules that may conflict with Prettier

# heading-increment - Heading levels should only increment by one level at a time
#MD001: true
# heading-style - Heading style
MD003: false
# ul-style - Unordered list style
#MD004: true
# list-indent - Inconsistent indentation for list items at the same level
MD005: false
# ul-indent - Unordered list indentation
MD007: false
# no-trailing-spaces - Trailing spaces
MD009: false
# no-hard-tabs - Hard tabs
MD010: false
# no-reversed-links - Reversed link syntax
#MD011: true
# no-multiple-blanks - Multiple consecutive blank lines
MD012: false
# line-length - Line length
MD013: false
# commands-show-output - Dollar signs used before commands without showing output
#MD014: true
# no-missing-space-atx - No space after hash on atx style heading
MD018: false
# no-multiple-space-atx - Multiple spaces after hash on atx style heading
MD019: false
# no-missing-space-closed-atx - No space inside hashes on closed atx style heading
MD020: false
# no-multiple-space-closed-atx - Multiple spaces inside hashes on closed atx style heading
MD021: false
# blanks-around-headings - Headings should be surrounded by blank lines
MD022: false
# heading-start-left - Headings must start at the beginning of the line
MD023: false
# no-duplicate-heading - Multiple headings with the same content
#MD024: true
# single-title/single-h1 - Multiple top-level headings in the same document
#MD025: true
# no-trailing-punctuation - Trailing punctuation in heading
#MD026: true
# no-multiple-space-blockquote - Multiple spaces after blockquote symbol
MD027: false
# no-blanks-blockquote - Blank line inside blockquote
MD028: false
# ol-prefix - Ordered list item prefix
MD029: false
# list-marker-space - Spaces after list markers
MD030: false
# blanks-around-fences - Fenced code blocks should be surrounded by blank lines
MD031: false
# blanks-around-lists - Lists should be surrounded by blank lines
MD032: false
# no-inline-html - Inline HTML
#MD033: true
# no-bare-urls - Bare URL used
#MD034: true
# hr-style - Horizontal rule style
MD035: false
# no-emphasis-as-heading - Emphasis used instead of a heading
#MD036: true
# no-space-in-emphasis - Spaces inside emphasis markers
#MD037: true
# no-space-in-code - Spaces inside code span elements
#MD038: true
# no-space-in-links - Spaces inside link text
#MD039: true
# fenced-code-language - Fenced code blocks should have a language specified
#MD040: true
# first-line-heading/first-line-h1 - First line in a file should be a top-level heading
#MD041: true
# no-empty-links - No empty links
#MD042: true
# required-headings - Required heading structure
#MD043: true
# proper-names - Proper names should have the correct capitalization
#MD044: true
# no-alt-text - Images should have alternate text (alt text)
#MD045: true
# code-block-style - Code block style
#MD046: true
# single-trailing-newline - Files should end with a single newline character
#MD047: true
# code-fence-style - Code fence style
MD048: false
# emphasis-style - Emphasis style
MD049: false
# strong-style - Strong style
MD050: false
# link-fragments - Link fragments should be valid
#MD051: true
# reference-links-images - Reference links and images should use a label that is defined
#MD052: true
# link-image-reference-definitions - Link and image reference definitions should be needed
#MD053: true
# link-image-style - Link and image style
#MD054: true
# table-pipe-style - Table pipe style
#MD055: true
# table-column-count - Table column count
#MD056: true
# blanks-around-tables - Tables should be surrounded by blank lines
#MD058: true
# descriptive-link-text - Link text should be descriptive
#MD059: true
# table-column-style - Table column style
#MD060: true

[AndrewDongminYoo]

FYI: DavidAnson (vscode-markdownlint/markdownlint maintainer) replied that extends behavior is by design and typical: it resolves a package name or a path relative to the config file.

He suggests this is a tooling interoperability issue caused by Trunk relying on NODE_PATH / non-standard module resolution, and that the most efficient fix is for Trunk to document/adjust the generated config/template (rather than expecting downstream tools to document Trunk-specific behavior).

Also noted: VS Code/Electron may differ from standard Node module loading, and VS Code web lacks Node module infra entirely, so portability matters.